Menu
▾
▴
libvisual-devel — libvisual mailinglist for developers
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
(38) |
May
(22) |
Jun
(92) |
Jul
(101) |
Aug
(18) |
Sep
(286) |
Oct
(180) |
Nov
(73) |
Dec
(14) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(18) |
Feb
(74) |
Mar
(56) |
Apr
(11) |
May
(5) |
Jun
(4) |
Jul
(20) |
Aug
(4) |
Sep
|
Oct
|
Nov
(1) |
Dec
(2) |
| 2006 |
Jan
(11) |
Feb
(2) |
Mar
(10) |
Apr
(2) |
May
(1) |
Jun
|
Jul
(24) |
Aug
(11) |
Sep
(5) |
Oct
(16) |
Nov
(25) |
Dec
(8) |
| 2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(1) |
Aug
|
Sep
|
Oct
(4) |
Nov
(12) |
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
|
From: Dennis S. <sy...@yo...> - 2004-09-17 06:06:07
|
On Thu, 2004-09-16 at 23:34 +0100, salsaman wrote: > Ooh I do love G-force :-) > > BTW, what is the status of nebulous ? If you mean nebulus, it's working, but it's openGL so it's (atm) far from LiVES stuff :) |
|
From: Dennis S. <sy...@yo...> - 2004-09-17 06:05:23
|
On Thu, 2004-09-16 at 23:33 +0100, salsaman wrote: > My suggestion was to use a wrapper - rather like the livido wrapper will > be for actors. > > Just have a little routine that is waiting for a kick trigger from > libvisual. Then the routine can handle registering hosts and sending the > OSC messages. Agree with this. |
|
From: Duilio J. P. <dp...@fc...> - 2004-09-16 23:38:55
|
> I got this patch from some gentoo dude for libdir stuff. > If I'm not wrong this was recently looked at but > I still post it here so you can verify. > > Thanks, > Dennis No, it was not fixed, I will do it right now. Please add acknowledgment who correspond on the Changelog. Bye, Duilio. |
|
From: salsaman <sal...@xs...> - 2004-09-16 21:19:40
|
Dennis Smit wrote: >On Wed, 2004-09-15 at 20:36 -0300, Duilio Javier Protti wrote: > > >>Oh, sorry, I forget to add the Makefile.am's to the repository :-) >>Please check again and test it. >> >> > >Alright, now it compiles! > >So the only issue left are the preset names ? > >That would mean we're really close to a G-Force unleash ;) > >Cheers, >Dennis > > > >------------------------------------------------------- >This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 >Project Admins to receive an Apple iPod Mini FREE for your judgement on >who ports your project to Linux PPC the best. Sponsored by IBM. >Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php >_______________________________________________ >Libvisual-devel mailing list >Lib...@li... >https://lists.sourceforge.net/lists/listinfo/libvisual-devel > > > > Ooh I do love G-force :-) BTW, what is the status of nebulous ? Salsaman. |
|
From: salsaman <sal...@xs...> - 2004-09-16 21:18:36
|
Dennis Smit wrote: >On Thu, 2004-09-16 at 13:01 +0200, Niels Elburg wrote: > > >>The OpenSoundControl protocol >>(http://www.cnmat.berkeley.edu/OpenSoundControl/) would make a great >>extension to libvisual. >> >>Using the OSC would bring a few benefits to libvisual: >> 1. Flexible (external/remote) control of libvisual plugins >> 2. Application programmers dont have to hardcode parameter/event handling >> but can send messages to libvisual actor/plugin instead >> >> > >Well, generally OSC is 'just another bus system' and a unknown one. >I don't really like depending on this. I'm very wary with depending >on 'cool' stuff. Since it can easily crack up the lib. > >Cheers, >Dennis > >(sorry for my somewhat short answer, kinda tired) > > > > >------------------------------------------------------- >This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 >Project Admins to receive an Apple iPod Mini FREE for your judgement on >who ports your project to Linux PPC the best. Sponsored by IBM. >Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php >_______________________________________________ >Libvisual-devel mailing list >Lib...@li... >https://lists.sourceforge.net/lists/listinfo/libvisual-devel > > > > My suggestion was to use a wrapper - rather like the livido wrapper will be for actors. Just have a little routine that is waiting for a kick trigger from libvisual. Then the routine can handle registering hosts and sending the OSC messages. Salsaman. |
|
From: Dennis S. <sy...@yo...> - 2004-09-16 20:06:24
|
On Thu, 2004-09-16 at 13:01 +0200, Niels Elburg wrote: > The OpenSoundControl protocol > (http://www.cnmat.berkeley.edu/OpenSoundControl/) would make a great > extension to libvisual. > > Using the OSC would bring a few benefits to libvisual: > 1. Flexible (external/remote) control of libvisual plugins > 2. Application programmers dont have to hardcode parameter/event handling > but can send messages to libvisual actor/plugin instead Well, generally OSC is 'just another bus system' and a unknown one. I don't really like depending on this. I'm very wary with depending on 'cool' stuff. Since it can easily crack up the lib. Cheers, Dennis (sorry for my somewhat short answer, kinda tired) |
|
From: Dennis S. <sy...@yo...> - 2004-09-16 20:01:44
|
On Wed, 2004-09-15 at 20:36 -0300, Duilio Javier Protti wrote: > Oh, sorry, I forget to add the Makefile.am's to the repository :-) > Please check again and test it. Alright, now it compiles! So the only issue left are the preset names ? That would mean we're really close to a G-Force unleash ;) Cheers, Dennis |
|
From: Dennis S. <sy...@yo...> - 2004-09-16 19:59:06
|
I agree on this totally, adding it to the roadmap! If someone could make a begin, (aka structure filewise) I'll be willingly to fill up the docs ;)) Cheers, Dennis On Wed, 2004-09-15 at 23:52 -0300, Duilio Javier Protti wrote: > I think would be nice to include on the frontmatter of the > html docs generated by doxygen, a general explanation about > the libvisual architecture, specially a graphic showing his > middlelayer role. > > I have seen that many people new to libvisual gets confused > about what is a plugin "for" libvisual, and what is a plugin > that "uses" libvisual (and his plugins for transitivity). > > This role is one of the key points of libvisual, so we must > let it very clear. What do you think people? > > > Bye, > Duilio. > |
|
From: Dennis S. <sy...@yo...> - 2004-09-16 19:53:55
|
Another thingy from gentoo, can you please look at this Duilio Should sure be merged before 0.1.7 ;) Cheers, Dennis |
|
From: Dennis S. <sy...@yo...> - 2004-09-16 19:51:51
|
On Wed, 2004-09-15 at 23:52 -0300, Duilio Javier Protti wrote: > We can disable mmx within libvisual, but there is no way to > disable mmx on the whole process (even the OS can't do that). > > The question is how to let the libvisual users disable/enable > mmx stuff. If we give something like: > > int visual_cpu_enable_mmx (int yes_or_no); I had exactly this in mind, the plugins should always check capabilities through VisCPU subsystem, and This way we can disable certain capabilities through the VisCPU system. > on the VisCPU module, the problem is what to do if some plugin > enables mmx, but then other plugin (say on morphed switch) disable it. > We must denied or not? If we accept, we must tell the others > plugins that mmx activation has changed, so we must let plugins > register a callback for that: Have to think about this, generally plugins should be touching the capabilities, as in changing them. But still, have to think about it. > int visual_cpu_enable_mmx (int yes_or_no, void (*) (void *)); > > The other possibility is to enable/disable mmx stuff only through > a visual_init() parameter. I like more this, because this is done > just once per application, and because main application have > enough information to decide whether or not it must activate mmx > stuff. Well, not through visual_init, but through an initialization call. I think that, having the app decide if it should be enabled or not is best indeed. However now we have the next problem. What about threaded render pipeline. (at morph, two actors in both a thread) for heavy use in mutliCPU machines... (Why O why does mmx share it's regs with FPU...) We should so get into SSE as well :) Cheers, Dennis |
|
From: salsaman <sal...@xs...> - 2004-09-16 16:56:19
|
Burkhard Plaum wrote: >> Fortunately for the plugins I've seen so far there is not a problem >> because the red/blue channels can be swapped without problem, so they >> can support both RGB and BGR. > > > Maybe the plugins might still look "cool" when B and R are swapped, > but the plugin authors won't like this. > Adjusting the colors for a visualization can involve many hours > of fine-tuning. Well true, but in this case it could be marked somehow. > > > There need to be a bullet-proof definition of RGB and BGR, so that > all plugins are displayed with the right colors on all architectures. See below. > > You should also take care, that there is no "standard" about RGB and BGR, > especially for 15/16 bpp. The same format might be called differently > in different software packages. Sorry, I was talking about 24bit colours, so in this case the definition is obvious, blue pixel byte comes before green pixel byte which comes before red pixel byte. > > Colorspace issues can become really complicated. I wrote a library > (gavl), > which handles all these. The main header is here: > > http://cvs.sourceforge.net/viewcvs.py/gmerlin/gavl/include/gavl/gavl.h?view=markup > > > The libavcodec source (ffmpeg.org) also gives an idea how to handle > pixel formats properly. > Swapping the red and blue is not hard, it's just time consuming when it has to be done for each frame. I've not heard of gavl before, but it looks interesting. Do you have conversions for all those palettes ? I am looking for a high quality YUV420 <---> UYVY converter. Livido will also have palette conversions. Salsaman. |
|
From: Burkhard P. <pl...@ip...> - 2004-09-16 14:11:42
|
> Fortunately for the plugins I've seen so far there is > not a problem because the red/blue channels can be swapped without > problem, so they can support both RGB and BGR. Maybe the plugins might still look "cool" when B and R are swapped, but the plugin authors won't like this. Adjusting the colors for a visualization can involve many hours of fine-tuning. There need to be a bullet-proof definition of RGB and BGR, so that all plugins are displayed with the right colors on all architectures. You should also take care, that there is no "standard" about RGB and BGR, especially for 15/16 bpp. The same format might be called differently in different software packages. Colorspace issues can become really complicated. I wrote a library (gavl), which handles all these. The main header is here: http://cvs.sourceforge.net/viewcvs.py/gmerlin/gavl/include/gavl/gavl.h?view=markup The libavcodec source (ffmpeg.org) also gives an idea how to handle pixel formats properly. -- _____________________________ Dr.-Ing. Burkhard Plaum Institut fuer Plasmaforschung Pfaffenwaldring 31 70569 Stuttgart Tel.: +49 711 685-2187 Fax.: -3102 |
|
From: Niels E. <ne...@lo...> - 2004-09-16 11:01:17
|
Hello list , The OpenSoundControl protocol (http://www.cnmat.berkeley.edu/OpenSoundControl/) would make a great extension to libvisual. Using the OSC would bring a few benefits to libvisual: 1. Flexible (external/remote) control of libvisual plugins 2. Application programmers dont have to hardcode parameter/event handling but can send messages to libvisual actor/plugin instead At audio analyzer level (not needing the visualization plugins): 3. Users can setup OSC messages to be sent to other applications to trigger bangs/events on sound events ( kick, beat, frequency ... ) Looking at the morph sdl example, I can imagine an osc structure for flexible control of libvisual plugins: /visual/morph/setup/ depth dimension pitch duration <in frames> /visual/morph/set/ freeze <num> alpha <float> speed <float> reverse ... (3. Users sets up OSC messages to be sent to other applications) /visual/analyzer/setup destination_host <host> destination_port <port> /visual/analyzer/on kick <message> beat <message> roll <message> vol <message> I guess that the latter (nr. 3) would be most usefull for libvisual ; it would greatly improve interoperability with other applications without needing to implement libvisual in those applications (the user can simply connect them). Best, Niels Elburg (main developer of Veejay, http://veejay.sourceforge.net) |
|
From: salsaman <sal...@xs...> - 2004-09-16 10:14:05
|
Hi all, as you know I have been testing libvisual in LiVES, and it is reasonably fast. However, there might be a problem with some plugins, as I believe that they work in the RGB colourspace whilst LiVES works in BGR (default for GTK+ on x86). Fortunately for the plugins I've seen so far there is not a problem because the red/blue channels can be swapped without problem, so they can support both RGB and BGR. However, for some plugins, they might require a strict interpretation of red and blue. Would it be possible to mark such plugins with a flag somehow ? Regards, Salsaman. |
|
From: Duilio J. P. <dp...@fc...> - 2004-09-16 02:43:40
|
I think would be nice to include on the frontmatter of the html docs generated by doxygen, a general explanation about the libvisual architecture, specially a graphic showing his middlelayer role. I have seen that many people new to libvisual gets confused about what is a plugin "for" libvisual, and what is a plugin that "uses" libvisual (and his plugins for transitivity). This role is one of the key points of libvisual, so we must let it very clear. What do you think people? Bye, Duilio. |
|
From: Duilio J. P. <dp...@fc...> - 2004-09-16 02:43:31
|
> > In regard of VisCPU module, there is an idea about the API? > > Well, there is not a real API yet no, there is a header file, but if you > can design a useful API that would be good! *heheheh*. Also, we need > to make sure that through an API call, mmx, etc can be disabled. > > Cheers, > Dennis We can disable mmx within libvisual, but there is no way to disable mmx on the whole process (even the OS can't do that). The question is how to let the libvisual users disable/enable mmx stuff. If we give something like: int visual_cpu_enable_mmx (int yes_or_no); on the VisCPU module, the problem is what to do if some plugin enables mmx, but then other plugin (say on morphed switch) disable it. We must denied or not? If we accept, we must tell the others plugins that mmx activation has changed, so we must let plugins register a callback for that: int visual_cpu_enable_mmx (int yes_or_no, void (*) (void *)); The other possibility is to enable/disable mmx stuff only through a visual_init() parameter. I like more this, because this is done just once per application, and because main application have enough information to decide whether or not it must activate mmx stuff. Bye, Duilio. |
|
From: Duilio J. P. <dp...@fc...> - 2004-09-15 23:27:39
|
> This I get after a FRESH checkout, ./autogen.sh: > > autoreconf: running: /usr/bin/autoconf --force > autoreconf: configure.ac: not using Autoheader > autoreconf: running: automake --add-missing --force-missing > configure.ac: installing `./missing' > Common/GeneralTools/Makefile.am: installing `./depcomp' > configure.ac:15: installing `./config.guess' > configure.ac:15: installing `./config.sub' > Makefile.am: installing `./INSTALL' > configure.ac:71: required file `Common/GeneralTools/Headers/Makefile.in' > not found > configure.ac:71: required file `Common/io/Headers/Makefile.in' not found > configure.ac:71: required file `Common/math/Headers/Makefile.in' not > found > configure.ac:71: required file `Common/UI/Headers/Makefile.in' not found > configure.ac:71: required file `GForceCommon/Headers/Makefile.in' not > found > configure.ac:71: required file `unix/Headers/Makefile.in' not found > configure.ac:71: required file `GForceColorMaps/Makefile.in' not found > configure.ac:71: required file `GForceDeltaFields/Makefile.in' not found > configure.ac:71: required file `GForceParticles/Makefile.in' not found > configure.ac:71: required file `GForceWaveShapes/Makefile.in' not found > configure.ac:71: required file `NotWorkingWaveShapes/Makefile.in' not > found > configure.ac:15: required file `./ltmain.sh' not found > configure.ac:71: required file `Common/GeneralTools/Headers/Makefile.in' > not found > configure.ac:71: required file `Common/io/Headers/Makefile.in' not found > configure.ac:71: required file `Common/math/Headers/Makefile.in' not > found > configure.ac:71: required file `Common/UI/Headers/Makefile.in' not found > configure.ac:71: required file `GForceCommon/Headers/Makefile.in' not > found > configure.ac:71: required file `unix/Headers/Makefile.in' not found > configure.ac:71: required file `GForceColorMaps/Makefile.in' not found > configure.ac:71: required file `GForceDeltaFields/Makefile.in' not found > configure.ac:71: required file `GForceParticles/Makefile.in' not found > configure.ac:71: required file `GForceWaveShapes/Makefile.in' not found > configure.ac:71: required file `NotWorkingWaveShapes/Makefile.in' not > found > autoreconf: automake failed with exit status: 1 Oh, sorry, I forget to add the Makefile.am's to the repository :-) Please check again and test it. Bye, Duilio. |
|
From: Dennis S. <sy...@yo...> - 2004-09-15 21:28:45
|
Duilio, I got this patch from some gentoo dude for libdir stuff. If I'm not wrong this was recently looked at but I still post it here so you can verify. Thanks, Dennis |
|
From: Dennis S. <sy...@yo...> - 2004-09-15 11:59:42
|
On Wed, 2004-09-15 at 13:38 +0200, Burkhard Plaum wrote:
> > In the case that you get anough audio samples for
> > a high framerate, what is the use of asynchronous rendering?
>
> On weaker CPUs, one visualization plugin might slow down the whole
> process (in the worst case, also the audio playback). Imagine a player,
> which does something like:
>
> while(1)
> {
> get_next_samples();
> send_samples_to_soundcard();
> send_samples_to_libvisual();
> }
>
> If send_samples_to_libvisual() renders and displays everything
> synchronously, the soundcard buffer might underrun, which won't sound
> that good.
> So at least at one point between the playback loop (which drives the
> soundcard) and the visualization, things should be decoupled.
>
> If it's in the application, inside libvisual, or inside the plugin,
> doesn't matter.
In this setup, you use a audio callback in the libvisual pipeline which
semi automaticly retrieves samples. Using that + have helper functions
to run the complete libvisual pipeline in a thread and this issue is
solved.
> > We're creating this, through improving libvisual and introducing
> > libvisual-display.
>
> The libvisual-display seems to be crucial. Keep me updated, when
> there is something in CVS.
Cool, watch the list, bits will coming the upcoming weeks.
> Actually, lemuria does this for it's 256x256 texture: Copy the
> framebuffer into a texture and into memory, exchange some colors
> and copy it back into a second texture.
> Because sometimes the foreground and background have
> the same texture image, only the colors are swapped.
Well, ok but here it's a small texture and for special purpose.
> The funny thing is, that most people think, they are completely
> different images :-)
Hehehehe!
Cheers,
Dennis
|
|
From: Burkhard P. <pl...@ip...> - 2004-09-15 11:35:36
|
> The application has final control, so I was thinking about the plugin.
> We can have a flag within the VisActorPlugin structure
> like .fps_preferred .
Ok, that's good.
> But what is the usage, of trying to draw frames, if it's not getting
> displayed anyway ?
You're right, that should be avoided.
> In the case that you get anough audio samples for
> a high framerate, what is the use of asynchronous rendering?
On weaker CPUs, one visualization plugin might slow down the whole
process (in the worst case, also the audio playback). Imagine a player,
which does something like:
while(1)
{
get_next_samples();
send_samples_to_soundcard();
send_samples_to_libvisual();
}
If send_samples_to_libvisual() renders and displays everything
synchronously, the soundcard buffer might underrun, which won't sound
that good.
So at least at one point between the playback loop (which drives the
soundcard) and the visualization, things should be decoupled.
If it's in the application, inside libvisual, or inside the plugin,
doesn't matter.
Xmms says, that the render_* functions shouldn't take long (for the
reason described above). This implies, that plugins, which are more CPU
intensive, should be threaded.
>> this doesn't interfer with syncing OpenGL to the monitor refresh rate
>> it could be ok.
> It won't because that is in glx it's hands. (right ?)
It's enabled via an enviroment variable (for the NVidia drivers at least).
The application cannot control the Gl<->Monitor sync.
> We will surely make an good API that can let plugins request any format
> they want!
Ok.
> We're creating this, through improving libvisual and introducing
> libvisual-display.
The libvisual-display seems to be crucial. Keep me updated, when
there is something in CVS.
>>A workaround for this could be to copy the OpenGL framebuffer into
>>system memory and use the same display methods as for 2D plugins.
>>Maybe the PCs in 2010 can do this at 1280x1024 :-)
>
> Heheh, well, that is a dirty solution ofcourse, might be even
> good for those video editing stuff, but not for what we want !
> but you know that as well lol.
Actually, lemuria does this for it's 256x256 texture: Copy the
framebuffer into a texture and into memory, exchange some colors
and copy it back into a second texture.
Because sometimes the foreground and background have
the same texture image, only the colors are swapped.
The funny thing is, that most people think, they are completely
different images :-)
--
_____________________________
Dr.-Ing. Burkhard Plaum
Institut fuer Plasmaforschung
Pfaffenwaldring 31
70569 Stuttgart
Tel.: +49 711 685-2187
Fax.: -3102
|
|
From: Dennis S. <sy...@yo...> - 2004-09-15 10:44:14
|
On Wed, 2004-09-15 at 12:05 +0200, Burkhard Plaum wrote: > > Well, how can an app take the best depth, without knowing it ?. > > Maybe because libvisual handles the Window/Visual/depth > stuff? Libvisual handles the visual/depth. NOT THE WINDOWS. that is the whole point. Because of this you can literally draw a visual anywhere. But because we don't want the app to handle windowing itself, we are planning to introduce libvisual-display. To solve this issue, and have more control! > It's nice if visualization plugins can be window system independent. > But IMHO it would even be better if applications also don't need to > care about it. > I didn't dig too deep into libvisual yet, so maybe I sound stupid. I agree with you, this is why we plan libvisual-display. But it needs to be coded, and we aren't with many people :) > > What about a system that tells libvisual, > > 'I'd REALLY like THIS framerate' and then libvisual implements > > an easy to use framerate limiter. > > Who tells it, the application or the vis plugin? The application has final control, so I was thinking about the plugin. We can have a flag within the VisActorPlugin structure like .fps_preferred . > > Some guys are doing VJ software > > combined with realtime video software with it. > > Ok, then we need the framerate forced by the application. Optionally, forced, yes OPTIONALLY :) Also this LiVES stuff uses only framebuffer plugins, because it mixes with video clips. > > Most plugins don't obtain this framerate, it's not a problem that > > not each sample a picture is generated. > > Exactly :-) > And this is, where it gets asynchronous! But what is the usage, of trying to draw frames, if it's not getting displayed anyway ? In the case that you get anough audio samples for a high framerate, what is the use of asynchronous rendering ? And if you can't obtain the framerate, what does asynchronous help in this ? > > As said, we can use a FPS limiter provided by libvisual, or wouldn't > > that be sufficient ? > > If this doesn't interfer with syncing OpenGL to the monitor refresh rate > it could be ok. It won't because that is in glx it's hands. (right ?) > > The audio core gets redone eventually, so don't rely too much on this > > '512' thing. > > Oops, the 512 samples are hardcoded everywhere inside lemuria and many > other plugins. It's in the xmms API (and thus also in winamp I would guess). We will surely make an good API that can let plugins request any format they want! > > What is needed, in facilities, within libvisual to make it possible ? > > (as you can guess by now, I only use threads when it's absolutely > > needed, no way around it). Ofcourse as a plugin writer, it's your > > choice. But I'd rather make some facilities in libvisual to work > > it out threadlessly, than using threads. > > Ok, IMHO there need to be at least 2 different layers. One, > which handles the pcm -> picture stuff synchronously and > threadless. The other one handles the window/displaying/framerate > stuff. We're creating this, through improving libvisual and introducing libvisual-display. > For 2D plugins like goom, these two can completely be separated. > You can make a picture even without knowing into which window > it will be displayed later on. Yep, for OpenGL this is a different case ofcourse > The problem is for OpenGL, because rendering a picture looks like > (speaking for GLX only): > ..... > And glXSwapBuffers can (and should) be synched to the monitor as > I said. Yep. > A workaround for this could be to copy the OpenGL framebuffer into > system memory and use the same display methods as for 2D plugins. > Maybe the PCs in 2010 can do this at 1280x1024 :-) Heheh, well, that is a dirty solution ofcourse, might be even good for those video editing stuff, but not for what we want ! but you know that as well lol. > I can't hack a lot for libvisual due to lack of time, > but I would really like to discuss APIs for the display stuff > when they get written. That is ok, Discussion APIs is contribution. Two know more than one so to say. > I think libvisual is a good approach, but It will cost some > brain cycles to make it meet all requirements :-) That is why it's good to have many people on the list, so we can distribute those brain cycles *grin*.. Thanks for all your comments, it's sure worth stuff! Cheers, Dennis |
|
From: Dennis S. <sy...@yo...> - 2004-09-15 10:33:37
|
Updated the roadmap: http://libvisual.sourceforge.net/LIBVISUAL_ROADMAP |
|
From: Dennis S. <sy...@yo...> - 2004-09-15 10:27:47
|
This I get after a FRESH checkout, ./autogen.sh: autoreconf: running: /usr/bin/autoconf --force autoreconf: configure.ac: not using Autoheader autoreconf: running: automake --add-missing --force-missing configure.ac: installing `./missing' Common/GeneralTools/Makefile.am: installing `./depcomp' configure.ac:15: installing `./config.guess' configure.ac:15: installing `./config.sub' Makefile.am: installing `./INSTALL' configure.ac:71: required file `Common/GeneralTools/Headers/Makefile.in' not found configure.ac:71: required file `Common/io/Headers/Makefile.in' not found configure.ac:71: required file `Common/math/Headers/Makefile.in' not found configure.ac:71: required file `Common/UI/Headers/Makefile.in' not found configure.ac:71: required file `GForceCommon/Headers/Makefile.in' not found configure.ac:71: required file `unix/Headers/Makefile.in' not found configure.ac:71: required file `GForceColorMaps/Makefile.in' not found configure.ac:71: required file `GForceDeltaFields/Makefile.in' not found configure.ac:71: required file `GForceParticles/Makefile.in' not found configure.ac:71: required file `GForceWaveShapes/Makefile.in' not found configure.ac:71: required file `NotWorkingWaveShapes/Makefile.in' not found configure.ac:15: required file `./ltmain.sh' not found configure.ac:71: required file `Common/GeneralTools/Headers/Makefile.in' not found configure.ac:71: required file `Common/io/Headers/Makefile.in' not found configure.ac:71: required file `Common/math/Headers/Makefile.in' not found configure.ac:71: required file `Common/UI/Headers/Makefile.in' not found configure.ac:71: required file `GForceCommon/Headers/Makefile.in' not found configure.ac:71: required file `unix/Headers/Makefile.in' not found configure.ac:71: required file `GForceColorMaps/Makefile.in' not found configure.ac:71: required file `GForceDeltaFields/Makefile.in' not found configure.ac:71: required file `GForceParticles/Makefile.in' not found configure.ac:71: required file `GForceWaveShapes/Makefile.in' not found configure.ac:71: required file `NotWorkingWaveShapes/Makefile.in' not found autoreconf: automake failed with exit status: 1 |
|
From: Dennis S. <sy...@yo...> - 2004-09-15 10:26:17
|
On Tue, 2004-09-14 at 23:24 -0300, Duilio Javier Protti wrote: > > Maybe an idea to support 'random morph plugin' option as well. > Sounds good. > > I doubt if the xmms plugin itself needs serialization through libvisual. > I'm agree with you. > > > 0.1.9 > > > Wait for VisFont subsystem. > > > 0.1.10 > > > Try to use VisFont subsystem. > > > Show song info on the video area on play and things like that. > > This will be handled in libvisual itself! through an API ;) > > (so every client can use it directly) > Oh, good. > > In regard of VisCPU module, there is an idea about the API? Well, there is not a real API yet no, there is a header file, but if you can design a useful API that would be good! *heheheh*. Also, we need to make sure that through an API call, mmx, etc can be disabled. Cheers, Dennis |
|
From: Burkhard P. <pl...@ip...> - 2004-09-15 10:06:11
|
> Well, how can an app take the best depth, without knowing it ?. Maybe because libvisual handles the Window/Visual/depth stuff? It's nice if visualization plugins can be window system independent. But IMHO it would even be better if applications also don't need to care about it. I didn't dig too deep into libvisual yet, so maybe I sound stupid. > What about a system that tells libvisual, > 'I'd REALLY like THIS framerate' and then libvisual implements > an easy to use framerate limiter. Who tells it, the application or the vis plugin? > Some guys are doing VJ software > combined with realtime video software with it. Ok, then we need the framerate forced by the application. > Most plugins don't obtain this framerate, it's not a problem that > not each sample a picture is generated. Exactly :-) And this is, where it gets asynchronous! > As said, we can use a FPS limiter provided by libvisual, or wouldn't > that be sufficient ? If this doesn't interfer with syncing OpenGL to the monitor refresh rate it could be ok. > The audio core gets redone eventually, so don't rely too much on this > '512' thing. Oops, the 512 samples are hardcoded everywhere inside lemuria and many other plugins. It's in the xmms API (and thus also in winamp I would guess). Changing visualization plugins for handling arbitrary audio frame sizes would normally result in buffering samples until there are 512 of them. > What is needed, in facilities, within libvisual to make it possible ? > (as you can guess by now, I only use threads when it's absolutely > needed, no way around it). Ofcourse as a plugin writer, it's your > choice. But I'd rather make some facilities in libvisual to work > it out threadlessly, than using threads. Ok, IMHO there need to be at least 2 different layers. One, which handles the pcm -> picture stuff synchronously and threadless. The other one handles the window/displaying/framerate stuff. For 2D plugins like goom, these two can completely be separated. You can make a picture even without knowing into which window it will be displayed later on. The problem is for OpenGL, because rendering a picture looks like (speaking for GLX only): Window window; Display * display; GLXContext glxcontext; glXMakeCurrent(display, window, glxcontext); /* Do all the OpenGL functions */ ... /* */ glXSwapBuffers(display, window); And glXSwapBuffers can (and should) be synched to the monitor as I said. A workaround for this could be to copy the OpenGL framebuffer into system memory and use the same display methods as for 2D plugins. Maybe the PCs in 2010 can do this at 1280x1024 :-) I can't hack a lot for libvisual due to lack of time, but I would really like to discuss APIs for the display stuff when they get written. I think libvisual is a good approach, but It will cost some brain cycles to make it meet all requirements :-) -- _____________________________ Dr.-Ing. Burkhard Plaum Institut fuer Plasmaforschung Pfaffenwaldring 31 70569 Stuttgart Tel.: +49 711 685-2187 Fax.: -3102 |
10 messages has been excluded from this view by a project administrator.
