[LAD] CV data protocol in apps.

Nick Copeland nickycopeland at hotmail.com
Thu Feb 18 13:39:58 UTC 2010

> > But actually, implementing it perfectly it jack apps may cost a lot if
> > your control rate is the same as the audio rate (for example computing
> > a filter coefs 96000 times per second). I think a new type of 'audio'
> > port having only a sample per period could be a simple and handy
> > solution to this (one of the problem may be when you connect more than
> > one cv to a port, mixing CV isn't necessarily the thing we want to do)
> >
> > Anyway, CV is still, even after 50 year, a really nice way of
> > controlling audio parameters, and would be kind of a good solution for
> > mapping lv2 control ports to jack ports.

I think you need to recognise that using a CV for everything might be nice but
is indeed a bit of an overhead and is also not really how the old analogue 
beasts really worked. They had continuous controls that did apply the V/oct
that mix/max in with the modulating signals, on top of that they also had some
non-continuous controls such as waveform selectors that did not function 
in this way - they typically switched between different circuit outputs. CV
really doesn't lend itself to such a use - MIDI is a far better choice for the 
many discrete controls of a synth.

Bristol internally uses both representations after making consideration of a
pure CV type signalling. MIDI CC are used for non-continuous controls and
full sample buffers are used for modulation signalling: LFO/Osc/Env outputs 
are fed into buffers that are mixed to modulating inputs: the filter sweep is a 
buffer of samples and it does recalculate filter coefs for every sample - it eats 
GOBS of CPU but avoids the 'ritzing' you would hear if it were only calculated
per buffer period. At the moment there is no external access to these buffers
but that would be a pretty cool capability, especially with something like the
ARP 2600 - let it feed some different signals into the cabling system.

Hotmail: Trusted email with powerful SPAM protection.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20100218/d1d3ea2b/attachment.html>

More information about the Linux-audio-dev mailing list