2008/6/2 Nedko Arnaudov <[EMAIL PROTECTED]>: > "Stefano D'Angelo" <[EMAIL PROTECTED]> writes: > > While I'm still not back to lv2zyn/zynjacku development, I'll share my > thoughts. :)
Fair enough :-) >> Let's stop this flame for a moment and see what LV2 misses in order to >> let me kill EPAMP and live an happier life. > > Not sure you will live happier live :P The less stuff to maintain, the better ;-) >> #1. Support for interleaved channels and non-float data >> Input and output data is often found in these formats. > > New port type is needed. Keep in mind though, that plugins using this > port type will be probably limited to music player hosts. Also if we > extrapolate this idea, we will have mp3 stream ports or things like > that. Think twice whether it is good idea. Well, I'd say non-float non-compressed data. I think ALSA's PCM sample formats are more than sufficient. If you're worried about third parties... LV2 is decentralized by design :-\ >> #2. Changing sample rate without re-instantiating all effects. >> Gapless playback when chaning songs, for example, should be possible >> without performing black magic. > > While I see nothing wrong to support that in general, if I was writting > a music player, I'd use one sample rate/format do processing using it > and convert/decode input streams early in the flow chain. Me too actually. I don't know. >> #3. Some serious connection logic thing (all the "equal channels" thing >> etc.). >> This needs a thousand flame wars and *deep* thinking. > > No idea what you mean by this. If someone is going to write that helper library (or adjust SLV2 or whatever), I guess we should find some reasonable conventions to organize and use plugins in a chain-like thing. This is damn hard, as Paul Davis outlined already on this mailing list, and I actually don't know to which degree it should be done. >> #4. Support for time stretching when using non real-time audio sources. > > Why not? AFAIK this has clear uses in "professional" audio world too. > >> #5. Informations about delay time introduced by the algorithm itself >> to do syncing with video-sources (for example). > > Uhm, dont we have such thing in LV2 already? If not, I think we need > it. This should be useful for syncing multiple audio streams too. For > video sources I'd prefer to have video streams (video port type), > probably as event port. > >> #6. Some way for the host to make sense of the meaning of some >> parameters and channels, to better support global settings and stuff. > > No idea what you mean by this. ATM, I miss instantiation stage > parameters though. Example: some LV2 extension tells the host that which parameter is a "quality vs. speed" parameter in a plugin. The host can, then, show a global "quality vs. speed" parameter to the user. By "channel sense", I mean the host could know what a channel is in a standardized way (I see you have that already in port groups extension, it could be generalized to channels rather than ports). >> #7. Global explicit initialization/finalization functions for more >> exotic platforms (they wouldn't harm, so why not having them). > > I still dont get what is the use case for this. Both on the host side and on the plugin side, no need for #ifdefs to define initialization/finalization functions and maybe support for exotic platforms not having them. >> #8. Rules to find plugins possibly platform-specific and outside of >> the specification; possibly one compile-time valid path. > > AFAIK, this conficts with "LV2 spirit". Why one needs this? If the goal > is to avoid RDF Turtle, this shouldnt be issue with proper helper > library for hosts. Still such feature could be implemented in such a > helper library. Nope. I mean there should be platform-specific rules to get the list of directories containing shared object files and possibly there should be a fixed path to check on each platform, known at compile time. >> #9. Maybe more strict requirements on both hosts and plugins >> (especially about thread-safety). >> I see there is some indication in the core spec, but I don't know >> about extensions and/or other possible concurrency issues. > > If things are not documented clearly enough I dont see why they > shouldnt. > >> #10. Something (a library possibly) to make use all of this features >> easily from the host author's POV. > > I'd choose one path of two host helper libraries, one for music player > like apps and one for more music creation oriented ones. Not sure whether > SLV2 fits in former case, AFAIK it is only used in later ones. I could help, let's just see how this discussion turns out. >> Can we start discussing about these issues and see if they are solved >> already/how to implement them/how to make them better? > > Sure, but IMHO the things get real momentum when someone starts writting > code, not just discussing. I hope this advice this will help you in your > journey ;) At least I don't want to waste effort if I start writing something :-) Stefano _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
