While I get where you're coming from, those using QEMU with Jack are
already advanced users that are used to reading technical documentation.
Having our one client do something that is unexpected/different would
not only confuse existing Jack users but also anyone following any
guides/documentation on how to use a generic jack client. IMO the better
solution here is simply better documentation, perhaps even a known
working sample setup.
On 2021-02-25 09:33, Christian Schoenebeck wrote:
On Mittwoch, 24. Februar 2021 23:04:47 CET Geoffrey McRae wrote:
This goes against how all standard jack clients work, a new jack
client
should not auto-connect at all unless explicitly configured to as if
there is an existing audio diagram configured (which is 99% of the
time)
it will cause unexpected/undesired behavior.
Jack is not supposed to be an 'automatic' system, it's the
responsibility of the patch bay software to route connections.
The auto-connect feature exists to allow the jack audiodev to
re-connect
a broken connection when the jack device restarts/reconnects.
Well, that was also my idea first, and I would agree with you in case
of a
regular music app of course, but then I thought QEMU is probably not an
average JACK client, and it simply lowers the entry level for new users
who
probably just want to output to system out anyway.
I mean, are you piping QEMU into Ardour or something Geoffrey?
This could still be overridden by passing a bogus pattern with argument
"connect-ports" for people who prefer the patchbay approach in the end.
Sorry but this is a kludge to reverse another kludge, I really don't
think this is a good way to go.
So I would vote for the "make it easy for newbies" approach in this
case, but
I leave that up to you and Gerd to decide. :)
Best regards,
Christian Schoenebeck
