MIDI in flashing x100

[gilmo]

The MIDI In section of the Control Bar keeps rapidly flashing "No In" and then "x100" and doesn't display MIDI In info, e.g, when I press a key on my controller keyboard.

[Jordi Torres]

Hi,

 

Anything that starts with an "x" is a System Exclusive message. You can find out more about this messages by using the free utility MIDI Monitor. Not only will it let you learn more about the message, it will also tell you where it is coming from (in case it's not coming from your keyboard).

 

You don't say which controller keyboard you have?

 

J.

[gilmo]

Thanks so much. I updated my signature so you can see my current gear. I have MIDI Monitor and hadn't known to use it here. It shows that the TAC-2 thunderbolt interface is spewing a flood of sys ex messages just being on, whether or not Logic is open, and this is with latest TAC-2 driver:

TAC-2 sys ex message stream

[gilmo]

Solution on the way.

 

A thread on Sound on Sound included another user with the same sys ex flood issue with his TAC-2, which he returned for replacement. Sweetwater authorized a return of mine for repair under warranty, so it's on its way. Thanks so much again for sending me in the right direction so clearly and quickly. Won't neglect that (now updated) MIDI Monitor again, hopefully.

[Jordi Torres]

Hi,

 

Thanks for updating your signature

 

We had a thread of our own here about this TAC-2 issue. User Supremeja posted good info he got from Zoom. Have a read:

 

viewtopic.php?p=592248#p592248

 

If his info is correct, getting a new TAC-2 won't solve the problem...unless Zoom's done something about this since then.

 

J.

[gilmo]

Thanks again, sour as this news is. I'll see what happens with my return and let you all know. The weird thing is that this misbehavior just showed up, wasn't there at the outset.

[David Nahmani]

I would still try to contact Zoom... it looks like some sort of clock signal... are there any sync settings you can adjust in the TAC2? MIDI Sync, WordClock sync, MIDI Clock....?

[gilmo]

Thanks so much for your attention to this, and thanks for your sage and generous advice in both your books and this forum.

 

No place to adjust anything to do with MIDI that I can find in the manual. It's strictly an audio interface, so it's puzzling to me that it's sending any MIDI data. I can't test more now because I already got an RMA from Sweetwater and sent the TAC-2 back to them.

 

Here's another thought about what may have unleashed the sys ex flood:

 

I think it had occurred beforehand, but I definitely noticed it after selecting the Wide Suitcase as the instrument on a track. Messages about surround sound settings appeared, which I dismissed somehow. I finally noticed that the track's output was Surround. Re-setting it to Stereo didn't staunch the sys ex flow.

 

The sys ex messages are on all the MIDI tracks. I'm sure these sample screenshots will mean something crystal-clear to you as they certainly do not to me:

 

[Jordi Torres]

Hi,

 

it looks like some sort of clock signal... are there any sync settings you can adjust in the TAC2? MIDI Sync, WordClock sync, MIDI Clock....?

 

According to user Supremeja in the thread I linked above, the Sysex messages are used for communication between the TAC-2 and its MixEfx software. He got this info straight from Zoom, apparently:

 

Hello Logic Pro Forum

 

I'm Supremeja from germany. I have the same problem with the Zoom TAC-2.

 

Its not a failure or a bug. It's a strange feature.....

 

Zoom wrote me, the TAC-2® sends always SysEx Messages thru the OS X. The reason is horrible simple. The Audiosoftware MixEfx needs the SysEx Data to communicate between Hard and Software. You don't have any chance to stop this problem. You will receive the SysEx Data.

 

The next step/problem is when you record midi notes with you master keyboard then you record the SysEx data too. It sucks. The only way to eliminate the SysEx Horror is to set the SysEx Filter in the Projectsettings and disable the midi monitor in the transport window.

 

I hope it's useful for you.

 

J.

[gilmo]

I guess another solution is to unplug the TAC-2 except when it's needed for recording. Too bad because I'll miss the cosy setup of using it for the Mac's audio output routed through my mixer.

 

Also, wouldn't Suprema's suggestion "to set the SysEx Filter in the Project Settings" filter out the messages so they don't hijack the midi monitor in the transport window? He suggests not, and I can't test at the moment with the unit winging its way back to Sweetwater.

 

Do those screenshots in my post yesterday show the sort of sy ex messages that Supremeja described? All Greek to me.

[Jordi Torres]

Hi,

 

Also, wouldn't Suprema's suggestion "to set the SysEx Filter in the Project Settings" filter out the messages so they don't hijack the midi monitor in the transport window?

 

Using the MIDI input filter will prevent the messages from being recorded to your regions, but they will still show up in the MIDI activity display in the LCD.

 

To make them completely invisible to Logic you'll have to approach it differently, and whichever way you do it will have to be done outside of Logic.

 

Do those screenshots in my post yesterday show the sort of sy ex messages that Supremeja described? All Greek to me.

 

They're coming from the Zoom alright.

 

Do you have to have this MixEfx software running in order to use the TAC-2? If it's anything like Apogee's Maestro you may not need to and that may stop the messaging. I'm just guessing here.

 

J.

[gilmo]

 

Do you have to have this MixEfx software running in order to use the TAC-2? If it's anything like Apogee's Maestro you may not need to and that may stop the messaging. I'm just guessing here.

 

J.

 

It seems so from Suprema's info. As I said, there's no mention of MIDI in the TAC-2 user's manual. I sent a report of all this to Zoom with a modest hint that it could hurt sales of this unit. I'll share any response from them.

[minilq]

No, whether or not MicEfx is running, the Zoom interfaces always send out sysex info, which makes working with MIDI automation impossible.

[Elazmo Hiftenfifter]

One stopgap measure:

You can keep the sysex from being recorded by disconnecting the Zoom Tac-2 from the sequencer input in the environment.

Yes, it appears as an available MIDI input device in the environment, even though the unit has no MIDI connectors.

However, the sysex data will still be seen as if it comes from a control surface, so any MIDI learn attempts will require workarounds.

[Jordi Torres]

Hi,

 

However, the sysex data will still be seen as if it comes from a control surface, so any MIDI learn attempts will require workarounds.

 

Such a workaround could be hijacking the Zoom's MIDI port with MIDI Pipe:

 

 

In fact this will take care of the problem entirely: no Sysex recorded nor detected by Controller Assignments.

 

J.

[Sascha Franck]

Ok, just found this thread. Sorry for the bump. but:

I got a Zoom UAC-2 a few days ago. Absolutely brilliant for my needs (using it at home for DI guitar recording and such). Latencies are kinda world record in this price class.

However, that SysEx thing is driving me nuts. Besides, it's efficiently destroying anything "MIDI learn", makes my event list look like a trainwreck (I know I can filter SysEx event there...) and such.

My solution so far has been to disconnect the "sum" out of the physical input thing on the click&ports layer in the environment and only drag cables to the sequencer input (or to the MIDI monitor) coming from the devices I'm actually using (basically 2 controller keyboards and a BCR2000 every now and then).

But that's not exactly a great solution. I know I can save my own templates (and already did so), but rather often there's times when I just want to start from scratch - and I really don't want to fool around with that messy, clumsy, undersized physical input object.

 

So, here's the big question: What's the easiest way to keep the Zoom away from sending SysEx messages to Logic systemwide? Are there any tools allowing me to do something like that? Ideally, it would only filter the SysEx messages and not deactivate the MIDI port of the Zoom entirely as I may like to use it for my floor controller every now and then, but that's less relevant than the SysEx mess - that really has to stop. And it seems Zoom isn't interested to do anything against it (which is a major shame as the UAC-2 is absolutely great in all other aspects).

Will that MIDI Pipe thing be of any help?

 

Thanks for any hints!

 

- Sascha

[des99]

My solution so far has been to disconnect the "sum" out of the physical input thing on the click&ports layer in the environment and only drag cables to the sequencer input (or to the MIDI monitor) coming from the devices I'm actually using

 

Instead of doing that, leave the sum as it is, but simply cable the MIDI input of the device you want to mute to a dummy object (say, an instrument object set to no MIDI output).

Now that port is removed from the SUM output, and everything else works like before.

 

Will that MIDI Pipe thing be of any help?

 

You could use this to hijack and block that port, but again it's clunky as it requires you always remember to run MIDIpipe and choose the appropriate preset pipe setting. Give it a try, see if any of those things work for you.

[Sascha Franck]

Fwiw, just fooled around with MIDI Pipe - it works! But uhm, now I have to remember starting it each time I boot my machine.

 

As a possibly interesting information: This does NOT affect the Zoom MixFX software - that's still working normally, even with MIDI Pipe doing it's job.

So it should be a piece of cake for Zoom to adress the issue when a little freeware utility is doing the job just fine.

[Sascha Franck]

Instead of doing that, leave the sum as it is, but simply cable the MIDI input of the device you want to mute to a dummy object (say, an instrument object set to no MIDI output).

Now that port is removed from the SUM output, and everything else works like before.

 

Yeah, that would indeed be a better way in case I used the environment - so thanks, but...

 

You could use this to hijack and block that port, but again it's clunky as it requires you always remember to run MIDIpipe and choose the appropriate preset pipe setting. Give it a try, see if any of those things work for you.

 

... as said in my last post, MIDI Pipe does a good job. So I simply slapped the appropriate .mipi file into my startup objects - and *blam*, no more nasty UAC SysEx terror systemwide anymore. Should cost little computer resources, the only annoying thing being that MIDI Pipe will now always show up when I CMD/tab through my opened programs.

 

Fwiw, there's another nasty thing with the UAC-2. Their MixFX software starts at each boot - but there's no trace of this to happen anywhere, at least not in the startup objects. Is there any other place where one could have a look? I just don't like companies taking control over my computer, especially in case it's something as trivial as using an audio interface. I might even uninstall it for a try, I'm only using one setting anyway.

[Sascha Franck]

And fwiw, payback time. I'm now going to terrorize the Zoom support as good as I can.

[des99]

Fwiw, there's another nasty thing with the UAC-2. Their MixFX software starts at each boot - but there's no trace of this to happen anywhere, at least not in the startup objects. Is there any other place where one could have a look?

 

It's probably a launch agent or launch daemon, have a look in /Library/LaunchDaemons or /Library/LaunchAgents or use a gui app like LaunchControl to edit these.

[Sascha Franck]

It's probably a launch agent or launch daemon, have a look in /Library/LaunchDaemons or /Library/LaunchAgents or use a gui app like LaunchControl to edit these.

 

Thanks, that was it (LaunchAgents). Will try to delete that .plist file and see whether it stays away.

Already mailed the Zoom support. Having little hopes that they will actually respond, let alone fix these issues. but you never know.

It's a shame, really, I hate having to deal with such things - especially as it would probably be absolutely trivial for Zoom to fix them.

[des99]

Yer. I have a similar issue, where the HUI protocol requires a C-2 note "heartbeat" every half a second or so. It's communication between Logic and the HUI control surface, so Logic *shouldn't* display it on the MIDI in display, as control surface traffic isn't shown there - but Logic *does* show it, and it blinks away, constantly, and gets in the way of seeing valid incoming traffic.

 

Not a deal breaker, but certainly annoying...

[fuzzfilth]

Sascha, don't bother. Zoom couldn't care less. As far as they are concerned, the TAC and UAC series are a done deal. No more resources going into it, as little as it seems. Putting work into it would have them raise their prices. See ?

 

I use a TAC-2r and a TAC-8 in two separate rigs, so I'm right in the middle of this issue. Bottom line is, you need to filter Sysex pretty much at the Input of Logic or it will flood Logic's MIDI buffer and this will crash Logic if you stop a long (say, 1 hour) recording (MIDI and/or Audio, doesn't matter). The recorded files are on disk at least, but any MIDI recordings will be lost.

 

Yes, you could intercept Sysex with MIDIPipe, but would need to remember activating it everytime. Fiddling with ports of the Physical In object works but these ports will rearrange depending on the connected gear and this might break a virtual cable to a dead end, thus feeding Sysex into Logic as before. Also, globally filtering Sysex in the Project's MIDI Preferences does not prevent the buffer from overflowing. Been there, got the tee.

 

Here's how I swatted this particularly nasty fly:

 

To filter Sysex between Physical In and Sequencer In, you would put a Transformer inbetween and, well, set it to filter Sysex. If you could set Sysex as the Condition. But you can't.

 

Ok, you can't filter Sysex, but you can let through everything else, although not in one step.

 

Unless you collect exotic controllers like a Seaboard, the incoming data is actually quite simply structured: Notes, Continuous Controllers, Pitch Bend, Program Changes, Channel Pressure, Poly Pressure (although the last one's pretty uncommon already)

 

- from the PI object's SUM port, cable into a Transformer, set to Mode: Condition Splitter (true>top cable)

- Condition: Status: Note

- cable the Transformer's first port into the Sequencer In. This will pass through Notes

- cable the Transformer's second port into a second Transformer, set to Mode: Condition Splitter (true>top cable)

- Condition: Status: P-Press

...

- And so on until you have max 6 Transformers for all possible event types.

- The last Transformer's second port goes into a dead end object. This is where the dreaded Sysex ends up.

 

It's tedious once, but you save this as your Template and start from there.

 

Christian

[Sascha Franck]

First off, thanks for the detailed reply, Christian!

I already suspected the physical ins to move around, but to my surprise, regardless of what I did, once the Zoom was not running through the "Sum" out anymore, it always stayed inactive, regardless of whether I plugged my other MIDI devices in and out. Possibly because as it's coming from Zoom, it stays last in the list. It moved around, though, so I actually don't exactly know why it worked, it just did.

But...

 

Yes, you could intercept Sysex with MIDIPipe, but would need to remember activating it everytime.

 

As said above, I just slapped the .mipi file into my startup objects, problem solved. Even had a look at OSX' activity monitor, MIDI Pipes CPU useage is like not noticeable at all, so I guess that's what I'll be doing for the time being. As said, I often like to start with a blank canvas, so using a template might not be the best idea (I could however create a blank template with just the MIDI filtering active, I'll be having a look...).

 

Anyway, thanks for all your informative replies, folks. If someone finds an easier solution to deal with the Zoom interfaces, I'm all ears!

 

- Sascha

[volovicg]

project settings ->midi->input filter - check (enable) system exclusive....

 

[Sascha Franck]

project settings ->midi->input filter - check (enable) system exclusive....

 

Yes. But that will still show the SysEx messages in the transport bar - which I often use to monitor other things.

[volovicg]

Ok - the display of midi information in the transport is channeled from the physical input prior to it exiting - so any object you put post physical input won't work. A trick - is the control surface inputs are taken from the physical input before it is sent to the display ( so it is hijacked prior).

Open up control assignment and click learn while the sysex is transmitting ( unclick learn) and the sysex should not show up in the display nor the sequencer. You can then change the class / command to something you will never use ( ie. flip in the example below).

 

[Sascha Franck]

Ok - the display of midi information in the transport is channeled from the physical input prior to it exiting - so any object you put post physical input won't work. A trick - is the control surface inputs are taken from the physical input before it is sent to the display ( so it is hijacked prior).

Open up control assignment and click learn while the sysex is transmitting ( unclick learn) and the sysex should not show up in the display nor the sequencer. You can then change the class / command to something you will never use ( ie. flip in the example below).

 

Oh, now that might be a neat solution, especially as it's a global Logic thing, so pretty much set and forget. I'll check that out in a bit and report, thanks!

[Sascha Franck]

Ok - the display of midi information in the transport is channeled from the physical input prior to it exiting - so any object you put post physical input won't work.

 

Fwiw, this is not really true, the information of the transport bars MIDI monitor is grabbed at the sequencer input, so you can as well take care of that SysEx nonsense in the environment, but that's a projectbased thing which you would either have to save in a template or repeat for each new (or old...) project.