On 3 Jun 2008, at 12:53, Stefano D'Angelo wrote: >>>>> #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?
I mean the y(-1) etc. buffers that filters use to calculate their output. Actually it may not be neccesary to discard them in some cases, but you will still get glitches from the coefficient changes. >>>>> #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? You don't have to make plugin A directly feed plugin B, you can have the host do some buffer twiddling inbetween. >>>>> #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 :-\ Well, pitch shifting is fine in plugins. >>>>> #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? Yeah, that's what implying by "magic", in LV2 it's an annotation on ports. >>>>> #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) OK, but interleaving is just inconvenient, in many ways. >>>>> #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? Yes, sure. > 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). http://lv2plug.in/docs/index.php?title=Filesystem_Locations >>>>> #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. It is. >>>>> #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. That was the intention I believe. The sample code makes it look eaay, but I've not written any code with it myself. LV2 is certainly one of the easiest plugin formats for plugin authors. - Steve _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
