"Stefano D'Angelo" <[EMAIL PROTECTED]> writes: While I'm still not back to lv2zyn/zynjacku development, I'll share my thoughts. :)
> 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 > #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. > #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. > #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. > #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. > #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. > #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. > #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. > 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 ;) -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>
pgp9GcY8EJnnf.pgp
Description: PGP signature
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
