Multi-instance mode sending note-off commands only about arpligner HOT 7 OPEN

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.

from arpligner.

@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

from arpligner.

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

from arpligner.

@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.

from arpligner.

How would mult-instance be instantiated successfully?

from arpligner.

@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...

from arpligner.

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...)

from arpligner.