On Fri, Aug 16, 2024 at 10:24:10PM +0200, Wim Taymans wrote:
(sorry, I'm on holidays and not really much on my
computer)
I don't want to spoil you holidays ! Anyway I'll be in holidays
myself in a week, so all of this will have to wait until late
September.
But meanwhile I'm more confused than ever.
You last remark:
For linking ports, you can use any of the jack tools
you probably
already use (jack_matchmaker) or jack_connect.
seems to suggest that you think that I want to use PW's Jack emulation.
That is not the case. I want to run all native Jack apps in Jack2, and
use the 'Jack Tunnel' to allow all others (e.g. a video conference app)
to connect to Jack. Or to route Jack signals to a bluetooth device.
Creating ports on a sink/source is part of the session
manager policy.
More precisely as part of the linking policy.
I really fail to understand this. If a sound card or app has N inputs
why should it ever have any other number of input ports ?
Unless a 'port' can represent more than single signal, e.g. a group
of signals that should always used together. Simplest example would be
a stereo 'port' with L and R signals. But then I'd expect such groups
be defined by the application. For example my Tetraproc Jack app has
8 inputs but logically these are 2 groups of 4: one Ambisonic A-format
input and B-format input. It makes no sense at all to group them
otherwise, nor to swap or combine signals within each group. So it's
certainly not up to a session manager to define this - it's fixed by
the app's function.
Of course in the Jack world such groups don't exist - only the port
names can be used to 'suggest' them. So at least for the Jack Tunnel
the only interpretation that makes sense is that each port represents
a single audio signal. Is there any way to set the port names, or at
least to have generic ones (numbered, starting at 0 or 1 - both make
sense depending on the situation) ?
Another mystery is the difference between context.modules and
context.objects. I used to think that the modules section somehow
defines what sorts of objects are available (by loading the code
required to create them), and the objects section actually creates
them. But that is obviously not true: the modules section contains
actual parameters for objects. And in my config I have the Jack
Tunnel in context.modules only and coppwr shows it is created and
even 'Running'.
But where should these things go in the config file ? I tried
a lot possible variations in my config file, it didn't make any
difference. That's a general problem: which properties/options
are available and where should they go ?
Finally, if that is the only solution, I could create my own
'session manager' that would just support what I need and
probably could be relatively simple. If all it takes is handling
and sending POD messages it can probably be done in Python.
Ciao, enjoy the holidays ?
--
FA