Custom JACK client/port names always written to global ray_canvas.json, not just the session

[zzzeek]

Hi -

I've been using RaySession for some months now and with increased use I find myself switching between multiple sessions that do entirely different recording configurations (one is for making drum cover videos, the other is for recording a band). I actually plug different cables into my focusrite 18i20 so I'm trying to have different labels in different sessions for things, but the labeling is coming out as effectively global and very difficult to maintain two different sets of labels. it seems sort of intentional maybe but im not sure how this is useful.

When you rename a JACK client or port in the patchbay canvas, the name gets saved to both the session-local .ray_canvas.json , and then it seems to stay persistent in RaySession and stays there when you close the session; it continues to persist when you open a new session, where it also prevents you from renaming anything you've named (this seems to be a different bug in HoustonPatchBay). When you close all of raysession it shows up in the global ray_canvas.json in the config directory.

This is with 0.17.4 and also 0.18.0 but I dont see any changelog or issue referencing this.

Using some tooling I identified in src/daemon/canvas_saver.py, the save_group_custom_name and save_port_custom_name both call save_group/save_port on both custom_names_config (global) and custom_names_session (session-local). it's not clear if this is the intent.

I can actually edit the global raysession file to remove the extra names there but things get kind of confusing when you do that since I dont think the tool was ever tested like that.

here's some screenshots to clarify what im doing:

1. an audio device

2. renaming one of the ports in the device (ignore that "jack pretty name" checkbox, I normally am unchecking that, which does not affect the behavior)

3. it's in session local .ray_canvas.json

4. after closing out raysession it's also in the global one

[zzzeek]

note I am also turning off that "JACK pretty-name metadata" checkbox, I know it's in my screenshot above, but the behavior of writing to both ray canvases is unchanged if you uncheck it

[Houston4444]

Hi ! Indeed, there is something inconsistent, and I see the impossibility to rename a group which already has a name, I will try to check it soon. Thanks

[Houston4444]

Hi! Sorry for the short answer and the delay, I really had no time at all at this moment.

So, there was a serious bug, it was impossible to change a custom name at all if the element already had one, affecting seriously what you was trying to do. This should be fixed now in git master (and next release of course).

Custom names are indeed saved in the session and in the config, it is intentional. This way, the config has the last modified (by user) custom name for an element. If you open a session where the custom name is affected and different, the custom name is used while the session is open, at session close, the element will be named with the custom name in config. In many cases, user will only want to set a custom name because the port/client name is too long or strange, if (s)he decides to rename it, it will be renamed whatever the session (except for sessions where this element already has another custom name) and it is clearly what user wants. This behavior does not prevent to set custom names depending on the session (as you want), for example to identify what is physically plugged to the devices.

[zzzeek]

if I set name X in session A, and name Y in session B, first off I guess that was not possible before with the "rename" bug that you've fixed. So we now can at least set the two different names like that. are you saying name X gets written to local and global session, then name Y...doesnt? how does that work?

[Houston4444]

are you saying name X gets written to local and global session, then name Y...doesnt?

No. If you set name X in session A, X will be saved in session and config, then if you set Y in session B, Y will be saved in session and config too (erasing X in config). But, if then, you load session A, Y will remain in config. The config has the last user modification. If then, you unload session, or load a session where the custom_name is not defined, it will be Y.

There's still one small problem that I may not have thought of. If user removes the custom name, load a session where it exists, and close the session, the custom_name is still here, I have to take a look if something is possible.