9 Oct
2004
9 Oct
'04
11:27 a.m.
Hello,
Is there any way to stop qjackctl from re-ordering a client's ports
in its connection dialog ? IMHO the author of a client probably had
her/his good reasons for the order chosen, and qjackctl should leave
this alone.
--
FA
9 Oct
9 Oct
2:50 p.m.
On Sat, 9 Oct 2004 15:13:16 +0200
Fons Adriaensen <fons.adriaensen(a)skynet.be> wrote:
Hello,
Is there any way to stop qjackctl from re-ordering a client's ports
in its connection dialog ? IMHO the author of a client probably had
her/his good reasons for the order chosen, and qjackctl should leave
this alone.
what order? afaik there's no guarantee made by jackd to present lists of
client ports in a particular order.
flo
3:20 p.m.
On Sat, Oct 09, 2004 at 06:48:29PM +0200, Florian Schmidt wrote:
On Sat, 9 Oct 2004 15:13:16 +0200
Fons Adriaensen <fons.adriaensen(a)skynet.be> wrote:
Are you sure about this ? How then are apps like qjackctl supposed to
list them in any logical order ? Alphabetical sorting will work in
some cases, but produce horrible results in others.
At least jack_lsp seems to list ports in the order they were created.
The practical problem I'm facing now is with multiple stereo outputs.
You'd expect L1, R1, L2, R2, etc. but qjackctrl first gives you all
the left, then all the right outputs.
--
FA
Is there any way to stop qjackctl from
re-ordering a client's ports
in its connection dialog ? IMHO the author of a client probably had
her/his good reasons for the order chosen, and qjackctl should leave
this alone.
what order? afaik there's no guarantee made by jackd to present lists of
client ports in a particular order.
4:04 p.m.
On Sat, 9 Oct 2004 19:05:31 +0200
Fons Adriaensen <fons.adriaensen(a)skynet.be> wrote:
i think the order is just implicitly given by the order of the creation. The
api docs themselfes don't seem to make this garantee though, thus one cannot
rely on it. Maybe it would be good though if the api docs made such a
garantee. As i can see there's no "correct" order right now.
what order?
afaik there's no guarantee made by jackd to present lists of
client ports in a particular order.
Are you sure about this ? How then are apps like qjackctl supposed to
list them in any logical order ? Alphabetical sorting will work in
some cases, but produce horrible results in others.
At least jack_lsp seems to list ports in the order they were created.
The practical problem I'm facing now is with multiple stereo outputs.
You'd expect L1, R1, L2, R2, etc. but qjackctrl first gives you all
the left, then all the right outputs.
This could be overcome by using 1L, 1R, 2L, 2R, etc.
flo
7:22 p.m.
Florian Schmidt wrote:
Fons Adriaensen wrote:
Qjackctl uses a custom sorting method, something like "natural order" you
find in some database systems. In summary, it's plain alphabetic order,
but numbers are sorted in decimal numerical order (e.g "a10" comes after
"a2", when in ascending order).
This has been a fixed'n'old feature on qjackctl's connection port list,
ever since, and has been like that exactly by user request. You can check
the suggested convenience from this ordering scheme when looking to
ardour's port list, specially when you take it to real use and have plenty
of tracks/busses ;)
Florian's suggestion makes sense, of naming the ports like something in
the lines of:
out_1L
out_1R
out_2L
out_2R
at least to me. Now only if a client author's would find it appropriate ;)
Take care,
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
what
order? afaik there's no guarantee made by jackd to present lists
of client ports in a particular order.
Are you sure about this ? How then are apps like qjackctl supposed to
list them in any logical order ? Alphabetical sorting will work in
some cases, but produce horrible results in others.
8:03 p.m.
On Sat, Oct 09, 2004 at 10:03:11PM +0100, Rui Nuno Capela wrote:
Florian's suggestion makes sense, of naming the
ports like something in
the lines of:
out_1L
out_1R
out_2L
out_2R
I tried a number of different schemes, and here are the results:
(creation order 1L, 1R, 2L, 2R, ....)
-> 4L 3L 1L 2L 2R 4R 3R 1R ????
-> out1L out2L out3L out4L out1R out2R out3R out4R
-> out_1L out_2L out_3L out_4L out_1R out_2R out_3R out_4R
-> out_L1 out_L2 out_L3 out_L4 out_R1 out_R2 out_R3 out_R4
So none of them is really satisfactory, and this is only a simple case.
Things wil get worse for Ambisonics signals . For first order, the signals
are conventionally named W,X,Y,Z, in that order, and they need to be kept
together, just as the components of an RGB signal. For second order B-format
which uses 9 channels, the names are even no longer in alphabetical order.
Since jackd seems to maintain the creation order at least for clients
that create their ports once and never modify them afterwards (it would
probably take extra code to change that :-), I feel qjackctl should at
least offer the option to keep them in that order.
For clients that add and remove ports while running, a special API to
jackd should be defined to allow them to specify grouping and ordering
of ports. None of this should depend on a viewer, as it just doesn't
have the necessary info to get this right except maybe in some simple
cases.
--
FA
10 Oct
10 Oct
8:46 p.m.
Fons Adriaensen wrote:
Rui Nuno Capela wrote:
Yes, you're right. Sorry. And only now I see that qjackctl's jack port
list sorting is somewhat flawed, and has been like that for quite a long
time.
Nevertheless, I'm really glad you noticed and insisted on the matter, Fons.
In fact, even my suggestion of numbering ports like out_1L, out_1R, ...
doesn't come right either, as you've verified.
I though the correct sorted output should be:
out_1L
out_1R
out_2L
out_2R
but it actually comes like this:
out_1L
out_2L
out_1R
out_2R
so I think I gotta review the code, as it doesn't obey the "natural" order
I've mentioned earlier which I guess as being the consensual one to do.
I think you shouldn't bother on jack maintaining any guarantee on port
ordering, as clients might be quite dynamic in general, when regarding
port (de)registering.
Bye now. But I'll be back...
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
Florian's suggestion makes sense, of naming
the ports like something in
the lines of:
out_1L
out_1R
out_2L
out_2R
I tried a number of different schemes, and here are the results:
(creation order 1L, 1R, 2L, 2R, ....)
-> 4L 3L 1L 2L 2R 4R 3R 1R ????
-> out1L out2L out3L out4L out1R out2R out3R out4R
-> out_1L out_2L out_3L out_4L out_1R out_2R out_3R out_4R
-> out_L1 out_L2 out_L3 out_L4 out_R1 out_R2 out_R3 out_R4
So none of them is really satisfactory, and this is only a simple case.
11 Oct
11 Oct
9:38 a.m.
Hi:
OK. I've revised the sort comparison code for the audio connections port
list on qjackctl and the news are that it's been completely rewritten. Now
the "natural" order scheme is really implemented, or so I think :)
That makes the following example /always/ shown in this so-called natural
order, independently of client port registering order:
out_1L
out_1R
out_2L
out_2R
...
out_9L
out_9R
out_10L
out_10R
...
Check it out from qjackctl CVS. If nothing gets in between, I'm thinking
releasing this as qjackctl 0.2.12a soon.
Cheers.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
12 Oct
12 Oct
1:52 p.m.
On Mon, Oct 11, 2004 at 12:19:28PM +0100, Rui Nuno Capela wrote:
OK. I've revised the sort comparison code for the
audio connections port
list on qjackctl and the news are that it's been completely rewritten. Now
the "natural" order scheme is really implemented, or so I think :)
Great ! Fast turnaround seems to be a feature of this list :-)
--
FA
7560
days inactive
7563
days old
linux-audio-dev@lists.linuxaudio.org
8 comments
4 participants
participants (4)
-
Alfons Adriaensen -
Florian Schmidt -
Fons Adriaensen -
Rui Nuno Capela