7 Jul
2011
7 Jul
'11
9:45 a.m.
On Thu, 07 Jul 2011 00:23:54 +0200, "rosea.grammostola"
<rosea.grammostola(a)gmail.com> wrote:
On 07/07/2011 12:10 AM, Rui Nuno Capela wrote:
qjackctl session manager saves and restores connections of all clients
event though clients aren't jack-session aware. upon session load,
connections are made if those client is already running or whenever it
gets started later on manually. as i often say, it just works like
qjackctl's patchbay "limited-edition" or w/e ;)
otoh, the auto-launch feature for non jack-session-aware clients would
be the primary purpose of the infra-client mapping on the
jack-session-manager side, right?
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
nope. qsynth has no jack-session support atm.
theres a couple of reasons that sets it back in that regard: qsynth
state is stored on a global user configuration file that doesn't
depend
nor change across sessions whatsoever. the other reason is that
qsynth
is a singleton. you can only have one instance running at anyone
given
time. starting a second instance just activates the first one. been
like
that for ages now, way before jack-session was ever the talk of the
town ;)
anyway, imo, the only advantage i can see to qsynth participate on a
jack-session would be its automatic launch on session load.
and the JACK connections. I can imagine that if Qsynth or app X has
its place between other JACK apps (which have JackSession support) in
a session, it would be quite cumbersome for making the JACK
connections, if that app X hasn't JackSession support (you could use
it as infra client maybe).