4 Feb
2008
4 Feb
'08
12:37 p.m.
Jonatan Liljedahl:
Yes, as long as JackPortAutoConnect is false by default, that's
definietely a sane solution. Its basically the same kind of
proposal I made, just using a flag to jack_port_register
instead of a new function.
But there is one problem with it:
jack_client_t *client=...
jack_port_t
*out_port[0]=jack_port_register(client,...JackPortAutoConnect);
jack_port_t
*out_port[1]=jack_port_register(client,...JackPortAutoConnect);
<something happens>
jack_port_t
*new_out_port[0]=jack_port_register(client,...JackPortAutoConnect);
jack_port_t
*new_out_port[1]=jack_port_register(client,...JackPortAutoConnect);
The problem is that new_out_port[0] and new_out_port[1] will
connect to physical port number 2 and 3 instead of 0 and 1.
How do you fix this problem without adding a new function to jacklib?
Thanks for clearing up. But I'm pretty sure your idea is too
simple. We also need a way to create ports which are not
autoconnected.
The ideal way, if we follow this thread of thinking, would
be to add another type of jack_port_register function, which
does not autoconnect:
jack_port_register_no_autoconnect(client,...);
However, this new API will break a lot of current programs
which are using the old jack_port_register function instead.
Infact I don't think there is any (sane) way to make your
proposal work without creating lots of mess with ports
in old programs who are autoconnecting when it shouldn't.
I think my proposal with a JackPortAutoConnect bit in JackPortFlags is
sane, it would not break old applications; they would continue to
function exactly as they are now. but updated code can get rid of their
own autoconnection and use this autoconnect bit in the flags to
jack_port_register() instead.