XOR Userforum

Hi
I've mapped out envelope sustain and volume on my Assimil8or using the MIDI IN to send CC via the mapping screen.
I've found a sporadically replicable issue, where hitting min or max value on specific CC channels, will set a CC value to another CC channel. Practically, this means that maxing out a fader, will open up the volume of a different channel, causing ruckus in a otherwise quiet part of the set.

There's a pattern to the issue, in which a specific channel will affect another specific channel. It adds a specific value to different channels (ie. CC33 will be set to a value between 0830 and 0930). 
So far, affected channels are CC24 CC32 CC33 and CC36. I'm still trying to figure out which are affecting which. So far CC29 has a ~30% chance of affecting CC24 if maxed out, judging by observation. CC24 is mapped to the CV16 EV4R, which will open the envelope in crucial performance situations

I have tested my controller (Faderfox MX12) using MIDI-OX, which shows no sign of cross-affecting values. I initially met the problem in 2.02A, but it still persists in 3.00.

Also: I found it hard to place this between "less important glitches/bugs" and "really bad bugs", since there's not crash. But since this is a crucial part of my live setup, it's more than a QoL issue, as it makes the NerdSeq problematic to use in a professional setting. Would you consider this less important? Just checking, because I want to put it in the right subforum, and it's good to know for future reference.

I will make a dump from the MIDI OUT when I get to work in 40 mins. I attached the project and mappings.
Let me know if you need anything else.

Cheers, and congratulations on the new update!  
/beep

PS: I suspected some NRPN tomfoolery, but I don't have the knowledge to single anything out.

I slightly checked your project and my first impression is that it most probably causes a massive midi data overflow in the output.
You route LFOs directly to Midi CC without limiting the data in any way. This combined with also probably back2back inserted midi data is just too much for midi.

Start with limiting the automator output to the midi channels. You can do that in the track setup of your midi tracks. Put it as low as the ‘flow’ is still fine. For example for
my usecases 5% is mostly totally fine. Yours is set to 100% currently.

Pretty sure there is the problem. Midi is quite slow and especially when you merge data then a traffic jam is easily possible.

Thanks a lot for the quick response and feedback. I hadn't noticed the automation limit feature at all. It makes sense. I'll give it a test run, and see if the problem still persists.
The MIDI-OX monitor showed a barrage of midi data in the same occasional pattern when I tried replicating it, so something like what you've mentioned seems like it could very well be the case.

Problem still persists with 5% on all automators, as well with all automators off. Is there a way to limit the influx of midi CC? I'm not sure, but I have my doubts it's due to overflow. The issue appears even when sending CC from a single, slowly moving fader.

OK, I connected a Midi fader (not a faderfox but I expect that makes no difference) and did set it to the mentioned channels but I can't see any problems with the Midi CC input stream. Just as a question, you are using one of the basic midi interfaces, not the multi-IO, right?

Lets investigate more deeper:
In the mappings you can see your current Midi CC values (range scaled to 0-4095). Check out the current value in the mapping screen of CC29 and CC24. Then change C29 until you think it happen again. Go back to the CC24 value and see if it has been affected in a way (slight changes are always possible caused by fader precision of course, but that shouldn't cause your mentioned problems). So it is interresting to see if the midi input stream does really affect others or if it might be something else after the Midi input internally, either with the mappings processing or further in the CV16 stream.

(10-06-2025, 01:04 PM)XORadmin Wrote: [ -> ]OK, I connected a Midi fader (not a faderfox but I expect that makes no difference) and did set it to the mentioned channels but I can't see any problems with the Midi CC input stream.

Often but not exclusively, the problem occur when multiple faders are being pushed or turned down.

---

Quote:Just as a question, you are using one of the basic midi interfaces, not the multi-IO, right?

Yup! It's the old school IO-Expander with DIN MIDI.

---

Quote:Lets investigate more deeper:
In the mappings you can see your current Midi CC values (range scaled to 0-4095). Check out the current value in the mapping screen of CC29 and CC24. Then change C29 until you think it happen again. Go back to the CC24 value and see if it has been affected in a way (slight changes are always possible caused by fader precision of course, but that shouldn't cause your mentioned problems).

I did that, and it does. :o Hence this detail below.

Quote:It adds a specific value to different channels (ie. CC33 will be set to a value between 0830 and 0930)

---

Quote:So it is interresting to see if the midi input stream does really affect others or if it might be something else after the Midi input internally, either with the mappings processing or further in the CV16 stream.

This is not happening in the CV16 stream. It sets a CC value to X, so the volume on my Assimil8or, controlled by CC out, is affected as well - (MCON section of mappings)