Change midi channel for TATAT in AUM (Solved)

nukular194

I hope you can help me because one thing is driving me crazy.

I want to send midi from TATAT in AUM to an external Synthesizer (Digitone). The communication works but no matter what i do it only sends on midi channel 1!

In other midi tools like Helium or Rozeta Sequencer Suite i can change the Midi channel in the tool itself, which i cant in TATAT.

How can i change the midi channel for TATAT in AUM? I cant find a way...

Thanks in advance

GeoTony

If your familiar with StreamByter you just need a simple one line script to remap the channel like

X0 = X5

Note StreamByter numbering starts at 0 so X0 means channel 1 and e.g. X5 means channel 6
You point TATAT at StreamByter and then use StreamByter as the input to your external device
(I assume this will work as I don’t use external devices)

nukular194

Thank you for your reply.

It works now, but when i pause or stop the sequence StreamByte becomes red and a message with an reload button pops up Audoenic: StreamByter failed. Audio Unit plugin invalidated
Then i have to reload StreamByte and install the mapping rule of the midi channels again.

nukular194

@GeoTony Do you have an idea how to fix this?

GeoTony

Just tested in AUM on iPad 18.1.1 and it works fine.
What Host / device etc are you using and can you provide a screenshot of the setup /error ?

nukular194

I‘m on IPad (9th Generation) 18.2.1

And when i reload and install the Mapping again it works until the next time i stop the sequence

uncledave

TATAT may be sending some badly formatted MIDI when you stop the sequence. Are you using the AUM transport controls, or controls inside the TATAT plugin? Try adding a MIDI monitor in parallel with StreamByter. You might be able to see those final messages.

GeoTony

What @uncledave said… if you don’t have another midi monitor you can use either the same or another instance of StreamByter, just click on the magnifying glass bottom right with TATAT as the input.

Synthi

Try switching off the iPad and power on again, sometimes fix strange thing related to AUv3

_ki

@nukular194 Could you paste screenshot of the TATAT preset ?

With the TATAT default preset SB doesn“t crash after AUMs start & stop on my iPadPro 10.5 IOS 17.2

Update: It crashes upon AUM Start if i insert the X0 = X9 script line, very weird.
* Sending AUMs keyboard through the very same script does not crash SB and produces the correct output with updared channel.
* I verified with different Midi monitor AUv3s that only a single NoteOn and NoteOff is send to SB.

Update 2: SB with script crashes upon AUM start even if nothing is feeding midi into it - so it‘s probably a problem with the transport start cmd that gets translated by SB into a custom sysex… I’m on it

Update 3: I found a fix by first blocking all sysex before applying the channel transformation

F0-F = XX +B
X0 = X9

The Sysex send for Transport start is F0 7D 01 7A F7 which matches the rule X0 (first nibble X=anything, second nibble 0) - so SB started to modify the sysex and then crashed due to the extra bytes. Since the problem occurs due to SB‘s translation of the transport commands to sysex, these sysex are not shown in other midi monitors => Mystery solved.

nukular194

@_ki thank you very much for the solution!

And thank you to all the others who responded so fast!

I also figured something strange out - it's all about the specific midi channel 10.
Every other midi channel except channel 10 in the one line script works perfect without the fix of @_ki !

X0 = X1 (works)
.
.
.
X0 = X8 (works)
X0 = X9 (doesn't work)
X0 = XA (works)
.
.
.
X0 = XF (works)

There must be something weird with midi channel 10 that i don't understand.

I couldn't monitor anything, because when the one instance of StreamByter crashes the other crashes also.

But now it runs like expected.

Thank you all again

_ki

@nukular194 Perhaps it‘s the output produced. The internal sysex for the AUM transport control will result in different commands depending on the translation applied.
According to the midi spec F9 is an undefined command Maybe streambyter is able to recover from other sysex translations like F1 (MTC), F2 (SPP), F3 (Song Select). But F4/F5 are also ‚undefined commands‘

wim

I wonder if mfxStrip would choke and die in the same way. It's just a frontend for underlying Streambyter code, but maybe as a more limited tool it wouldn't puke on the invalid sysex. mfxStrip and mfxConvert are handy tools for quickie conversions like these without coding.

j_liljedahl

Where are those sysex messages coming from? AUM does not send any so I assume they come from TATAT. If so there are two bugs to report:

• TATAT sending invalid MIDI messages
• StreamByter crashing on invalid MIDI input

(And while you're at it, ask TATAT dev to add a MIDI output channel setting. Every MIDI sending thing is supposed to have a setting for that)

_ki

@j_liljedahl StreamByter AUv3 internally sends these sysex to its script when it receives transport control commands from its host (in this case AUM). From its design, SB works on the stream of midi data, so acting on host commands (which arrive via other callbacks) was not possible. Therefore the dev had the idea to just convert these commands into simple sysex that are inserted into the midi buffer of the script.
The same ‚idea‘ is used to hand over slider movement or button oresses in the SB gui - these also arrive as internal sysex that can be picked up by the script.

The crash seems to result from converting this internal sysex with a script command that was meant for channel conversion: X0 = X9 meaning for midi command bytes with any upper nibble (X) and lower nibble zero (0) convert the lower nibble to 9. This matches note on/off, cc‘s etc on channel 0 BUT also the sysex F0 … which then get converted to F9 which identifies an undefined sysex leading to a crash.

So its neither of the two bug variants you suspected

j_liljedahl

@_ki said:
@j_liljedahl StreamByter AUv3 internally sends these sysex to its script when it receives transport control commands from its host (in this case AUM). From its design, SB works on the stream of midi data, so acting on host commands (which arrive via other callbacks) was not possible. Therefore the dev had the idea to just convert these commands into simple sysex that are inserted into the midi buffer of the script.
The same ‚idea‘ is used to hand over slider movement or button oresses in the SB gui - these also arrive as internal sysex that can be picked up by the script.

The crash seems to result from converting this internal sysex with a script command that was meant for channel conversion: X0 = X9 meaning for midi command bytes with any upper nibble (X) and lower nibble zero (0) convert the lower nibble to 9. This matches note on/off, cc‘s etc on channel 0 BUT also the sysex F0 … which then get converted to F9 which identifies an undefined sysex leading to a crash.

So its neither of the two bug variants you suspected

I see! Thanks for the detailed explanation. So just one bug then: SB crashing on undefined internal sysex.