Reconnect to Midi input (and output?) ports

[zigmhount]

Hello,

I've been having this issue for a while, but I was not sure whether it was due to how I was handling things, till today, so here goes (might be linked to #183 ):
These days I usually use RaySession (based on NSM) to manage my sessions, where the session usually contains Carla or Ardour, a bunch of plugins in those, 1 or 2 mididings scripts and a few jack_mixers when using Carla.
To this I connect 0 to 3 MIDI devices (keyboards and control surface). I've been playing around with seq64's [manual-alsa-ports] and [reveal-alsa-ports] settings to figure out if any combination might work out as I expect, and I usually keep

[manual-alsa-ports]
0
[reveal-alsa-ports]
0

since I use the native Jack setup, which displays (as expected) the names of the ports as detected by Jack.
My problem is that the MIDI connections with Seq64 when I reopen the session are (almost) always messed up.

Most of the time, I've supposed that it depends on the sequence in which I launch the applications: if Seq64 is launched at the same time as Carla or Ardour, Seq64 obviously opens much faster, and all MIDI ports popping up from the tracks and plugins are not auto-detected because they don't exist yet. So I close Seq64 (most likely overwriting the RC file's input/output settings) and reopen, the ports are back, but the connections are lost or messed up (input ports are almost always lost, even when I use a MIDI through plugin to make sure I don't change the connections to Seq64 whether or not I plug my actual MIDI devices).
I guess that it may be due to the fact that Seq64 "remembers" the port to connect based on their ID, rather than their name, so if applications are not started in the same order or MIDI devices not plugged in the same order, the ports may not get the same ID, and connections are subsequently incorrect. Does this make sense? If yes, would it be doable to reconnect based on the port's name?

Today however, I was very careful to not open Seq64 before Ardour, which contains MIDI busses for my devices and MIDI busses for the sequences' synths, so that connections can be restored properly, but it seems that my 2 input ports where still inversed!

So I'm wondering a bit how you use this and whether I do it wrong...

Using [reveal-alsa-ports]=1 or the ones hardcoded in the USR file ([manual-alsa-ports]=1) might work, but then it limits the number of output ports to 16, which may in some cases not be sufficient for my instruments/synths (I could of course use channels and/or instruments for each port, but I'm very reluctant so far because it makes it much more difficult to monitor what goes where and I may have to add plugins to filter the channels to dispatch between the synths... but I'm relatively new to this so it may be the way it should be done?).

What do you think?
I'd be curious to know more about your setup as well if you can share :)

I'm using 0.96.8 from the midi_control branch btw.
And while I'm at it (but maybe I should open another ticket for that), is there any hope for the future to have the RC and USR files in any folder, e.g. a project or session's folder, rather than always in .config/sequencer64?

Thanks!

[Houston4444]

Hi.
As RaySession dev, I must say that the sequencer64 behavior with jack-midi makes it complex to use in a session manager.

When JACK-midi is choose, it should not create midi ports according to which one is connected. It should just have one midi entry port (or more if needed) and let user connect the hardware or software midi ports (s)he wants. This does not prevent to let the user choose the midi hardware connected in the preferences dialog, It changes just the behavior. Of course, the program could save the connections in the config file or elsewhere.

But, now, if user has set a carla midi output as midi input in sequencer64, when they are launched together in the session, seq64 will be ready before carla and won't see its ports. So, user has to stop and restart sequencer64 to get it correctly connected.

And, it's a small detail, but, a new behavior will prevent to have midi ports will very long names in JACK patch bays (Catia, QJackCtl).

[ahlstromcj]

Try the manual mode. In the 'rc' file, find the manual-alsa-ports section and edit it. Or use -m command line option. It creates a number of virtual output ports that you can connect. Should work in JACK too. Let me know of any issues that still bug you. Also see the seq66 project. I'm still working on getting that version to play nice with the non session manager.....

…

On Wed, Oct 14, 2020, 02:59 Houston4444 ***@***.***> wrote: Hi. As RaySession dev, I must say that the sequencer64 behavior with jack-midi makes it complex to use in a session manager. When JACK-midi is choose, it should not create midi ports according to which one is connected. It should just have one midi entry port (or more if needed) and let user connect the hardware or software midi ports (s)he wants. This does not prevent to let the user choose the midi hardware connected in the preferences dialog, It changes just the behavior. Of course, the program could save the connections in the config file or elsewhere. But, now, if user has set a carla midi output as midi input in sequencer64, when they are launched together in the session, seq64 will be ready before carla and won't see its ports. So, user has to stop and restart sequencer64 to get it correctly connected. And, it's a small detail, but, a new behavior will prevent to have midi ports will very long names in JACK patch bays (Catia, QJackCtl). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#204 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB45LKEYLGIMU2ZUCTN5VALSKVD3HANCNFSM4M2UML3A> .

[Houston4444]

Argument -m works well, thanks !
I changed the sequencer64 RaySession template to be launched with this argument.
Do you plan to implement NSM support ?

[ahlstromcj]

Working on it now for seq66. It's required enough refactoring that I won't backport it to sequencer64. Still documenting the NSM support and making sure what it says is true. :-) Checkout the seq66 'nsm' branch and see. Feedback welcome! Day job is slowing things down.

…

On Wed, Oct 14, 2020, 15:33 Houston4444 ***@***.***> wrote: Argument -m works well, thanks ! I changed the sequencer64 RaySession template to be launched with this argument. Do you plan to implement NSM support ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#204 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB45LKC3HC76MPCGSWTSVU3SKX4G3ANCNFSM4M2UML3A> .

[ahlstromcj]

I got my app (qseq66) running in RaySession. It comes up fine. However, there is no session information in qseq66's "Session" tab. When I run qseq66 via non-session-manager, the app receives a /reply "/nsm/server/announce" ... message from NSM and uses the data to populate the Session tab's "Session Manager", "Session Path", and "Client ID" fields. Also don't see a "Session Server URL". Attached is what I see with NSM. What am I doing wrong? Thanks!

…

-------- Houston4444 23:58 Tue 13 Oct --------

Hi. As RaySession dev, I must say that the sequencer64 behavior with jack-midi makes it complex to use in a session manager. When JACK-midi is choose, it should not create midi ports according to which one is connected. It should just have one midi entry port (or more if needed) and let user connect the hardware or software midi ports (s)he wants. This does not prevent to let the user choose the midi hardware connected in the preferences dialog, It changes just the behavior. Of course, the program could save the connections in the config file or elsewhere. But, now, if user has set a carla midi output as midi input in sequencer64, when they are launched together in the session, seq64 will be ready before carla and won't see its ports. So, user has to stop and restart sequencer64 to get it correctly connected. And, it's a small detail, but, a new behavior will prevent to have midi ports will very long names in JACK patch bays (Catia, QJackCtl). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #204 (comment)

-- This planet has -- or rather had -- a problem, which was this: most of the people living on it were unhappy for pretty much of the time. Many solutions were suggested for this problem, but most of these were largely concerned with the movements of small green pieces of paper, which is odd because on the whole it wasn't the small green pieces of paper that were unhappy. -- Douglas Adams

[Houston4444]

Hi.
I tried the nsm branch of qseq66, unfortunately NSM support seems to not work with the simple make method, and I was discouraged by the length of the complex make instructions, I'll give it a new try, sorry for that !

Normally, the client <=> server communication is the same in RaySession than in NSM, it uses the same messages. Given values can be different, and reply time too.

I don't see any attached screenshot in your previous message. You forgot something ?

[Houston4444]

I don't arrive to build qseq66 with NSM support. When I type ./bootstrap --enable-nsm, it gives me
? Unsupported bootstrap option; --help for more information

[ahlstromcj]

Session support is now enabled by default, no need for any option. The bootstrap script has its own options so that I can do stuff with less typing. Here's what I usually do when making a major change to the modules: $ ./bootstrap --full-clean $ ./bootstrap -er $ make &> make.log You can replace "-er" with "-ed" to build for debug mode. The --enable-nsm option is useful only with the ./configure script (which bootstrap creates). I think I need to update the INSTALL file! Good luck! To explain further about the messaging, qseq66 first looks for the NSM URL, then it sends a client-announce message. qseq66 then uses the announce-reply to populates the capabilities and session-manager name strings. Then NSM sends the client-open message with the rest of the session information. Finally, once the main window is created, the Session tab is populated with the NSM path, Client ID, etc. obtained from nsmd.

…

-------- Houston4444 03:03 Tue 27 Oct --------

I don't arrive to build qseq66 with NSM support. When I type `./bootstrap --enable-nsm`, it gives me `? Unsupported bootstrap option; --help for more information ` -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #204 (comment)

-- An engineer, a physicist and a mathematician find themselves in an anecdote, indeed an anecdote quite similar to many that you have no doubt already heard. After some observations and rough calculations the engineer realizes the situation and starts laughing. A few minutes later the physicist understands too and chuckles to himself happily as he now has enough experimental evidence to publish a paper. This leaves the mathematician somewhat perplexed, as he had observed right away that he was the subject of an anecdote, and deduced quite rapidly the presence of humour from similar anecdotes, but considers this anecdote to be too trivial a corollary to be significant, let alone funny.

[Houston4444]

To explain further about the messaging, qseq66 first looks for the NSM URL,
then it sends a client-announce message. qseq66 then uses the announce-reply
to populates the capabilities and session-manager name strings. Then NSM sends
the client-open message with the rest of the session information. Finally, once
the main window is created, the Session tab is populated with the NSM path,
Client ID, etc. obtained from nsmd.

Yes, like all nsm clients does. I don't see why it could not work with raysession at this stage.

[Houston4444]

making this (on nsm branch):

    $ ./bootstrap --full-clean
    $ ./bootstrap -er
    $ make &> make.log

I don't see any NSM support nor with new-session-manager, nor with raysession.