Add a save action for client and server with a keyboard shortcut

[newlaurent62]

Hello,

It would be nice to implement a save option in addition to the signal interrupt on Unix like

For client:
Ctrl+s to save settings

For server:
Ctrl+s to save settings and write an intermediate reaper file (and continue to record in the same reaper file that will be overwrite if another Ctrl+s or save action is called or server is stopped.

BR,
Laurent

[pljones]

The server has a settings file, just like the client, so Ctrl-S would do the same thing on both.

There could be a shortcut for the new "New recording" button, though. Ctrl-N?

[newlaurent62]

Yes,

Ctrl+s to save settings

Ctrl+N to create a new recording (i don't know if this is standard but it is used by audacity to create new file) also Ctrl+N is used on Jamulus client to sort the mixer on 3.5.6 so ...

and Ctrl+Shift+s to create an intermediate project file (without cutting or creating a new record, just save the RPP project with the current state and backup the old one if it exists like reaper does when saving a reaper project).

I have found that having one RPP file with a long session is sometime more workable than having a lot of different project even if it is longer to load ... (at least for my use)

[pljones]

and Ctrl+Shift+s to create an intermediate project file

That's what New Recording / SIGUSR1 does and what Ctrl-S would (as it would be a shortcut for New Recording).

[newlaurent62]

That's what New Recording / SIGUSR1 does

I don't think so, New Recording creates a new directory with new wav files.
What i would need is

• to write a new reaper file in the current recording directory
• renames the old RPP with a new extension .RPP.backup-$(datetime)
• continue to append recording to the current wav files.

until New Recording is pressed or SIGUSR1 is sent.

Am i right ?

[pljones]

Sorry, no. SIGUSR1 starts a new project from the current time. That splits the WAV files. If you want a new project, that means a new set of WAV files to me - i.e. you've started a new song, for example, and may want to process the files differently even. For the same reason, it starts a new directory.

[corrados]

@newlaurent62 Let's discuss the use case of storing settings. And let's focus on the client only for now:
The typical use case is that you have a Jamulus client running and have all your audio/network/profile settings set correctly. If you now close the client and re-open it, you will have all your settings recovered. Why do you then need to store/load the settings during a Jamulus session? Is it just to store/load fader/pan settings like in #377?

[newlaurent62]

When using a session manager, there are four actions to handle:

1. Open Jamulus
2. Save Jamulus state without quitting (Ideally SIGUSR1)
3. Quit Jamulus without saving state (Abort) SIGKILL
4. Quit Jamulus kindly (save state) SIGTERM

We are talking about client settings but this could apply to server settings too.

I use RaySession as session manager available on Linux.

===

Considering a concert streaming : Each musician is connected to Jamulus and an additionnal Jamulus client (called "Streamer") will handle the output streaming mix of the musician playing and will be send to a social network or icecast2 using OBS.

The store/load of fader/pan mixers is intended to help handling the streaming of a Jamulus concert. This would allow to prepare each song settings before the concert begins and recall them as needed during the concert. An easy and fast action to store/load would be preferable. Closing the Jamulus client should not be needed.

May be, it would be better to let the user dispose of a jack client with a port for each channel from the server or a special client to the server with an output jack port for each channel. This would allow to put some VST/LV2 on channels and making sub groups for a more complex mix in a DAW that otherwise would be impossible.

===

So save client/server settings and the store/load of faders/pans are two distinct needs.

[corrados]

a special client to the server with an output jack port for each channel. This would allow to put some VST/LV2 on channels and making sub groups for a more complex mix in a DAW that otherwise would be impossible.

This is covered by the following Issue: #96

We are talking about client settings but this could apply to server settings too.

I don't see a need for this for the server. So let's focus on the client usecase here.

This would allow to prepare each song settings before the concert begins and recall them as needed during the concert

Ok, so this is the "store/load of faders/pans" usecase. This is useful, agreed.

When using a session manager, there are four actions to handle:

Please give me further details about this usecase. Your session manager supports four actions. But the question is if they are useful in the context of Jamulus usage.

Not long ago pljones supported that the client settings are stored correctly on a SIGTERM. This should be sufficient. I do not see a need for intermediate settings storage (other then the "store/load of faders/pans" usecase discussed above).

[newlaurent62]

Not long ago pljones supported that the client settings are stored correctly on a SIGTERM. This should be sufficient. I do not see a need for intermediate settings storage (other then the "store/load of faders/pans" usecase discussed above).

You might be right.

However, the aim of this functionnality (Jamulus state/settings save) is to save the current state and come back to this state when restarting the session. When creating a snapshot with RaySession (all state are saved and state/configuration files are versionned), you can also do some stuff and come back to a previous snapshot if needed. Someone could find this functionnality useful. Without the save state functionnality, it's not possible to create a snapshot of Jamulus settings.

Force the user to close Jamulus to save settings can generate some noise or Xruns with Jack when stopping and restarting Jamulus. And the jack ports have to be reconnected ...

[corrados]

the aim of this functionnality (Jamulus state/settings save) is to save the current state and come back to this state when restarting the session.

Are you referring to the "store/load of faders/pans" usecase?

[newlaurent62]

In my mind, the Jamulus state is the Jamulus client settings. (the ini file)

[corrados]

Ok, so what settings other than the "faders/pans" are of actual interest? I guess you are running the session on the same PC so the audio/network jitter buffer settings should remain the same. Are you interested in changing your profile information? This should not be done since, e.g., the profile name is the key to all the "faders/pans" settings. If you change the name, for the other clients the recovering of settings would not work anymore.
So, what settings do you need for your new session?

[newlaurent62]

If you change the name, for the other clients the recovering of settings would not work anymore.

Thanks for this information. I was not aware of that.

The Jamulus session information i can think of are:

• server / port (actually set from command line)
• profile name ... (profile name set in the ini file)
• nojackconnection (actually set from commandline) [ The audio applications are connected by the session manager e.g. RaySession ]

These are the minimal information needed to restart a Jamulus session.

[corrados]

server / port (actually set from command line)

Hmm, I am not sure how this should work. Do you mean that the Jamulus software auto-connects on startup? This cannot be store in the normal settings file since this would mean you would always automaticall initiate a session on startup which is not wanted. We have the -c command line argument for that. So no need for settings storage here. Or have I misunderstood your request?

profile name ... (profile name set in the ini file)

As I wrote, it is not wise to change the profile name. Why do you have to change it in between sessions?

nojackconnection (actually set from commandline)

This is something which does not make sense to include in the normal settings. Since the jack connections are only set when Jamulus starts up. If you would have a setting for that in the GUI, it would only be applied on a re-start of Jamulus. A better way would be to do the jack connections completely outside of Jamulus. You could either use the --nojackconnection command line argument of Jamulus or alternatively you could make Jamulus its connections but disconnect these with another tool and set the correct connections. I did this once in a script and that worked just fine.

[newlaurent62]

I misunderstood the question.

When i start a new session: i need server/port, profile name and nojackconnection

But i have no example for the need to change those settings or other existing settings after the session start except for faders/pans which are apart from our discussion.

[corrados]

But i have no example for the need to change those settings or other existing settings after the session start

Same with me. I also do not see a need to support this.

So maybe we should focus on #377 which definitely has a usecase and maybe close this Issue and maybe also close #294. What is your opinion on that?

[newlaurent62]

Allright, we can close #294.

for #377, now, i doubt that this feature has to be implemented in Jamulus. #96 could be more useful if efforts have to be put. It would allow to use a DAW or a mixer application to create a real mix with VST/LV2 effects thanks to Jack. What is your vision for Jamulus ?

[newlaurent62]

#146 sounds more related to a DAW collaboration than #96

[corrados]

for #377, now, i doubt that this feature has to be implemented in Jamulus.

#377 is useful if you have, e.g., a choir and you are changing a lot of things like volumes, pan and grouping. You could then store that setup and send the setup file to all the other choir members. Then all have the same mix.

And also what you wrote above: "This would allow to prepare each song settings before the concert begins and recall them as needed during the concert"

#96 could be more useful if efforts have to be put.

My opion to #96 is that Jamulus is not the right tool for this. If you want to get all the streams, you should use a jamming tool which uses peer-to-peer connections like Jamkazam or Soundjack do.

[corrados]

@newlaurent62 You closed this one but immediately re-opened it again. I think it should be closed. Do you agree?
BTW, #377 is implemented now.

[newlaurent62]

I closed it accidentally. But agree to close it now.