Multi-instance mode sending note-off commands only

[riban-bw]

In Multi-instance mode the pattern seems to be continually sent as MIDI note-off commands and there are not any MIDI note-on commands.

• Add instance of arplinger to chain with MIDI channel 1
• Configure as [Multi-instance] Global chord instance
• Add instance of arplinger to chain with MIDI channel 2
• Configure as [Multi-instance] Pattern instance
• Add sequence driving MIDI channel 2
• Monitor output of pattern instance

Expect to see nothing but actually see MIDI Note Off messages on MIDI channel 2.

• Play a chord on MIDI channel 1
  Expect to hear and see MIDI Note On/Off to match sequence but actually continue to see MIDI Note Off messages only.

[YPares]

Thx! Just to be sure, what was your When no chord note setting? Silence ?

Also, in your situation you expected no events at all, right? You haven't been feeding chords as I understand, so either with Silence or Latch last chord you shouldn't be seeing note ON events in any case.

[YPares]

@riban-bw If you want to have a quick try: just comment lines 192 & 193 in Arp.cpp:

    else // No mappings means we add the NOTE OFF as it is:
      midibuf.addEvent(msg, 0);

(I added that because it seemed to fix some rare stuck notes cases, but it's certainly what causes your problem here. But it's not multi-instance specific, probably you'll have the same behaviour in the same conditions in multi-chan mode)

EDIT: I applied that in latest master

[riban-bw]

Although that stops note-off messages being sent I am still not seeing any note-on messages being sent in multi-instance mode.

[Edit] Actually - in multi-instance mode the pattern instance behaves as if there is not chord instance connected. I wonder if the IPC is working as expected on this platform:

Arpligner.so: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=7f85e19443224c9c448b21e863a81d5907db2092, with debug_info, not stripped

[YPares]

@riban-bw Then that's probably that. That's what's expected to happen if the two instances are isolated and both create their own "singleton" object each one on their side.

[riban-bw]

How would mult-instance be instantiated successfully?

[YPares]

@riban-bw Multi-instance relies on SingletonHolder from JUCE: https://github.com/juce-framework/JUCE/blob/2b16c1b94c90d0db3072f6dc9da481a9484d0435/modules/juce_core/memory/juce_Singleton.h

But it's not clear to me yet what in their implementation makes the shared pointer unique...

[YPares]

Okay so it probably just boils down to the fact that the singletonHolder attached to the class is made static:
static juce::SingletonHolder<Classname, juce::CriticalSection, doNotRecreateAfterDeletion> singletonHolder;

So yes I'd guess that, for it to work, the exact same process has to load (at least on Linux) the various plugin instances, so that static singletonHolder may be the same for each. Is the "scope" of static mutable members a well-defined property in C++ standards anyway? (I know this could qualify as "dabbling with black magic" here...)