changing label, looses match with name in patchbay

[grammoboy2]

It is possible to rename the client label in raysession. Drawback of it as far as I can see, is that the names in the clientslist of raysession and the patchbay doesn't match anymore. In agordejo this is also the case, but there is still a match between the id's (all though not with a easy overview).

In Agordejo it is only possible to rename the name of the client if I'm right (clientOverrideNames). Raysession seems to display the label as the name, which can be renamed. In Agordejo the label (send by the client) can't be renamed it seems.

Intuitively I would probably expect that the NSM gui, shows the custom label instead of the label (if there is any) send by the client, when a user would edit the label in the gui (more a clientOverideLabels). The NSM gui could still show the label instead of the name (as raysession is doing). Hm this needs some thinking here... *

The drawback of renaming the name of the client is also mentioned here, where also the GUI states are discussed (see other issue). You had the same questions apparently.

https://www.mail-archive.com/non@lists.tuxfamily.org/msg00455.html

• edit: api wise there might be or can arise a prioritize conflict between label send by client and label set by user I can imagine.

[Houston4444]

a client can have:

• label (defined by the user, the client itself (rarely) or the daemon if it comes from the .desktop file)
• name (defined by the client)
• executable

What is displayed as name is the label it if exists, else name, else executable.

Drawback of it as far as I can see, is that the names in the clientslist of raysession and the patchbay doesn't match anymore.

Not very strong, let consider user as adults. For a very short time, click on a client widget in the list selects one of its JACK boxes (and vice versa).

Intuitively I would probably expect that the NSM gui, shows the custom label instead of the label (if there is any) send by the client, when a user would edit the label in the gui (more a clientOverideLabels). The NSM gui could still show the label instead of the name (as raysession is doing). Hm this needs some thinking here... *

I must confess that this is a question I haven't thought much about, except nsm-proxy (and old ray-proxy), I don't know any client using the /nsm/client/label message. I would be happier if this thing does not exists TBH, I could simply not use it in the GUI.

[grammoboy2]

I'll respond on your message on a later moment, but on that mailinglist you also mention jack metadata.

"Jack has pretty names / meta data. Metadata can be set by any client, not only from the client within. NSM could set Jack Metadata. However, since I know that you don't want to tie NSM into JACK this could be done by specific client, like jackpatch. That would still require the editable string mentioned above. "

I'm able to rename JACK ports and see the name change appear in Patchance, I'm also able to rename 'main-client-name' of Carla, but then the name doesn't change in Patchance. Would it be possible to do this, either by exclusively the client itself or by the client and any other application, so the rename shows up in Patchance?

[Houston4444]

on that mailinglist you also mention jack metadata.

That's not me !

I'm able to rename JACK ports and see the name change appear in Patchance, I'm also able to rename 'main-client-name' of Carla, but then the name doesn't change in Patchance. Would it be possible to do this, either by exclusively the client itself or by the client and any other application, so the rename shows up in Patchance?

You mean you set jack pretty-name metadata to the carla client ? It is not used yet in HoustonPatchbay, it is possible yes, but I think it is impossible to know who sets the metadata unfortunately. It is the main reason why I didn't implement any GUI method to rename ports in patchbay, because if names are not permanent, I think it is a semi-feature, I have to think about how to implement this to be not prior over a client renaming its ports.

[grammoboy2]

To understand why the 'label api' is as it is, one must also understand the JACK api probably.

I think this is a important quote from the original developer:

"Architecturally, I prefer for all state to be in the client's own project format."

There is some confusion about JACK metadata. Is it possible to rename the name of the client in the patchbay using JACK metadata or can it only rename ports?

This seems to suggest it is possible, but the API only talks about ports I think. "Allow to set the JACK_METADATA_PRETTY_NAME of jack_mixer's JACK client, so different instances of jack_mixer can be identified better in a JACK patchbay" https://github.com/jack-mixer/jack_mixer/issues/55

It is possible to rename the client when using JACK2: "and JACK2 introduced the possibility of client name changes too" https://jackaudio.org/metadata/

I guess this is what Carla and Non-Mixer are using, when Carla is renaming the plugin as JACK client and Non-Mixer the mixer strip as JACK client? (All though the 'main name', Carla, Non-Mixer, stays the same.)

If one can't rename a client in the patchbay using JACK metadata, but one can rename the client in JACK2 in the client itself, then this is probably the explanation why NSM expects the initiative of the names and labels coming from the client itself and why it doesn't store it in the session file.

Would be helpful if you could take away the confusion about JACK metadata.

edit: pretty-name for clients seems to be possible, qjackctl displays it.

[grammoboy2]

Not very strong, let consider user as adults. For a very short time, click on a client widget in the list selects one of its JACK boxes (and vice versa).

That's a feature which makes it easier indeed, but when you use patchage or especially njconnect, then it becomes really problematic. But even in raysession I find this mismatch not ideal.

I must confess that this is a question I haven't thought much about, except nsm-proxy (and old ray-proxy), I don't know any client using the /nsm/client/label message. I would be happier if this thing does not exists TBH, I could simply not use it in the GUI.

In nsm-proxy I find it pretty convenient to add the label at launch. It's also possible to copy a predefined nsm-proxy folder into a other session (with gmidimonitor for example), including the label. Fluajho is sending a empty label, I thought it was done to clean the label, but I can't make Fluajho send other labels. Maybe that was a previous design? Or did JACK metadata solved it for Fluajho?

After thinking about it, I don't think it's wise to mix the label which comes from the client with a user defined label, one overwriting the other. That makes this api less clear and so I understand why Agordejo does overwrite the (pretty) names, instead of the labels, with the advantage that it keeps being compatible with the original sessionfile format. If I would put them in a sessionfile as Raysession does, I would use both as separated items I think. But I understand why NSM expects the labels coming from the clients, without storing it in the sessionfile. Moreover the JACK metadata might be the current way to handle labels and NSM doesn't want to be tight to JACK by design.

In a DAW the labels are in the tracks (and mixer strips). In the NSM environment the labels are in Non-Timeline and Non-MIxer or Carla. It can become less clear if there are multiple instances of the same application, but ideally multiple instances are not needed, this was also the opinion of 'male' iirc*. Non-Mixer itself does fix the label issue, by making each mixer strip a JACK client? Maybe he would have used JACK metadata if it was available back then. In a other modular environment, BespokeSynth, giving modules/plugins labels is not possible I think (maybe you can add text/comments?)

It would be interesting to know if there is still a 'label issue' for jack_mixer, or did JACK metadata solved it for them?** Now it's more easy to distinguish the different instances by pretty port names in the patchbay I guess. Then only stopping/removing in the NSM gui might give some confusion, but in RaySession that could be done in the patchbay maybe, telling the client to stop from the patchbay (resume and remove might be more complicated visually to enable in the patchbay GUI I can imagine, but could be a option as well).

• edit: Not sure if that's the right interpretation, quote from website: "If the user is allowed to run two or more instances of the application simultaneously (that is to say, there is no technical limitation preventing them from doing so, even if it doesn't make sense to the author)..."
• • edit: jack_mixer uses JACK to rename ports, not JACK metadata I suppose.

[mxmilkiib]

JACK Mixer is "JACK Mixer" in the applications section and "jack mixer" in the graph.

As noted, renaming something in the session applications list does nothing to the graph node title.

Why not keep them in sync? This would help resolve knowing which application to stop when the session gets busy. Having to click back and forth between items in the app list to watch for a border change on graph nodes is an extra step when the visual cue of graph nodes having the appropriate name removes the need for that thought and action.

[Houston4444]

I think the user must can rename a client "label" (what we see in clients list). RaySession is not only an NSM server, it can also launch other JACK or not JACK (possibly not audio at all) applications, for them we need a customizable name.

As noted, renaming something in the session applications list does nothing to the graph node title.

Now, in the "rename" dialog, there is an option to change the identifiant of the client (client must be stopped). It also renames the label to this identifiant, and the graph box should follow. I just tested it and I must say there is still a little problem, 'long jack naming' should probably be set to on when this action is done, else the JACK client name is the same, true.

[Houston4444]

(quoting myself)

Now, in the "rename" dialog, there is an option to change the identifiant of the client (client must be stopped). It also renames the label to this identifiant, and the graph box should follow. I just tested it and I must say there is still a little problem, 'long jack naming' should probably be set to on when this action is done, else the JACK client name is the same, true.

I just fixed this problem, now rename a client checking the identifiant change (in rename client dialog) always sets the jack_naming to 'long', so it changes it in the graph too.

[mxmilkiib]

Aah, I see the checkbox now, and have managed to rename something with the new name showing in both places. Thanks!

The workflow is a bit cumbersom though. How about having the checkbox by "Identifiant renaming (will save & restart client)"?

I'm still slightly confused as to what "identifiant" means (in more than one way); is that simply the RS name for the client? As in "identifier" (but somehow not "identity")?

For seq66, the app list shows Seq66 and the graph shows qseq66 (the executable name).

[Houston4444]

The workflow is a bit cumbersom though. How about having the checkbox by "Identifiant renaming (will save & restart client)"?

I perfectly agree, it is just more work ;) , I'll probably do it later.

I'm still slightly confused as to what "identifiant" means (in more than one way); is that simply the RS name for the client? As in "identifier" (but somehow not "identity")?

Ohoh, that is just a language error from me, "identifiant" should be "identifier", I don't know why, I was thinking it was the same word in french and in english, not at all. I have to replace all occurrences.

For seq66, the app list shows Seq66 and the graph shows qseq66 (the executable name).

the label in app list can comes from many sources, by priority order:

• label defined by user or RaySession templates factory
• Name from desktop file (can be localized)
• Name given by client via NSM protocol (OSC)
• Executable

If seq66 respects the NSM protocol, it should have the same name in the graph that this one given in client advanced properties (right click on a client -> Properties -> General Tab -> Advanced properties -> JACK Client). Oh, to check this, please uncheck "Use graceful names" options.

[Houston4444]

The workflow is a bit cumbersom though. How about having the checkbox by "Identifiant renaming (will save & restart client)"?

Finally, I have improved the action, now it restarts the client if it is started. More, if client can switch, it directly switches, so, even for Ardour, it's not very long (depends on the project size of course).

[grammoboy2]

I still think the way to solve this is by using JACK metadata. The label/ JACK metadata can then be set in Qjackctl (or potentially in Patchange). Storing and restoring can be done by a JACKPatch like application. For the NSM clients which are not JACK clients (and Multi-Jack-Clients like Non-Mixer), one can use the label feature in the NSM api, like NSM-Proxy is doing.

[Houston4444]

I still think the way to solve this is by using JACK metadata.

I can see some prioritize conflicts with Metadata use. What happens if a client auto writes metadata when the SM already has a different a value for the same key (probably written by the user).

The problem could be easily fixed showing the string that the program should use as JACK client name instead of label in app list, although I don't find this very pretty, especially for newbies, it could be a GUI option.

[grammoboy2]

I can see some prioritize conflicts with Metadata use. What happens if a client auto writes metadata when the SM already has a different a value for the same key (probably written by the user).

Currently this is only the case for pretty name metadata for JACK ports. I believe Fluajho sets JACK metadata for it's ports.

For pretty name metadata for the JACK client name, I don't known any application which sets the pretty name of the JACK client itself, or gives the user the possibility to set the pretty name metadata for the JACK client name in it's user interface.

As I'm mainly interested in the pretty name metadata for the JACK client name, not for it's ports, there is currently no problem. I'm not sure if this will ever become a problem, but it could in theory.

The NSM design(er) favors the fact that NSM clients restore their own data, so in that line, I would say, if the NSM client gives the user the option to set the metadata (from the applications interface), it is also responsible for restoring it (when under NSM). Then the data set by the JACKPatch like metadata client, will always be the same as the one from the client itself. But this certainly needs some thinking.

But again, currently this problem only exists in theory when dealing with JACK metadata for the client name. So if NSM clients (authors) leaves setting metadata properties (for JACK client names) to be a task of dedicated external JACK metadata applications (when under NSM), then there is no problem.

(By the way, it surprises me that the JACK metadata key for JACK ports is the same as for the JACK client name, namely JACK_METADATA_PRETTY_NAME. This means that any application which wants to set either pretty names metadata for only port names or only client names, needs to filter if it's dealing with a JACK port or a JACK client name first. Intuitively I would think that a different key for the pretty name of the JACK client name (JACK_METADATA_PRETTY_NAME_CLIENT for instance) would make sense. )