30 Jul
2005
30 Jul
'05
10:30 p.m.
On Sunday 31 July 2005 01:05, Paul Davis wrote:
and here i am, pointing out a disadvantage of this concept :/
exactly these 26/12 outputs are the main outs. the same thing could btw be
done with the main ins as well.
in terms of the jack api, i could also call them ports with the hardware flag
set. most jack programs automatically connect to the first hardware ports
available, as far as i mentally gathered.
"naaaa" "naaaaaaaaaaaaaaaa" "hm ... na." "but..."
"SHUT UP!" "ok" :P
--
-- leonard "paniq" ritter
-- http://www.paniq.org
-- http://www.mjoo.org
based on the
current layout of jack, writing an application that has an
effect on all sound streams generated looks a bit hacked:
of course, because if the user didn't route them through a single point
of control, then there is no single point of control - this is
deliberate, its not an error or an oversight. this mixer
application would have to plug itself to the main outs and sit
idle waiting for new connections. when a new connection connects itself
to the main outs, the mixer app would disconnect the ports and reconnect
them to the in-ports of the mixer application.
"main outs"? what are they? my RME interface has 26 outputs. a delta
1010 has 12. what are "the main outs" ? instead, what
about a final amp routine within jack that reads its amp
value from a float shared in memory. other apps could read from/write to
this float, and synchronization does not matter in this case.
this was discussed at length during the design of JACK and rejected by
almost everyone.