rncbc
Please allow meta data JACKEY_ORDER to order ports
Please allow meta data to order ports in your patchbays, both the old one as well as the graphical.
https://github.com/drobilla/jackey/blob/master/jackey.h
/**
Order for a port.
This is used to specify the best order to show ports in user interfaces.
The value MUST be an integer. There are no other requirements, so there may
be gaps in the orders for several ports. Applications should compare the
orders of ports to determine their relative order, but must not assign any
other relevance to order values.
*/
#define JACKEY_ORDER "http://jackaudio.org/metadata/order"
Not sure what is intended here. Which applications are actually using this jakey thing?
Qjackctl already sorts port names by its original registration name (Connections and Graph) or their metadata pretty-name/aliases (Connections only).
Sort order has been natural alphanumeric/decimal order so that eg. "2" precedes "10" .
This would be a way for programs (DAW, Sequencer etc) to sync their own interal track order with sorted order in QJackCtl.
I am planning to use this KEY in Patroneo and Laborejo.
Please explain. It is anywhere clear why a DAW is not responsible for its own naming of registered ports.
You seem to suggest that an user of those applications might have a different choice. Yes he/she might, but...
However I'm still not sure why Qjackctl has to be involved on this call.
Again, please, elaborate.
Gladly, here is an example: In your DAW/Sequencer you have four tracks: {Voice, Guitar, Bass, Drums} or {Violin I, Violin II, Viola, Cello}. These are in a musical order, not alphabetical. From high to low, from foreground to background, your call. Also, scale that up to any number of tracks to your liking, imagine a full orchestra, which has a traditional sorting order as well.
If you want to connect these tracks via JACK and open QJackCtl, they will be presented in alphabetical order, which requires a mental context switch and searching around, both are bad for the workflow.
The clean mechanism to establish the same musical order in QJackCtl, or any other patchbay (I've submitted this request to falktx as well) is to use the metadata index key for sorting. Or is there another proper method I'm not aware of?
If your DAW (or sequencer, whatever) registers and names JACK ports on each track, why not naming those in some sequential order, like "Track_1", "Track_2" etc. instead. ?
What you ask is reasonable, but somewhat an overshoot: you have to manage on both sides the index order (one at the application side and two on the patchbay side as well); why not solving that for once and only at the source (meaning the application only)?
If your DAW (or sequencer, whatever) registers and names JACK ports on each track, why not naming those in some sequential order, like "Track_1", "Track_2" etc. instead. ?
Generic names like Track_1 or just numbers 01 are very hard to read. For me this would be even worse than properly named ports but in the wrong order. Now you, the human, has to remember what number is what track.
On top, if you change the track order in your program by moving one up or down all subsequent tracks will be renamed as well, if they follow a number pattern. Even if you memorized that "Track_2" is "Guitar" now everything has changed completely.
Generic names like Track_1 or just numbers 01 are very hard to read. For me this would be even worse than properly named ports but in the wrong order. Now you, the human, has to remember what number is what track.
But isn't what you wanted in the first place? You don't want to remember the actual names but the order that is listed in the connections manager? You may also know that port names are "machine" names while track names might be something for human eyes only.
order based on port-name can work only if the user never changes the order of the tracks. which implies newly added tracks with ports will always have to be at the bottom, no? or be very careful about naming of the ports to ensure the correct sorting.
also, manual order of existing ports just seems impossible.
if port has JACKEY_ORDER metadata
order according to atoi(metadata value)
else if port has PRETTY_NAME metadata
order according to strcasecmp(metadata value) (and properly handle numerals in names)
else
order according to port strcasecmp(name) (and properly handle numerals in names)
endif
This should solve all cases, shouldn't it ?
@ventosus, qjackctl/Connections already implements the p-code above, all but JACKEY_ORDER; qjackctl/Graph always list ports by their registration name; both handling numerals in names properly.
To let you all be on same slate, we have currently two (2) overlapping sort orders (registered port-names and metadata pretty-names); and yet you're proposing a third one and one as a top priority, which is not even on jackaudio.org spec.
please either stop or make it into jack.h headers as standard.
Don't worry, I will make these properties part of the JACK API soon enough :)
@falktx, sure, thanks. until then this issue will be put on hold. sorry @diovudau ;)
As of https://github.com/rncbc/qjackctl/commit/0ae45fe, there's this new View > Sort sub-menu in the Graph window, letting to choose the port sorting order on each node (client).
The current available options are Sort / Port Name (registered port name) and Sort / Port Title (metadata pretty-name, if any); also you can opt whether ports are listed in Sort > Ascending or Descending orders. All View / Sort options are saved to config file.
So that makes it for now: until that JACKEY_ORDER or its carved in stone definition makes it like "Sort > Port Index" in the hopefully not too far future. ;)
Cheers
As of https://github.com/rncbc/qjackctl/commit/7a0289f, preliminary JACKEY_ORDER support has been added for Sort / Port Index, falling back to be the same as Sort / Port Name as no client is known to use that thing yet.
ps. applies to the Graph only, of course.
I can confirm it works. Thank you for implementing it. Do you have any plans to make it work in the default connection bay? Because that is what most people use, I think.
We could also discus if that shouldn't be the default sorting mechanism. I think it should be.