2008/6/3, Steve Harris <[EMAIL PROTECTED]>: > On 2 Jun 2008, at 19:16, Stefano D'Angelo wrote: >> >>>> #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 :-\ > > I think you'll make everyones life much better if you just provide > utility functions (eg. in slv2) to convert interleaved integers and > whatever to channelled floats. Constantly converting back and forth > between different plugins with different requirements is lossy (in > audio quality terms) and difficult to get right. Just do it once. > There's a reason that LADSPA, LV2, VST etc. do everything in floats.
Maybe yuo're right. >>>> #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. > > If you want glitch free playback then you have to stick to one sample > rate at the card, in which case you may as well do the conversion > before you start feeding plugins. Right, didn't think about that actually. > Any plugin that uses filters (ie. pretty much anything interesting) > will have to recalculate it's coefficients and throw away buffers if > you change the sample rate on it, so you'll be out of luck if you > expect this to be smooth. By "throwing away buffers" you mean past buffers? >>>> #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. > > It's not necessary, just intervene after each run() call, it's not > hard and on a modern machine the cost is negligible. Sorry, I'm not understanding here. How would you do exactly? >>>> #4. Support for time stretching when using non real-time audio >>>> sources. >>> >>> Why not? AFAIK this has clear uses in "professional" audio world too. > > Yeah, but not in "realtime". LV2 could of course support that, with an > extension, but it doesn't seem like the sort of thing that has enough > variance that a plugin mechanism is a huge win over using SRC. Mmm.. not if it is only time-stretching, but if it is time-stretching + other stuff (for example pitch shifting) together? Gonna use two plugins? I don't know :-\ >>>> #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. > > In LADSPA there's a "magic" control out port called "_latency" or > something, that should apply to LV2 aswell, but I'm not sure if the > spec says so. Which spec are you referring to? IIRC the LADSPA spec doesn't state such a thing. Some convention maybe? >>>> #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). > > What is a channel that is not a port/port group? Ports can be grouped > and attributed, as eg. quality v's speed, or you can just say that by > convention QvS ports have some well-known label, in the same way that > systemic latency is indicated. I was referring to one of the interleaved channels in a multi-channel stream. About labels, could we maybe define a set of known labels? (And isn't that already implemented somehow in LV2? - I'm not exactly familiar with it, as you may have noticed) >>>> #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. > > That's just a specification issue, it doesn't require any code. In > order to use things like the CRT, linkers and loaders invoke global > constructor attributes and so on, so that's just not an issue. ? >>>> #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. > > That's all in the specification. You can also do more sophisticated > searches based on attributes of the plugins (EQs, room correction or > whatever). "That's all in the specification" <- that's the weird part of it. Are you going to make a new revision any time there's some new platform to support? Then, I see no reference on how to get a fixed path when you compile/install an LV2 host, which could be useful after all (in many distros I had to set LADSPA_PATH on my own, for example). >>>> #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. > > Extensions can label the concurrency properties of any additional > stuff in a machine readable way, but I don't think that's relevant, as > without knowing exactly what a new function does, how/why would you > call it? I agree. Anyway, I was just saying that maybe it's good to be strict about concurrency issues, in case LV2 is not already strict enough. >>>> #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. > > I don't see why you'd need a different library, but hey, the more the > merrier. I didn't look at SLV2, gotta give it a look ASAP. However, let's make it simple for both developers who don't want to loose too much time with LV2 and for users. Stefano _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
