4 Apr
2012
4 Apr
'12
12:45 a.m.
On Tue, Apr 3, 2012 at 4:24 PM, Filipe Lopes <falktx(a)gmail.com> wrote:
hey lads,
sharing an idea I had here
my (currently in development) host directly exposes plugin ports to jack -
audio as audio, midi as midi, and parameters as a midi port for midi-cc
usage.
while coding for lv2 plugins, I noticed the CV port type, more info here:
http://lv2plug.in/ns/ext/cv-port/
I didn't yet coded support for it, but I'll do soon. Those kind of ports
will be exposed to jack as pure audio ports.
Non-daw and non-mixer also use this kind of ports, and maybe others.
The problem is that users shouldn't connect normal audio and CV ports
together...
so I came up with an idea that is simple and fairly easy to implement - a
new jack port flag.
example:
port = jack_port_register(client, port_name, JACK_DEFAULT_AUDIO_TYPE,
JackPortIsInput|JackPortIsCV, 0);
patchbays can check for this flag and represent the port as a different
type (I've done it here myself as jack keeps any custom port flag values I
set, and works just fine).
in the jack library code we can check for the flag and not allow port
connections.
what do you think?
BTW, SpiralSynthModular is another program that uses JACK audio ports for
CV.
Seems perfectly reasonable to me, although I would rather it be the
connection manager that disallows the connections rather than JACK itself.
Some users may have valid reasons for wanting to force a connection between
Audio and CV ports (such as sending an analog control voltage signal out of
the audio interface)... And consider the case right now for programs which
have not been updated to set the appropriate flag on their CV ports--those
connections would have to be forced until the programs are updated. But
even if the connection manager just used the information to display the
ports in a different color, it would still be useful. Also, obviously you
need a #define or something to indicate that the version of libjack has the
enum for CV ports.
As you point out, it's a very simple change and I think it's about time we
had *something* in place for this and in lieu of arbitrary port types and
data representations, this will certainly work for the CV case.