RtMidi cannot create ports past a certain limit about rtmidi HOT 10 OPEN

It seems odd that you would need to create so many ports. Rather, create one port and send messages to it. I don't think ALSA was designed with the idea that someone would open a new port every time a new message was ready to send.

from rtmidi.

I'm trying to create a MIDI patchbay using the Mido and rtpmidid libraries in order to route messages from multiple hardware sequencers. In order to do that, I need separate ports for each device (I have a large MIDI studio with >40 physical ports). Sorry if I'm misunderstanding you, but if I only create one port, wouldn't this just merge all incoming messages so there would be no way to distinguish what source they're coming from?

from rtmidi.

Well, that seems like an unusual configuration (having so many physical MIDI ports). That said, I don't think there are any particular issues in the RtMidi code that would limit the number of instances you decide to create.

from rtmidi.

Agreed it is unusual, but I was hoping there would be a way to accomplish it with preexisting tools. It does seem like it might be doable if the port creation didn't happen on a separate client each time a new one was created. I'll keep trying...

from rtmidi.

from rtmidi.

Ok, I think most of the issue is that while ALSA allows multiple ports under one sequencer client, RtMidi does not. This means that while one RtMidiIn or RtMidiOut object should be able to act as a container for multiple ports, it currently cannot. Is there a reason for this? It seems that instead of the connected_ flag attached to the client object, there could be a container variable to keep track of all currently open ports. I'm totally willing to try forking the project and mocking this up, but is there a reason why only a single connection to a client is allowed in the first place?

@insolace Since I'm getting the error before actually opening the ports, the issue is not with the ports themselves but rather that ALSA for some reason does not allow the creation of a large number of client objects. If RtMidi could avoid having to create so many clients and instead nest the ports under a single client, this would hopefully avoid that problem.

from rtmidi.

If a single instance of RtMidi could be used to open multiple ports at the same time, then there would have to be a mechanism for specifying to which port a message is sent or from which a message is received. Given that it was unexpected, when designing the RtMidi API, that someone would want to have many ports open at the same time, I decided to make life simple and go with a single port per instance. So, if a single instance is to support many ports, there would have to be some significant API changes.

from rtmidi.

Got it. I was thinking about this, and a possible solution would be for there to be separate RtMidi objects per port, but if they were created with the same clientName instance variable, they would reference a single client internally. I don't think this would necessitate any API changes. Does this sound like it could be a workable solution? At the very least, the output of aconnect -l would be cleaned up considerably and note be full of identically named clients.

I'll have to look at the code a bit more to see how much this could potentially mess up. One thing I'm not sure of is how much is automatically managed by the system when ports are added and removed on the client and what happens to the port numbers. There may at least need to be some kind of function to refresh the client and look for changes, or maybe this could be rolled into the openPort function somehow.

from rtmidi.

It seems to me that there is a limit of clients for ALSA. Since RtMidi opens a new client for each port this limit also hits RtMidi. ALSA allows several ports per client so this limit could be pushed somehow. However, this has some implications on the architecture of RtMidi. The main reason to use this design is thread safety, as ALSA is only thread safe if different threads use different clients. If RtMidi would use multiport clients, it would be necessary to use spinlocks in order to garantee thread safety.
This is in principle possible.

The problem of port association is not really a problem since ALSA provides the source and destination client and port of each ALSA message to the receiving ALSA client.

I played with both parts in https://github.com/keinstein/rtmidi/blob/code-deduplicate/src/ALSA.cpp .

from rtmidi.

Thanks, this is very helpful! I'll take a look at your code. Gonna take some time to wrap my head around this.

On a side note, I noticed that running the ALSA library function snd_seq_system_info_get_clients on a seq object gives the output 192. Unless I'm misunderstanding something, this should actually be the number of clients that is allowed to exist at once on any given system. Therefore, this really does seem like a bug in ALSA...

from rtmidi.