On Sat, 2012-05-26 at 19:47 -0400, Tim E. Real wrote: > I added variable run-length processing to MusE. > It can break a period into single frame runs if necessary. [...] > What about encoder and decoder plugins? Yer switching matrices etc. > Their precise control rates and timestamps must be preserved right? > I guess if LV2 allows hi-speed control rates, it would cure the issue with > some ladspa audio ports being used for hi-speed control, with no way to > know that fact.
LV2 does have CV ports, which are identical to audio ports but semantically the values are control values. For discrete controls, actually you can easily do this with a normal event port, just as we do MIDI. There's just a lack of convention, or standard event type to convey control values. Once you go that far, though, you start questioning why you're using different port buffers when it's easy to multiplex controls to a single buffer, which is: * More space efficient * Easier to iterate over and process as time progresses (but harder for some other things) * Allows for dynamic controls (e.g. n-band EQs and such), a highly desirable feature * Faster than multiple run() calls due to decreased function-call-via-a-pointer overhead > Whaddya you guys think? > Or did I actually just provide arguments /against/ vari-runs? Ha ha... Basically you've provided arguments that the control rate not always being the Jack buffer size is good. Few would argue that. It's splitting the cycle on odd numbers that causes problems for certain kinds of plugins. However it should be mentioned (despite suggestions to the contrary) that if a solution to this was implemented, it is trivial to make old plugins adapt to restricted buffer sizes. It's the other way around that doesn't work. Cheers, -dr _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
