Subject: Re: [linux-audio-dev] A new audio plugin API ?
From: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Mon May 13 2002 - 21:51:31 EEST
On Mon, May 13, 2002 at 07:32:38 +0200, Dr. Matthias Nagorni wrote:
> On Mon, 13 May 2002, Steve Harris wrote:
>
> > > 6) Optional string array for integer ports (e.g. waveform: sine, saw, ...)
> > good idea, but not just for integer ports...
> For which ports else ? Toggles ?
Well, yes, I was just distinguishing from the (int) ports you mentioned
below.
> > > 7) Type of integer port int not float
> > Don't think it helps much, in some cases there is a fine line between
> > integer and non-integer ports, eg. "mode" of diode_1185
> It makes the code for the GUI routines simpler. If integer port variables
> are int, their pointer can be directly passed to the integer GUI element.
OK, I see why that helps, but I'm still not convinced.
> > There is possiblt some argument for labeling CV ports, or at least an
> > agreed on a standard scale (late CV was 1v per octave, with 1v=440 Hz
> > IIRC, so maybe 1.0f per octave, 1.0f=440Hz is good).
> The idea of directly using the old Moog-style CV has the advantage of not
> limiting the max frequency, so I like this idea. However, it will make
> these ports logarithmic.
Yep, well, the're pitch controls, and pitch is logarthmic (with respect to
frequency).
> What about the other ports ? Gate and Gain ?
> Some people might also want aftertouch.
I'm a modular synthesist at heart, so I don't like the idea of making
things like aftertough first class signal types. The aftertouch out on
the MIDI "module" could be wired to any input port on any module. Its just
a singal.
In my worldview there are only signals of n volts (float values in ladspa
land) and they can all be processed in the same ways. There are times when
it makes sense to run an audio signal through a logic module, or a CV
pitch signal through a ringmod.
> > This would also allow greater expressivity in categorising plugins, they
> > could be grouped by arbitrary criteria, and new classes can be created
> > and expressed at any time.
> OK, but don't forget that the data must be such that a host has a way to
> automatically create menus. The string categories I suggested could be
> directory-like, e.g. synth/organ
No problem, the steps of extracting a heircharchy from RDF aren't as
trivial as tokenising the string with '/', but its pretty damn easy.
function parse_class(rdf_class class, tree_node node) {
tree_node new_node = node.addItem(class.title);
for (var subClass in class.subClasses()) {
parse_class(subClass, new_node);
}
}
or something similar. And yes, I am prepared to write a wrapper library
around RDF that lets you do this stuff easily.
Advantages are that the class graph is extensible, and isn't confined
to a single tree structure natively, but can be flattened to one.
> What about the frequently discussed arrays ? I have seen from your code
> that you just use audio ports whenever you need arrays. I would prefer to
> distinguish between audio and control ports.
Yes and no, generally, where I have used audio ports, its because thats
what they are. There isn't really any difference between an audio rate
control port and an audio rate audio port. Sometimes it is helpful to mark
them as different, but you should never be prevented or discouraged from
wiring one to the other.
My prime example of this is the nord modular, which is a fantastic
instrument and allows you to wire any output to any input.
- Steve
This archive was generated by hypermail 2b28 : Mon May 13 2002 - 21:45:41 EEST