Does it also send “All Controllers off”? Because one thing I noticed is that it sends “all controllers off” (CC121) at value 0 in irregular intervals as well. That’s not THAT much of a deal for me, since I can “swallow” these messages with MIDI Translator… But is there any way you could make it so you can turn all auto-off-stuff off completely in the midioutchop?
I don’t see it sending 121, but ‘All Notes Off’ is controller 123.
It sends 123 for ‘All Notes Off’ pulse, .panic() method, and some automatic note off menu settings.
Before this upcoming fix it was also sending it randomly and sporadically.
It also sends ‘volume off’ (control change 7) during .panic() and ‘Volume Off’ pulse button.
Is that what you were seeing?
I just reopened the project, and it’s sending both, at the same time, regardless of the setting of the Auto-Off toggle. (Index seems to be offset in TDs MIDI Console). I tested adding some more MIDI-Devices plus a custom (but empty) MIDI-Map, turning all the midioutchop’s auto-off toggles off, and it’s still doing it.
unfortunately it still doesn’t work for me, even if I do everything as described
Okay guys. I just updated to latest version of Windows, and the CC121-Bug is gone. Also, I figured that Cubase has a MIDI-Filter set for CC123 by default, so that’s why I never noticed the “All Notes Off”-Bug when working in Cubase. Still glad it’s gonna be fixed though 
So that’s that. It was some Windows update, just as I expected right from the beginning.
Edit: Just so you know, it was this one:
2021-04 Cumulative Update Preview for Windows 10 Version 20H2 for x64-based Systems (KB5001391)
1 Like
Are you using build 2021.13610. This is the build with the fix.
I have build 2021.14360 and I’m still getting random control change 124 & 122 for all channels.
Hi @deseipel, could you send in your example file as requested in this thread Odd MIDI in behavior so we can get a look at what is happening for your case? We are waiting to get a reproducible case.
Thanks
I have been going crazy for the past few weeks trying to fix what I thought was a bad midi controller, and now believe may be this bug (or some variation). This even happens using midi controllers ↔ mioXM ↔ rtpMIDI ↔ TouchDesigner, across multiple different types of midi controllers (1x Behringer xTouch Extender, 2x Midi Fighter Twisters). 2021.14.357/14360. I’ve seen both the ‘Other 00 00 00’ message and two other possibly related issues where the midifilein receives a 0 message, and I get a spray of messages ranging from zero to the correct value a few seconds after a values is changed: “(Current value)…0.1.2.3.4.(rest of values).(currentvalue)…”.
My only other note is that it seems to have a high correlation with missing frames, using a HOG seems to make the issue happen more often.
This started happening when updating either to 2021.13610 or 2021.14357/14360.
Windows 10 Enterprise 20H2 19042.1110, Windows Feature Experience Pack 120.2212.2530.0.
Hi.
Thanks for your patience.
Can you verify that all your MIDI Out CHOPs have ‘Automatic Note Off’ turned off?
To list all your MIDI Out CHOPs quickly in the textport you can type:
[n.path for n in root.findChildren(type=midioutCHOP)]
For each operator listed, go to its Output page and make sure ‘Automatic Note Off’ is set to ‘None’.
If you haven’t already done so, please send the toe file to support@derivative.ca so we can take a close look.
Thanks for your support,
Rob.
2 Likes
Hi Rob,
I didn’t send in the toe file yet, as the loading chain is complex and involves a lot of toxes / file system dependencies / system config, etc.
I think I finally figured it out after a few more weeks of seeing this intermittently.
Even if a Constant CHOP with a single dummy channel is hooked up to a midioutCHOP and no other midi commands are being sent to it via python, and all other midiouts have been deleted (including the midiouts inside of the templates in /local/*), and Automatic noteOff is set to none, TouchDesigner will occasionally send midi CC 121 and midi CC 123 on channels 1-16. even when a midi-> midiRTP device is being used to eliminate any local machine level disconnects and reconnects. (The timing might be related to the TD timeline). Midi controllers with automated faders seem to respond to the ‘Reset All Controller’ messages in unpredictable ways.
Happy to follow up with my testing methods, but more or less this was replicated and logged on both the same machine and a separate machine over the network, using Protokol.
2021.14357 / Win10 Pro for all of these tests.
Thanks!
Further confirmation by splicing midi controller ↔ computer A ↔ OSC ↔ computer B to filter out CC 121 and CC 123 messages, entire bidirectional midi loop seems to work just fine now.
Can you add an Info CHOP, pointing to the suspected MIDI Out CHOP and monitor its
‘events_sent’ value?
Let’s see if the value goes up when these unplanned messages happen.
Thanks,
Rob.
1 Like
I’ve examined MIDI Out CHOP further, and can’t find any reference to CC 121.
CC 123 however, is only sent whenever the reset parameter is pulsed, or Automatic Note Off parameter is set.
Another potential source may be through python scripting.
Would any of those routes apply to your toe file?
1 Like
Thanks for the followup, Rob.
Can you add an Info CHOP, pointing to the suspected MIDI Out CHOP and monitor its
‘events_sent’ value?
Let’s see if the value goes up when these unplanned messages happen.
Great idea, I’ll try this onsite in a day or two.
I’ve examined MIDI Out CHOP further, and can’t find any reference to CC 121.
CC 123 however, is only sent whenever the reset parameter is pulsed, or Automatic Note Off parameter is set.
Another potential source may be through python scripting.Would any of those routes apply to your toe file?
Thanks, I was guessing there’s only so many places a hard push of a value could happen in the source code.
Automatic Note Off is set to None .
In the simplified controller mapping I set up to diagnose this problem, the only values I’m sending to the controller are python scripts that execute op('midiout').sendPitchBend(tdu.digits(channel.name), val).
I’m not casting tdu.digits to int(), so I do see than tdu.digits returns NoneType on no digits found. So the only obvious issue I see is op('midiout').sendPitchBend( *NoneType* , val). I will test this, but the behavior doesn’t seem to match - if this was the issue I would expect to see this happen on many frames, not once every few seconds.
The second possible issue I could see is something happening if frames are dropped - maybe channels are dropping out and coming back in during a dip in FPS? Entire channels disappearing for a single frame has been extremely hard to diagnose for me in the past (as the Trail CHOP recreates the entire visual every single frame, so dropouts don’t appear unless you use a ReplaceCHOP / OverrideCHOP a known set of channel names, but then that’s actually ‘polluting’ the data if there’s no easy default value (ie expected values between -10 and 10, so to detect a channel dropout you’d use a constantCHOP with values set to -99 into a Replace/OverrideCHOP, but this ‘pollutes’ things like averages and downstream multi-sample calculations). The chopExecute concept of onValueChange doesn’t clearly capture the events of channels adding or removal, so perhaps there’s confusion there? For example:
- If a channel val is at 0, then the channel is removed for a frame, then the channel comes back at 100, is onValueChanged() called? (?Yes?)
- If a channel val is at 100, then the channel is removed for a frame, then the channel comes back at 100, is onValueChanged() called? (???)
But even so, the only python function being called on the midiout is sendPitchBend(), which is why I was very confused to see the the CC messages. All other oddities with channels dropping should be covered if sendPitchBend can handle sendPitchBend( arbitraryType, arbitraryType),
To reframe that, if a constantCHOP connected to a midiout (with Automatic Note Off and all other midi outs (including /local/) are removed), and a chopExecute only has the python sendPitchBend( arbitraryType, arbitraryType), is there any way that CC 121 and/or CC 123 could be sent? (This was with Protokol for capture, so maybe these are off by 1 for indexing, and are actually 120/122 or 122/124 in TouchDesigner?)
Another thing to note, for this testing I had {(Midi Controller) → (Mio XM) → Protokol A} AND {(Midi Controller) → (MioXM) → (TouchDesigner [midi out to Protokol B, midi out to mio back to midi controller] )} , and these messages only appear on Protokol B and not Protocol A. Meaning, these messages were not generated by the midi controller or MioXM (otherwise they would have also appeared in Protokol A).
Does TouchDesigner do any midi feedback loop detection? I don’t think the Mio is doing this, as I bought the mio to disconnect the midi controllers from usb to isolate this problem in the first place (at first I thought this was the controller disconnecting and reconnecting and triggering callbacks of some sort).
Thanks for the further info.
In addition to the Info CHOP on the specific MIDI Out CHOP, you can also use the MIDI Event CHOP to log events from anywhere in TouchDesigner.
That might give us a better clue.
I think the sendPitch is probably fine, but can you comment it out altogether for testing?
In addition to the midiout.send* commands, there is also midiout.panic(). Do you have one of those?
Is anything pulsing the All Notes Off / All Volume On / All Volume Off / Send Start-Stop parameters?
Where are you getting channels added and removed as a result of dropped frames? One place this can happen is when you’re using a Shuffle CHOP for example, and the number of samples in a timeslice varies. If that’s the case, just keep the first sample always to avoid those issues during dropped frames.
In trems of CC 121/123 vs 120/122 or 122/124 I still don’t see
extra messages being sent intentionally.
TouchDesigner doesn’t do any feedback loop detection.
You’re also using a branch build is that correct?
I belive it includes all the relevant fixes, but any chance you can confirm on the posted build, just in case?
1 Like
Just an update: I found an issue where the MIDI Out CHOP may send extra message when new channels are first encountered.
This will be fixed in an upcoming release.
1 Like
@rob This is so great to hear! Apologies for not responding to your earlier post, I was hoping to at least give you more info via the MIDI Event CHOP.
Would you mind posting the exact official and/or experimental build numbers where this should be fixed for future reference? Thanks!
Hi.
Looks like it didn’t make it to the latest posted build, but is in builds 15270 and later.
Contact us at support@derivative.ca, and we can setup access with you.
Cheers.
1 Like