2401 stable: Not dealing well with multiple same model controllers

[Koshdukai]

I was finally able to upgrade to 2401 stable and after doing the Restore all seemed ok except my USB MIDI controllers were all playing all tracks, so I went on each track to check what was happening and noticed some new unexpected issues:

1) Controllers with multiple USB MIDI Ports and a long controller name lose the port # suffix, making it difficult to exclude just one of those ports because listing that string in DISABLED_IN will disable all ports

2) The other issue, already hinted at above is when using multiple controllers of the same brand and model (due to the MIDI count limitation of these linux builds, on the next example I had to disconnect one of the KLEs so the 2nd KLmkII is recognized):

In this case, besides having a similar issue as the one described on issue #1, there’s an additional problem on the “Capture MIDI from …” option, where only 1 of those is listed:

I don’t remember having any of these issues on previous ZynthianOS builds/versions, besides the unfortunate USB MIDI port limitations that I wish will eventually increased considerably in a near future

So, even with issue 2, I could still use MIDI Channel selection per track but “setBFree/Upper” instance I’ve been using for a while, for some reason, now doesn’t allow MIDI Channel selection, only MIDI port

As I was writing this, I thought of confirming this by adding another instance of setBFree but it wasn’t being listed as an available Synth to add.
Checked the LV2-Plugins list and found a new(?) version in there (unchecked) so I enabled it

and tried again

and this new version does have MIDI Channel again, phew

So, I guess I can workaround issue 2 for this track through MIDI Channel (like I used to do) and not have to unplug one of the KLEs but still, issues 1 and 2 can be annoying, that’s why I decided to mention them here.

[tunagenes]

@Koshdukai

I was finally able to upgrade to 2401 stable

Did you update to get current fixes after loading the 2401 image via software update in webconf or the UI? There have been some changes that directly involve the USB long names, so it might affect this.

[Koshdukai]

Yup, just right before posting this I did the update (sorry, meant mention that and forgot!)

These are the current versions:

[riban]

ALSA (the Linux low-level audio & MIDI driver layer) has changed in recent kernels which means we had to change how we handle MIDO interfaces in Oram. This means that the kind of issue you are seeing in stable is fixed in Oram. Indeed we have a mode that allow for devices that are identical being identified by the physical USB port they are connected to. So the office should go away when you migrate to Oram.

Oram is currently the development branch so this does not fix your issue in stable. I doubt we will address this in 24.01 because we hope to release Oram soon. It may prove challenging to fix this issue in 24.01 and that could be wasted time of we then migrate to Oram soon afterwards.

setBfree is one of a few engines that only allow one instance, i.e. after you add setBfree to a chain or is no longer available in the list of engines. The other instance you found is the LV2 version that is not limited to one instance but had some other limitations. We have removed the LV2 versions of these synths from Oram but changes to the others means that (in theory) we could allow multiple instances of setBfree (and the others). I don’t think that is coded yet though.

Other single-instance engines are: Pianoteq & Aeolus.

[Koshdukai]

@riban

This means that the kind of issue you are seeing in stable is fixed in Oram.

That’s all that I wanted the hear, thanks

@riban

setBfree is one of a few engines that only allow one instance, i.e. after you add setBfree to a chain or is no longer available in the list of engines. The other instance you found is the LV2 version that is not limited to one instance but had some other limitations

Just found this a few seconds ago, the “hard way” as I was trying to remap the drawbar parameters (that aren’t there on the LV2).
So that explains why I wasn’t able to add another non-LV2 instance.
Yup, sure enough, once I removed it, here it is available

@riban

We have removed the LV2 versions of these synths from Oram but changes to the others means that (in theory) we could allow multiple instances of setBfree (and the others). I don’t think that is coded yet though.

Other single-instance engines are: Pianoteq & Aeolus.

Thanks, very helpful info!

Funny thing is, that setBFree has some initial setup options that would induce one to have a few instances running, each with different options. Oh well, guess I’ll have to “annoy” the setBFree team now

[Koshdukai]

Well, just found another issue while trying to remap the KLE faders (on MIDI Channel 3) to the drawbar parameters:
The Mixer MIDI Learn isn’t respecting the learned MIDI Channel

So now, as I change track’s #3 drawbars, the Mixer levels are messed up because the MIDI CC’s match but the Mixer was set to use those just on MIDI Channel 1 (from KL88) -.-’

Welp… Mixer Clean MIDI-Learn it is then
hopefully Oram also has this one fixed

EDIT: oh! Looks like the problem is that Multitimbral isn’t actually working. That explains some of the issues I’m seeing now.
Once I (re)set some of the controllers, each on their MIDI Channel, the only track being played is the selected one instead as before, all would play incoming MIDI, independently of the track selection.

[riban]

Again, we have different behaviour in Oram with the ability to learn based on MIDI channel or selected chain.