libvisual-devel — libvisual mailinglist for developers

[Libvisual-devel] Developer

[Dennis S. <sy...@yo...>]

Duilio

I've added you as a developer!

About comitting things to CVS:

When all the new packages are in CVS I grand you to
do whatever you'd like with the infinite plugin as long
as it's sane :)

Build tree fixes may always be comitted.

For other patches please post them on the devel list first
so I can have a look at it, this especially goes for
libvisual itself.

Thanks,
Dennis

Re: [Libvisual-devel] Re: plans

[Dennis S. <sy...@yo...>]

On Sat, 2004-06-19 at 16:20 -0300, Duilio Javier Protti wrote:
> Hi, I have updated the building scripts of
>  
> There is a major error on 0.1.4, you don't
> distribute lv_xmms.h, so compilation fails.
> You must include lv_xmms.h to libvisual_xmms_la_SOURCES
> on src/Makefile.am, this way the header will be
> included on the 'dist' target.
Omg, that is embarrasing :) after all the auto* 1.8 stuff
is done it's time to rerelease it seems :)


> >when using --force within the autogen.sh, is --force
> >needed or can i drop it ? it seems to work fine
> >without it. (automake 1.4)
>  
> On first use is not neede, however, if you upgrade
> autoconf or automake, this will make all things be
> upgraded to the new version.
> I really really recommend you to change to at least
> automake 1.7. Rebuilding process is tooooo much improved.
Ok, i'll get it working :), this is the first time I used
the auto* tools so I'm still kinda flacky here and there!
thanks for your help!


> >How can I add you as a developer to the libvisual
> >project at sf.net?
> 
> Login in to sf.net, then go to project page, click
> on Admin menu, then on Members menu, then on
> 'Add a developer to this project' and enter
> my sf.net username: dprotti

I will add you!

Thanks a lot,
Dennis

[Libvisual-devel] libvisual 0.1.4 release problems.

[David B. <c_x...@ya...>]

In the libvisual package:
the 'examples' and 'tests' subfolders are missing.

In the libvisual_plugins package:
missing plugins/actor/JESS/*.h
missing plugins/actor/infinite/*.h
missing plugins/actor/oinskie/*.h
missing plugins/actor/lv_analyzer/ directory
missing plugins/actor/video_test/ directory

In the libvisual_xmms package:
missing src/lv_xmms.h

You will need to make a new release so we can build
libvisual and add spells to SMGL
(http://www.sourcemage.org)

and maybe testing your release before posting it is
an idea... ;)


	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

[Libvisual-devel] Re: plans

[Duilio J. P. <dp...@fc...>]

Hi, I have updated the building scripts of
Libvisual XMMS plugin. ChangeLog:
 
- configure.in moved to configure.ac
- AC_INIT and AM_INIT_AUTOMAKE moved to his
new form
- AM_DISABLE_STATIC and AM_PROG_LIBTOOL moved
to AC_DISABLE_STATIC and AC_PROG_LIBTOOL
- Check for pkg-config installed and above 0.14
- Misc checks make it more verbose
- AC_C_CONST check
- Use of AC_PREFIX_PROGRAM to try to guess prefix
from xmms path
 
Also some paths on src/Makefile.am make it more
relative, so objects can be build from anywhere,
not just the top_srcdir.
 
There is a major error on 0.1.4, you don't
distribute lv_xmms.h, so compilation fails.
You must include lv_xmms.h to libvisual_xmms_la_SOURCES
on src/Makefile.am, this way the header will be
included on the 'dist' target.
 
>when using --force within the autogen.sh, is --force
>needed or can i drop it ? it seems to work fine
>without it. (automake 1.4)
 
On first use is not neede, however, if you upgrade
autoconf or automake, this will make all things be
upgraded to the new version.
I really really recommend you to change to at least
automake 1.7. Rebuilding process is tooooo much improved.

>How can I add you as a developer to the libvisual
>project at sf.net?

Login in to sf.net, then go to project page, click
on Admin menu, then on Members menu, then on
'Add a developer to this project' and enter
my sf.net username: dprotti

 
Bye,
Duilio.

Re: [Libvisual-devel] Re: Plans

[Dennis S. <sy...@yo...>]

Thanks a lot this is fantastic!, i've got one issue with
the autogen.sh, 

when using --force within the autogen.sh, is --force needed
or can i drop it ? it seems to work fine without it.
(automake 1.4)

automake: unrecognized option -- `--force-missing'
Try `automake --help' for more information.
autoreconf: automake failed with exit status: 2

Regarding infinity with xmms disabled it's working like a charm!
---

I'm kinda busy right now, we're in the middle of a move (again)
so that is being the reason for that.

However I'll try to find some time tomorrow to import libvisual
into sf.net CVS. I also would be REALLY happy if you could
convert libvisual-plugins, libvisual-xmms and libvisual-nebulus
as well! Also I'll fix the extra_dist issues with libvisual
(stupid me!)

How can I add you as a developer to the libvisual project at sf.net ?

Thanks and cheers,
Dennis


On Fri, 2004-06-18 at 19:22 -0300, Duilio Javier Protti wrote:
> >Any suggestions how I can easily move a complete
> >reposity to sf.net or is it best to just re import the source
> >trees ?
> 
> Is much easier to make an initial import. However,
> you must not import the distributed package, you must
> init the repository with a subset of the package, without
> the cached building-process files and the system/version
> dependent macro files.
> Let me explain.
> I have rebuild your building scripts with autoconf 2.59
> and automake 1.8. ChangeLog is like this:
> - configure.in renamed to configure.ac (configure.in is
> deprecated)
> - AC_INIT and AM_INIT_AUTOMAKE macros moved to the new
> long form
> - now we check for headers:
> AC_HEADER_DIRENT
> AC_HEADER_STDC
> AC_CHECK_HEADERS([fcntl.h stdint.h stdlib.h string.h sys/time.h
> unistd.h])
> - now we check for functions:
> AC_FUNC_MALLOC
> AC_FUNC_REALLOC
> AC_CHECK_FUNCS([memset sqrt strdup])
> - warn if pkg-config is not installed or installed version
> is older than 0.14
> - removed examples/Makefile and tests/Makefile from AC_OUTPUT
> (because their Makefile.in's are not in the distro!
> The tests directory doesn't even exists! Probably you have
> forgotten to define EXTRA_DIST macro on the corresponding
> Makefile.am's on your working directory, so they are not included
> on the 'dist' target)
> - finally, AM_CFLAGS is used instead of CFLAGS on libvisual/Makefile.am
> Ok, what you must submit to the CVS is a clean tree of the package,
> but without configure and all the Makefile.in's. How you will obtain
> this on a first checkout? Well, all these will be generated by the
> autogen.sh script that I send you attached on a private mail.
> For this to work autoconf >= 2.57 and automake >= 1.7 are needed.
> What you gain here is an autoconf/automake's version independent
> repository. Every developer will build your own macros/cached-files,
> that matchs the exact autoconf/automake version they have.
> 
> Enjoy it!
>                                                                                                                
> >you'd like to develop on the infinite plugin I assume ? :)
> 
> Yes, I want to get involved. In regard of that, if you have some
> time please try to compile my plugin with --disable-mmx option
> and let me know the results. I really think the problem is the
> use of MMX, because XMMS also use it, and as you probably know,
> if you have a context switch before to make emms(), you will
> trash the processor's float registers. On my system this work
> well, but I have to much reports about this problem.
> 
>                                                                                                                
> Duilio.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> Libvisual-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libvisual-devel

[Libvisual-devel] Re: Plans

[Duilio J. P. <dp...@fc...>]

>Any suggestions how I can easily move a complete
>reposity to sf.net or is it best to just re import the source
>trees ?

Is much easier to make an initial import. However,
you must not import the distributed package, you must
init the repository with a subset of the package, without
the cached building-process files and the system/version
dependent macro files.
Let me explain.
I have rebuild your building scripts with autoconf 2.59
and automake 1.8. ChangeLog is like this:
- configure.in renamed to configure.ac (configure.in is
deprecated)
- AC_INIT and AM_INIT_AUTOMAKE macros moved to the new
long form
- now we check for headers:
AC_HEADER_DIRENT
AC_HEADER_STDC
AC_CHECK_HEADERS([fcntl.h stdint.h stdlib.h string.h sys/time.h
unistd.h])
- now we check for functions:
AC_FUNC_MALLOC
AC_FUNC_REALLOC
AC_CHECK_FUNCS([memset sqrt strdup])
- warn if pkg-config is not installed or installed version
is older than 0.14
- removed examples/Makefile and tests/Makefile from AC_OUTPUT
(because their Makefile.in's are not in the distro!
The tests directory doesn't even exists! Probably you have
forgotten to define EXTRA_DIST macro on the corresponding
Makefile.am's on your working directory, so they are not included
on the 'dist' target)
- finally, AM_CFLAGS is used instead of CFLAGS on libvisual/Makefile.am
Ok, what you must submit to the CVS is a clean tree of the package,
but without configure and all the Makefile.in's. How you will obtain
this on a first checkout? Well, all these will be generated by the
autogen.sh script that I send you attached on a private mail.
For this to work autoconf >= 2.57 and automake >= 1.7 are needed.
What you gain here is an autoconf/automake's version independent
repository. Every developer will build your own macros/cached-files,
that matchs the exact autoconf/automake version they have.

Enjoy it!
                                                                                                               
>you'd like to develop on the infinite plugin I assume ? :)

Yes, I want to get involved. In regard of that, if you have some
time please try to compile my plugin with --disable-mmx option
and let me know the results. I really think the problem is the
use of MMX, because XMMS also use it, and as you probably know,
if you have a context switch before to make emms(), you will
trash the processor's float registers. On my system this work
well, but I have to much reports about this problem.

                                                                                                               
Duilio.

Re: [Libvisual-devel] Re: Plans

[Dennis S. <sy...@yo...>]

I've got my own reposity local but indeed I should move
it to sf.net. Any suggestions how I can easily move a complete
reposity to sf.net or is it best to just re import the source
trees ?

Btw, you'd like to develop on the infinite plugin I assume ? :)


On Thu, 2004-06-17 at 15:52 -0300, Duilio Javier Protti wrote:
> Dear Dennis,
> 
> There are plans for CVS repository?
> This way we can keep track of development,
> and even we can became involved very
> easy.
> 
> 
> Duilio.

[Libvisual-devel] Re: Plans

[Duilio J. P. <dp...@fc...>]

Dear Dennis,

There are plans for CVS repository?
This way we can keep track of development,
and even we can became involved very
easy.


Duilio.

[Libvisual-devel] Plans

[Dennis S. <sy...@yo...>]

It has been kinda quite around libvisual lately and I've
been side tracked by other projects.

However now most of the API docs are done I'm going to
work on the plugin param system from which new exciting
features can flow.

Also I'd like to hear reports about portability and
libvisual!

Cheers,
Dennis

[Libvisual-devel] New libvisual release!

[Dennis S. <sy...@yo...>]

We've made a new release for libvisual, libvisual-plugins,
libvisual-nebulus, libvisual-xmms.

This release is NOT backwards compatible so all clients
and plugins need to be recompiled.

Changes:

libvisual-0.1.4:
        Version 0.1.4 has been released.

        * Fixes for SGI regarding time.h
        * Architecture fixes, using precise intergral types from
stdint.h
        * Made an builtin bitmap loader, for loading textures and such.
        * Documentated the code using doxygen.
        * Many many cleanups.
        * Made all the enumerate non anonymous.

libvisual-plugins-0.1.4:
        Version 0.1.4 has been released.

        * Portability fixes.
        * Using precise intergral types from stdint.
        * All kinds of cleanups.

libvisual-nebulus-0.1.1:
        Version 0.1.1

        * Adapted to API changes.

libvisual-xmms-0.1.4:
        Version 0.1.4 has been released.

        * Dropt SDL depency to 1.2.5 because this works
        out of the box on IRIX and should work for us.
---


Notes:

Basicly this is a minor cleanup, portability fixes release and the
major change is the fairly complete libvisual API documentation that
can be found at: 
http://libvisual.sourceforge.net/libvisual-api-docs/index.html

It's fresh so if you spot things that need attention in the API docs
please report them on this list!
---


Availability:
http://prdownloads.sourceforge.net/libvisual/libvisual-0.1.4.tar.gz?download
http://prdownloads.sourceforge.net/libvisual/libvisual_nebula-0.1.1.tar.gz?download
http://prdownloads.sourceforge.net/libvisual/libvisual_plugins-0.1.4.tar.gz?download
http://prdownloads.sourceforge.net/libvisual/libvisual_xmms-0.1.4.tar.gz?download

[Libvisual-devel] irix needs sys/time.h for tv structure

[Jeroen <dys...@xs...>]

A note for synap.

Other observations
* When compiling on IRIX, one need gmake; not make.
* Libvisual-0.1.33 compiles fine with GCC 3.3.
* MIPSPro currently untested.
 
Kind regards / met vriendelijke groet,
Jeroen

-- 

100% Microsoft free. You could be too!

Re: [Libvisual-devel] opts

[Dennis S. <sy...@yo...>]

On Tue, 2004-06-08 at 17:49 -0300, Duilio Javier Protti wrote:
> >On the naming, what would you people prefer, "opts", "param" or
> >something else ?
> 
> I prefer param.
> 
> 
> Duilio.

I must admit that i'm still kinda in doubt. Eventually we will
have a plugin preferences system to set plugin preferences. As said
before this will be separated from the (opts || params) because
I want a lowlevel param system.

I see the opts kinda like 'getopt' however getopt takes
parameters and seen we don't have the 'getopt' layer maybe
it's nicer to call it parameter.

Eh, what does sound better:
visual_param_set_bool (params, "displacement field", FALSE);
or:
visual_opts_set_bool (opts, "displacement field", FALSE);

Cheerio,
Dennis

(The following was written under the influence of a considerable
amount of alcohol and for that reason can be a bit 'less optimal')

[Libvisual-devel] Re: plugin opts

[Duilio J. P. <dp...@fc...>]

>On the naming, what would you people prefer, "opts", "param" or
>something else ?

I prefer param.


Duilio.

[Libvisual-devel] opts

[Duilio J. P. <dp...@fc...>]

>On the naming, what would you people prefer, "opts", "param" or
>something else ?

I prefer param.


Duilio.

Re: [Libvisual-devel] plugin opts

[Dennis S. <sy...@yo...>]

On Tue, 2004-06-08 at 11:00 -0300, Gustavo Sverzut Barbieri wrote:
> >
> > On the naming, what would you people prefer, "opts", "param" or
> > something else ?
> 
> opts is better IMHO.
> 
> Thanks for that, now I can specify input_mplayer mmap()ed filename.
> 

I agree on opts sounding better, it's not yet in but i'll be working on
it after i finished all the documentation (which is almost complete now)

Cheers,
Dennis

Re: [Libvisual-devel] plugin opts

[Gustavo S. B. <gu...@gs...>]

Em Tuesday 08 June 2004 08:59, Dennis Smit escreveu:
> I'd like to begin working on plugin opts soonish.
>
> Opts are plugin parameters which can be used to set intergral,
> boolean and string values.
>
> Opts shouldn't be confused with plugin preferences.
>
> Opts are more like low level settings for example:
>
> visual_opts_set_string (opts, "gst-pipe", "random ! gst ! pipe");
> for a gstreamer actor plugin. (which for example could be streaming
> video into libvisual).
>
> or
> visual_opts_set_boolean (opts, "displacement", FALSE);
> that could be disabling the displacement field of the JESS plugin so
> JESS can be directly drawn in the goom plugin using a special visualFX
> wrapper for goom.
>
>
> When implementing opts within plugins always keep in mind strongly that
> opts are meant for low levelness not for preferences.
>
>
> Also I'd like two sets of opts, being local opts and global opts.
>
> Libvisual will have a small set of global opts. These are opts that
> count for EVERY plugin and EVERY plugin should be monitoring these opts.
>
> An example on this is a "show songinfo" opts which can be toggled to
> enable and disable showing songinfo within plugins, when they
> support this.
>
> Local opts are ofcourse plugin specific opts.
>
>
> On the naming, what would you people prefer, "opts", "param" or
> something else ?

opts is better IMHO.

Thanks for that, now I can specify input_mplayer mmap()ed filename.

-- 
Gustavo Sverzut Barbieri
---------------------------------------
Engenharia de Computacao 2001 - UNICAMP
GPSL - Grupo Pro Software Livre
Cell..: +55 (19) 9165 8010
Jabber: gsb...@ja...
  ICQ#: 17249123
   GPG: 0xB640E1A2 @ wwwkeys.pgp.net

[Libvisual-devel] plugin opts

[Dennis S. <sy...@yo...>]

I'd like to begin working on plugin opts soonish. 

Opts are plugin parameters which can be used to set intergral,
boolean and string values.

Opts shouldn't be confused with plugin preferences.

Opts are more like low level settings for example:

visual_opts_set_string (opts, "gst-pipe", "random ! gst ! pipe");
for a gstreamer actor plugin. (which for example could be streaming
video into libvisual).

or
visual_opts_set_boolean (opts, "displacement", FALSE);
that could be disabling the displacement field of the JESS plugin so
JESS can be directly drawn in the goom plugin using a special visualFX
wrapper for goom.


When implementing opts within plugins always keep in mind strongly that
opts are meant for low levelness not for preferences.


Also I'd like two sets of opts, being local opts and global opts.

Libvisual will have a small set of global opts. These are opts that
count for EVERY plugin and EVERY plugin should be monitoring these opts.

An example on this is a "show songinfo" opts which can be toggled to
enable and disable showing songinfo within plugins, when they
support this.

Local opts are ofcourse plugin specific opts.


On the naming, what would you people prefer, "opts", "param" or
something else ?


Cheers,
Dennis

[Libvisual-devel] Random updates!

[Dennis S. <sy...@yo...>]

Heya people, it's kinda silent around libvisual lately.. BUT that
doesn't mean i've been slacking!

What have i been doing:
1. Cleanups.
2. Documentating using doxygen, most of the API is documented but it's
not yet finished. (This was a load of work)
3. Randomness.

I'm searching for someone who is into web developing that can brew up
a more advanced website. I want a simple website but one that is better
navigatable and using sections.

I'll be doing a new release quite soon!

Cheers,
Dennis

Re: [Libvisual-devel] Take care with arch

[Dennis S. <sy...@yo...>]

stdint, i never knew that one, let me check it out :)

The lv_config.h isn't there, it was an suggestions, but i think stdint
will do.

Thank you!

On Tue, 2004-06-01 at 09:20 -0300, Gustavo Sverzut Barbieri wrote:
> Em Tuesday 01 June 2004 08:09, Dennis Smit escreveu:
> > Gustavo,
> >
> > what do you think about an lv_config.h that gets generated
> > from the config.h.in template ?, i have no experience with this tho.
> 
> Which package? Just downloaded libvisual, ./configure and no lv_config.h, make 
> and still none... locate lv_config.h (my system have libvisual installed) and 
> nothing.
> 
> 
> > How can i set up macros in the template that will generate
> > uint16, int16, (same for 8, 32) for me ?, i'd like to get this fixed
> > in the next release, also someone reported issues with amd64 so
> > hopefully it gets fixed, or atleast partialy fixed by using
> > these types.
> 
> #include <stdint.h>
> 

Re: [Libvisual-devel] Take care with arch

[Gustavo S. B. <gu...@gs...>]

Em Tuesday 01 June 2004 08:09, Dennis Smit escreveu:
> Gustavo,
>
> what do you think about an lv_config.h that gets generated
> from the config.h.in template ?, i have no experience with this tho.

Which package? Just downloaded libvisual, ./configure and no lv_config.h, make 
and still none... locate lv_config.h (my system have libvisual installed) and 
nothing.


> How can i set up macros in the template that will generate
> uint16, int16, (same for 8, 32) for me ?, i'd like to get this fixed
> in the next release, also someone reported issues with amd64 so
> hopefully it gets fixed, or atleast partialy fixed by using
> these types.

#include <stdint.h>

-- 
Gustavo Sverzut Barbieri
---------------------------------------
Engenharia de Computacao 2001 - UNICAMP
GPSL - Grupo Pro Software Livre
Cell..: +55 (19) 9165 8010
Jabber: gsb...@ja...
  ICQ#: 17249123
   GPG: 0xB640E1A2 @ wwwkeys.pgp.net

Re: [Libvisual-devel] Take care with arch

[Dennis S. <sy...@yo...>]

Gustavo, 

what do you think about an lv_config.h that gets generated
from the config.h.in template ?, i have no experience with this tho.
How can i set up macros in the template that will generate
uint16, int16, (same for 8, 32) for me ?, i'd like to get this fixed
in the next release, also someone reported issues with amd64 so
hopefully it gets fixed, or atleast partialy fixed by using 
these types.

Cheers,
Dennis

On Tue, 2004-04-27 at 22:58 -0300, Gustavo Sverzut Barbieri wrote:
> struct _VisAudio {
>         int16_t plugpcm[2][512];
> 
>         int16_t pcm[3][512];
>         int16_t freq[3][512];
> 
>         fft_state *fft_state;
> 
>         int16_t bpmhistory[1024][6];
>         int16_t bpmdata[1024][6];
>         int16_t bpmenergy[6];
>         int32_t energy;
> };
> 
> 
> Also, if the data is limited to 2 channels of 512 16 bits samples, we should 
> provide some helper to merge channels... even if the helper discard the 
> channels instead of merge them  (1/3/5/6 channels -> 2 channels)
> 

[Libvisual-devel] Re: Gentoo / libvisual

[Dennis S. <sy...@yo...>]

Hello Malc,

Thanks a lot for creating the ebuilds!, Gustavo an libvisual
contributor had already looked into this, but hadn't yet submitted
them so thanks a lot for taking the time!

I know of no one using libvisual succesfully on an 64 bit architecture
so i'll be glad to retrieve stacktraces and get the issues worked out!

Libvisual needs a lot of multiplatform support fixes, so i'll be looking
into this in the near future!

Thanks a lot,
Dennis

On Sun, 2004-05-30 at 18:14 +0100, malc wrote:
> Dennis,
> 
> Just to let you know - I created some preliminary ebuilds for gentoo and
> submitted them to our bugzilla. The bug with attached ebuilds is at
> http://bugs.gentoo.org/show_bug.cgi?id=52476 should anyone ask you for a
> gentoo ebuild in the meantime.
> 
> As an aside, I tested libvisual-xmms on amd64 in 32bit mode ok - but got
> segfaults in 64bit mode (where I have no hardware opengl thanks to ati)
> I just wondered if you knew of anyone who had successfully used the xmms
> plugin on the amd64 architecure?
> 
> Regards,
> malc.
> 

Re: [Libvisual-devel] First public release.

[Dennis S. <sy...@yo...>]

And thanks to Jeroen for testing my release tarballs ! :)

The analyzer plugin isn't getting installed right now because it does
nothing, but if there was an old version laying around we had an binair
incompatilibity issue!

Cheers,
Dennis

> I had some problems with XMMS and my old plugin directory.
> If you install the 0.1.3 version be sure to remove 
> $INSTALLPATH/libvisual -- ie. /usr/lib/libvisual
> 
> After i removed that and reinstalled libvis-plugins everything was okay.
> 
> Thanks to Dennis for pointing this out!
>  
> Kind regards / met vriendelijke groet,
> Jeroen
> 

Re: [Libvisual-devel] First public release.

[Jeroen <dys...@xs...>]

In message #1 on Fri, May 28, 2004 at 02:14:04AM +0200, Dennis Smit mumbled:
> I've been doing the first public release tonight.

[...]

> Why did i release, because i felt like releasing, it's without doubt
> beta if not alpha, but i think it's ready for public experimentation!

I had some problems with XMMS and my old plugin directory.
If you install the 0.1.3 version be sure to remove 
$INSTALLPATH/libvisual -- ie. /usr/lib/libvisual

After i removed that and reinstalled libvis-plugins everything was okay.

Thanks to Dennis for pointing this out!
 
Kind regards / met vriendelijke groet,
Jeroen

-- 

100% Microsoft free. You could be too!

[Libvisual-devel] First public release.

[Dennis S. <sy...@yo...>]

Heya!

I've been doing the first public release tonight.

Released are:
libvisual-0.1.3:
2004-05-27  Dennis Smit  <ds...@ne...>
        Version 0.1.3 has been released.

        * Install lv_log.h
        * Lots and lots of work on the managed bin.
        * Managed bin now seamlessly automaticly morphs from whatever
          to whatever. (Ok i lied here, the managed bin needs
          a rewrite, but it SEEMS to work)
        * Better support for openGL.
        * Have requisition method for the actor plugins.
        * Pass audio to the morph plugins.
        * Don't open the plugins with RTL_GLOBAL.

libvisual-plugins-0.1.3:
2004-05-27  Dennis Smit  <ds...@ne...>
        * Added a madspin port.
        * Fixed all the actor plugins to support size requisition (this 
	  is mandatory btw).
        * Added support for retrieving VisAudio within the morph 
	  plugins.
        * Cleanups.

libvisual-xmms-0.1.3:
2004-05-27  Dennis Smit  <ds...@ne...>
        Version 0.1.3 has been released.

        * Depth notification from the managed bin.

And i've also released the new libvisual-nebulus openGL plugin which is
a port from the xmms one.


Notes on the managed bin stuff:

It's borked, it's without succes, it's there to be rewritten, utterly
shit and i basicly screwed up. However you won't really see this without
abusing it, so i released anyway.

Why did i release, because i felt like releasing, it's without doubt
beta if not alpha, but i think it's ready for public experimentation!

Cheers,
Dennis