Jim Peters wrote:
> If you're designing a new plugin standard, can I throw a few ideas
> into the mix ? Here we go:
>
> - Intelligent handling of silence. Many plugins can completely skip
> processing a frame if there is silence on their inputs - they just
> need an easy way to recognise that.
in real-world audio files (i.e. all but computer-generated music),
there is no such thing as silence. there is always noise, and with
open microphones, there is an *important* ambiance component in the
moments where no intentional sound takes place.
plus i doubt that any ADC in the world will give you all-zeroes,
even when you shorten the input.
as a consequence, to implement your idea you need a noise-gate with
a threshold, which i think is a bad idea. when i gate, i do so
*intentionally* and *explicitly*. i don't want clever plugins to do
that for me.
hiss may be bad, but arbitrarily opening and closing gates and the
corresponding hiss rhythm is worse.
plus in a real-time environment, i don't think it's helpful to see
wildly varying cpu usage depending on the program material.
i'd prefer to see the worst-case usage all the time, so that i don't
overassign cycles and see drop-outs during a session.
<snip>
> - Upgradable control inputs. Control inputs often have constant
> values over the length of a frame, which makes processing more
> efficient. However, when control inputs change, if they change in
> steps you often get unpleasant side-effects. For instance, if it
> is an amplitude control, and it changes at the frame rate of 200Hz
> (say), then you are going to generate a 200Hz ripple, which is
> definitely audible. If you think you can improve this by increasing
> the frame rate, you just shift the frequency of it. The only answer
> to this is to change control inputs smoothly, at the sampling
> frequency.
i don't see all the implications of this, but it sounds desirable.
> - Command-string control ports. Strings are good - you can encode
> almost anything as a string. Commands to a plugin can be easily
> sequenced as part of a song or mix-down (the sequencer doesn't have
> to understand what the strings mean, just store them, and feed them
> to the plugins at the required moments). As a general type, it can
> cover a huge amount of stuff. If you're worried about the overheads
> of parsing strings, remember that these are likely to be coming in
> at the control-rate or slower. Worst case, we could give the plugin
> the opportunity to precompile command-strings before a sequenced
> song/tune starts. The flexibility this buys you is well worth it, I
> think.
this talk of control-rate sounds very csoundish to me. do protools
etc. actually have a control rate < sampling rate ?
--
J�rn Nettingsmeier
home://Kurf�rstenstr.49.45138.Essen.Germany
phone://+49.201.491621
http://icem-www.folkwang-hochschule.de/~nettings/
http://www.linuxdj.com/audio/lad/
