linuxaudio.org

On Sat, 2012-05-26 at 19:47 -0400, Tim E. Real wrote:

quoted text
> I added variable run-length processing to MusE.

> It can break a period into single frame runs if necessary.

[...]

quoted text
> 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?

quoted text
> 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

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev