Mulitple supercollider instances (ALSA MIDI port | JACK client name, Linux)

flower · April 11, 2024, 11:43am

One issue I currently face when launching multiple instances of sclang via the command line (which boots scsynth) is connecting Midi ports on Linux using the patchbay (for flexibility), across different sessions.

Supercollider is using the same port names and ALSA is adding a port number to each instance [129] and [130] for example. But after rebooting the two instances of supercollider, the ALSA port numbers could be changed, to [134] and [135] or vice versa, for example. So a tool which tries to restore the MIDI connections, fails to do so.

Not sure how and if this could be solved, but I was thinking would it be possible to add a method to sclang (MIDIClient?) which allows you to set a custom ALSA midi port name? (Then the MIDI connection restore tool, should still do some regex to filter out the port numbers probably).

github.com

supercollider/supercollider/blob/28a0b12216fb97e4487373b2cf00a5ec28850f1f/lang/LangPrimSource/SC_AlsaMIDI.cpp#L630


      
          if (client->mHandle)
              return errNone;
          
          // initialize client handle
          if (snd_seq_open(&client->mHandle, "default", SND_SEQ_OPEN_DUPLEX, 0) < 0) {
              client->mHandle = nullptr;
              post("MIDI (ALSA): could not open ALSA sequencer: %s\n", snd_strerror(errno));
              return errFailed;
          }
          
          snd_seq_set_client_name(client->mHandle, "SuperCollider");
          client->mClientID = snd_seq_client_id(client->mHandle);
          
          
          // initialize queue
          client->mQueue = snd_seq_alloc_queue(client->mHandle);
          snd_seq_start_queue(client->mHandle, client->mQueue, nullptr);
          snd_seq_drain_output(client->mHandle);
          // snd_seq_set_client_pool_output(seqHandle, ??);
          
          // initialize event en-/decoders

Edit: Same is true for the JACK client name probably:

github.com

supercollider/supercollider/blob/28a0b12216fb97e4487373b2cf00a5ec28850f1f/server/scsynth/SC_Jack.cpp#L236


      
              if (clientName == nullptr) {
                  // no semicolon found
                  clientName = serverName;
                  serverName = nullptr;
              } else if (strlen(clientName) == 0) {
                  free(clientName);
                  clientName = nullptr;
              }
          }
          
          mClient = jack_client_open(clientName ? clientName : kJackDefaultClientName,
                                     serverName ? JackServerName : JackNullOption, nullptr, serverName);
          if (serverName)
              free(serverName);
          if (clientName)
              free(clientName);
          if (mClient == nullptr)
              return false;
          
          scprintf("%s: client name is '%s'\n", kJackDriverIdent, jack_get_client_name(mClient));

flower · April 11, 2024, 6:16pm

A ALSA MIDI client name could maybe be added to MIDIClient.init or as similar method (MIDIClient.initWithName)?

A JACK client name could maybe be set via a environment variable, as that is the way custom JACK settings seems to be handled.

smoge · April 11, 2024, 6:45pm

One could do that. “SuperCollider_1”, “supercollider_2” etc.

Or, you could have another process receiving all input control data, and rerouting freely to the other 2 processes, maybe via OSC. Maybe more flexible?

flower · April 11, 2024, 9:41pm

" NOTES

ALSA does not guarantee client names to by unique. I.e. it is possible to have two apps that create two clients with same ALSA client name. JACK however requires port names to be unqiue. To ensure this uniqueness, a2jmidid will add the unique numeric ALSA client ID to the JACK port name. However this behaviour is known to be problematic when restoring connections using simplistic tools like aj-snapshot and jack_connect. In order to make them work, the -u option can be used. This option will cause a2jmidid to omit the numeric ALSA Client ID from JACK port names. In this mode, ALSA client name uniqueness must be guartanteed externally."

So a2jmidid is adding the port id numbers.

A other solution would be to add JACK MIDI support to SuperCollider.

smoge · April 11, 2024, 11:22pm

It would be a good new feature.

jamshark70 · April 11, 2024, 11:53pm

Only if you’re explicitly requesting it by running a2jmidid yourself, but that wasn’t the case in the original post? Unless I’m missing something.

Yeah, the restriction to ALSA MIDI is occasionally uncomfortable. Adding (or switching to) JACK MIDI is likely to be a do-ocracy task though (it’ll happen when someone needs it, and does it, and puts in a PR).

hjh

flower · April 12, 2024, 8:13am

I think the easiest and probably the best solution now is to add support for a environment variable which (if available) sets the JACK client name and the MIDI client name (both are “SuperCollider” by default).

jamshark70 · April 12, 2024, 8:48am

These are two distinct things, though.

The JACK client name is for the server, and this is already set by s.options.device (documented here). So there’s no need for an environment variable, because it’s already configurable.

I’m not sure how MIDI clients appear in other OSes. Only Linux by default supports inter-app patching, so in Linux, apps must appear as ports. In MacOS, there’s IAC Bus; in Windows, loopMIDI. Certainly it’s possible to run multiple sclang clients in every OS, so, identifying multiple sclang MIDI clients could be a cross-platform issue. In that case, a language-side variable would make more sense, but this may need confirmation. (If this problem is specific to Linux, then I’d probably go with the environment variable – it wouldn’t make sense to add a MIDIClient.clientName for everybody, if it would be ignored in the vast majority of installations.)

hjh

flower · April 12, 2024, 9:13am

Oh nice, I didn’t knew that.

If you look at JACK clients which have session manager support on Linux (NSM, RaySession), they use the same client name for JACK as for the MIDI client name.

I think it makes sense to automatically use the same name for the MIDI client, as is set via s.options.device in supercollider to. So if you set the device name to “SuperCollider.drums”, your supercollider midi client name is also named “SuperCollider.drums”.

Having the same names will also be the case with JACK MIDI support probably, as the JACK client name is the same for audio as for MIDI then (same JACK client).

flower · April 13, 2024, 10:18am

What do you think @jamshark70?

A downside I can think of is that it might break some existing code of people who expect the MIDI client name always contains “SuperCollider”. But a custom device name can still contain “SuperCollider” of course.

jamshark70 · April 13, 2024, 11:49am

I have a bit icky feeling about that – coupling two entities that are not substantially related, but only in Linux (it would be 100% wrong in Mac and Windows to do anything like this), and only because of the accident that audio and MIDI connections can be made in the same JACK interfaces, doesn’t strike me as something to enforce as a default situation.

I think it would be fine if a user wants this to have a method in a linux/ directory that sets both the server device name and (future, after making it settable) MIDI client name to the same string.

hjh

flower · April 13, 2024, 12:30pm

I agree with this I think.

I’ve no clue about other platforms, but I would expect them to mirror the JACK MIDI situation, where the audio client is the same as the midi client, while with ALSA, midi is a other layer, which is typical Linux.
Renaming the device name doesn’t rename the MIDI client name in OSX/ Windows automatically?

It would be good to have that option, this is currently the biggest obstacle for me to run SC as some sort of standalone application in a linuxaudio session. You want reliable restoration of MIDI connections, also if you use the patchbay and not MIDIOut.connect().

How should that method be named?

Server.default.options.deviceName 
Server.default.options.deviceClientName 
Server.default.options.deviceMidiClientName
Server.default.options.deviceAndMidiClientName
Server.default.options.deviceAndMidiDeviceName

jamshark70 · April 13, 2024, 12:54pm

It belongs in MIDIClient. I strongly disagree with any notion of folding a MIDI option into ServerOptions. MIDI is language-only and has nothing to do with the server. The fact that they both appear in JACK UIs is purely an accident of the evolution of audio and MIDI subsystems in Linux. This should not influence SC architecture.

There could be a convenience method to set both at once, but these two entities should not be modeled in the same place.

hjh

smoge · April 13, 2024, 12:55pm

Some Apps work better because they support. For example, many apps save their status when receiving “SIGUSR1” Unix signal, which non-section-manager does etc.

flower · April 13, 2024, 1:21pm

So something like MIDIClient.initWithName()?

You can set save and stop signal in NSM-Proxy indeed. It might be nice for instance if it was possible to handle SIGTERM in sclang. Then a SIGTERM signal could be sent from NSM-Proxy and it could be handled in sclang, by for example, sending \quit to the belonging scsynth.

Not sure how useful a SIGURS1 signal would be when it comes to SC. Ideally OSC would be used instead I think in this case.

jamshark70 · April 13, 2024, 1:38pm

Or MIDIClient.name_("APopular80sTechnology").init;

I’m not sure if this is relevant to other OSes. I think (in both Mac and Windows) that apps can see only device names, not other apps, and devices typically don’t have access to app names (the connection is via a physical cable), so the SC client name is probably invisible and thus irrelevant (except maybe in MacOS Audio MIDI Setup). This may be why MIDIClient never had an interface for setting a name.

hjh

smoge · April 14, 2024, 8:15am

It’s true. non-session-manager can also be controlled by OSC, but I don’t know much about compatibility/features on NSM yet. I’ve been using just non-mixer.

The non-mixer and non-timelines are good software and can fit many different situations since they are so clean and modular. Checking out NSM now. Let’s see.

@flower share some tips on how you use NSM, I’m just considering it right now. The other pieces are more obviously useful for me.

flower · April 14, 2024, 10:29am

Add supported NSM clients to your session (non-mixer, non-sequencer, zynaddsubfx, ardour, qtractor, carla, seq192 etc.).
Add applications without NSM support using nsm-proxy
Restore JACK connections by adding jackpatch to your session.
https://non.tuxfamily.org/wiki/Non%20Session%20Manager

Btw: sclang doesn’t launch scsynth detached, so when sclang is started in a terminal and you kill the terminal, both sclang and scsynth are gone.