MIDI Merger Running Status Problem

[chrisaxeman]

Hello,

Long time since I posted here, but here I go (hope it's the right place) .

I'm hoping for some ideas for a MIDI merger that doesn't implement running status. I've no idea where to start.

I've tried mergers from M-Audio, MIDI Solutions (the best of them) and a Kenton (hopeless), they all implement a degree of running status.

For the uninitiated (just my understanding, hope it's correct), MIDI running status is used to streamline data in MIDI. And it does this by sawing off like status bytes in MIDI messages, that being the MIDI message type and MIDI channel. This might be all fine and dandy for a keyboard player, but for a guitar player using multiple MIDI messages of the same type (especially control changes/CC's), it can cause all sorts of dramas like MIDI lockups and lockouts.

For those interested,I have a pretty complex MIDI controlled rack rig. Without going into War & Peace, I've had to use a MIDI merger to mix the main footcontroller (Axess FX1), MIDI clock (polytec 34One), and a MIDI Solutions Dual Footswitch Controller. This is due to the fact the FX1 doesn't have MIDI thru capability

Where should I start?

Cheers

Chris.......

[MoltenVoltage]

Hi Chris,

Glad to see you understand the advantages of MIDI-controlled gear!

Running Status is actually a great feature of MIDI, as MIDI bandwidth is relatively limited (by today's standards).  However, running status has nothing to do with MIDI Clock, as clock data ALWAYS takes priority over any other type of MIDI message.  Also, running status should never "saw off" the controller value, only the message type/channel which is the first byte of the 3 that make up a control change message.

We make a MIDI Clock Injector that can replace your polytec and merges Control and Program Change messages received with the MIDI Clock it generates:
http://www.kaom.com/TEMPEST_Pedalboard_MIDI_Clock_Injector_p/built_009.htm

Here's the manual:
http://www.moltenvoltage.com/downloads/Tempest_-_PedalSync_MIDI_Clock_Injector_-_Owner%27s_Manual_-_Molten_Voltage.pdf

TEMPEST also stores the tempo associated with 128 programs

If you want to build something, we make a kit of our PedalSync MASTER CONTROL which outputs MIDI Clock:
http://www.kaom.com/PedalSyc_MV_58_Master_Control_Footswitch_Complet_p/kit_002.htm

I'm surprised the MIDI Solutions Dual Footswitch Controller doesn't merge well, since it has a MIDI In and the product page says "Triggered MIDI events are merged with incoming MIDI messages and sent to the MIDI output of the Dual Footswitch Controller."  Perhaps if you put it in this order: Axess, MIDI Solutions, TEMPEST, rig, that will solve your problems.  It really depends on how good the MIDI merge of the MIDI Solutions device is.

It sounds like the MIDI Solutions might not segregate CC messages that come from different sources or on different channels.  If you want to see what is happening, try using MIDIOX or some other resource and slowly input single control change messages from your Axess into the MIDI Solutions device, and from the MIDI Solutions device itself, then monitor the MIDI Solutions output with MIDIOX.  You might find that the MIDI Solutions device works fine and the problem is in the device being controlled, but maybe the issue is with the MIDI Solutions.  Please let me know what you find.

- William

BTW, we've stared a blog to educate people about using MIDI Clock to sync their pedalboard:
http://blog.moltenvoltage.com/

[chrisaxeman]

Hello William,

Very interested in the Tempest. Just noticed though in the MIDI implementation list, that it generates CC data. What is the CC data, I can't find it in the manual?

Is it possibly incorporate the functionality of the MIDI Solutions footswitch controller into a product like Tempest?

I really only need a piece that can pass data from in to out, add clock and allow two swicth input that will send a pair of CC's.

Cheers

Chris.....

[MoltenVoltage]

Hi Chris,

Tempest does not generate any CC information, it just passes it through.  The original plan was to convert CC value information from one channel to another, but I changed my mind.

Are you using expression controllers into the MIDI Solutions device, or just 2 footswitches that send single commands?

- William

[chrisaxeman]

Hi Chris,

Tempest does not generate any CC information, it just passes it through.  The original plan was to convert CC value information from one channel to another, but I changed my mind.

Are you using expression controllers into the MIDI Solutions device, or just 2 footswitches that send single commands?

- William

Sorry William,

Busy week at work, and wanted to study the Tempest manual a bit more closely.

No exp's on the MIDI Solutions (Axess controller handles these), just 2 switch inputs that send single on/off CC comands, as I ran out of sw/exp ports on the Axess (can be assigned to switch or exp, but has 4, I needed six).

Really like the look of the Tempest. If I could have something that could do its job, as well as the two switch inputs (to replace the MIDI Solutions box), I'd be all over it.

Only thing I don't dig I can see with the Tempest is the fact that 3 channels get tied up with it's implementation (1,2&15 - I can see that it is part of intergration with other products in the line).

Is it possible to have it respond to MIDI CC and PG data on only one channel?

I'm already using 11 channels in this rig, and don't want to tie up 3 more for one device. With the Tempest, two channels really become redundant in a multi channel control system (the Axess sends independent data over all 16 channels if need be, but the Tempest means only 14 are useful, if you follow me). For my needs, that is an extra complication to be thinking beyond "one device=one channel", and my rig is too complex now

Cheers

Chris.....

[MoltenVoltage]

Hi Chris,

I could program a custom version that only respond to commands on one MIDI channel.

Send me an email at questions@MoltenVoltage.com

Thanks again,

- William

[chrisaxeman]

Cheers William,

I will be in touch - removing the channel 15 functions would possibly be better (some patches might be best auto-starting clock, others manually).

But first I'm intending to use MIDI OX and monitor what's actually happenning. I want to get all of my ducks in a line first, I've crashed a bit of money on this problem and not got a result.

I've spent all day testing, and the problem lies in the fact the Merger implements running status when multiple devices are transmitted to, and as a result I've got CC's floating around without a channel number. Even with the Tempest, I'm still dealing with the same amount of data - it may not be a magic bullet as I'll still need to merge it's output and the footswitch controller into the merger.

I'll work it out, hopefully.

Chris...

[MoltenVoltage]

Hi Chris,

I thought about it and am going to put a channel select routine on power up under certain conditions.

If you are really going to use Channels 1 and 2, then maybe I need to make it with 4 options (1, 2, 15, 1 & 2).  What do you think?


Which exact MIDI merger are you using?

If it really can't keep the running status data from different sources separate, then I might need to build a better one.

- William

[chrisaxeman]

Hi Chris,

I thought about it and am going to put a channel select routine on power up under certain conditions.

If you are really going to use Channels 1 and 2, then maybe I need to make it with 4 options (1, 2, 15, 1 & 2).  What do you think?


Which exact MIDI merger are you using?

If it really can't keep the running status data from different sources separate, then I might need to build a better one.

- William

ATT: Mods: If you would like me to take this offline with William, please let me know. Some of the fault finding info might be useful for those who delve into MIDI, but I don't make the rules.

William,

Long post warning, but this is doind my head in, and excites me as well (as sign of insanity I believe).

As I mentioned, I'm not going to pull the trigger until I'm 100% on what's going wrong. I've bought 3 mergers at $ub$tantial co$t (a specialised part that are hard to sell on), that have not fixed it and have worsenned the problem in some instances (Kenton Merger made it worse, but I was warned by the maker )

The real problem stems for the fact that running status strips the channel number and message type. That's fine for a keys player, who isn't sending too many of the same message types at once across multiple MIDI channels. Sub in a guitar player with a larger MIDI system that can be sending similar messages across multiple channels, well running status means there could be channeless data bouncing about.

Here is a bit of history about what is happenning.

Current Merger is a MIDI Solutions Quadrmerge. It merges MIDI data from an:

-Axess FX1 MIDI Controller (this is the main system contol).
-MIDI Solutions Dual Footswitch Controller (provides two external switch inputs that sends an on/off MIDI CC each)
-Polytec 34One pedal (sends clock/start/stop, and a CC to start an arpegiator {which I don'y need)

If you get 5mins, have a look at the MIDI Solution FAQ's where it mentions that all of the products inplement running status (actually becomes cumulative if you series his products), resend the status byte at intervals (causes zippering with continuous controllers), and admits that it will causes probelems with equipment that doesn't recognise running status (Line 6 M5 in this rack, and I suspect the MIDI VCA's in line mixer I am using, and possible the Whammy 4 also).

Initially, the MIDI circuit on the control board (pre-rack) was wired like this:

FX1>MIDI Solutions Dual Fooswitch Controller>MIDI Merger In1 >Out to rack
Polyetc 34One>>>>>>>>>>>>>>>>>>>>MIDI Merger In2>

Now the dual footswitch controller would cause any data from the continuous pedal ports to zipper. My whammy and VCA's audio would zipper when I was pedalling them from the FX1 (as I say, between the the two MS products, the running staus become cumulative).

So, I built a 5vdc supply for the footswitch controller, so there would be no data passing through it (I build a lot of my own gear). The MIDI circuit was re-configured like:

FX1>>>>>>>Merge in 1
Dual Fsw Con.>Merge In 2>MergeOut to rack
Polytec 34One>Merge in 3

This alleviated the zippering prob. But an existing problem is:

If the Polytec is running (so a start command, clock and MIDI CC#90 on channel1 at level 127 is sending), if I operate the FX1 continuos control port for the Whammy 4 (CC#11 on Channel 3), the Line 6 M5 (on Ch5) goes to bypass (and stays there, I have to physically re-enable it).

Initially I thought the M5 was on the wrong channel (no it wasn't), but it's bypass CC# just so happens to be #11 also. I suspect once the Polytec starts running, the merger implements running status, the channel number of CC#11 messages go missing, and when I send the FX1's CC port (#11) to a value below 64, the M5 switches off.....this can be avoided by switching the clock pedal back off once I've set tempos to the rack, but it's another complication in a complication.

Thta's just an example, the Axess has got something to do with it, I used to use a Rocktron All Axess with some of this gear and had no issues. The FX1 doesn't seem to be very conducive to working with other gear in a joint control system - it needs to be in charge. But by trying overcome it's shortage of no MIDI thru capability, and an inadequet amont of pedal/switch ports, I've created new issues.

There is no question I'm sending a heap of data (as I said, there are 11 channels of various messages, but all the same MIDI was meant to be real time), but I've yet to really get down to sending all of the data I would like to, until I know it's not gonna get sawn off and turn the rig into a big piece of crap and no fun to use.

I've been delving into complex MIDI guitar rigs for years, and am very frustrated I can't get this working prpoerly (a lot of time and effort to not have it work the way I want).

Sorry about the long post.

Chris..........

[MoltenVoltage]

Hi Chris,

First, a merger should keep track of the data coming into each port and re-insert the first byte if it is merging running status data from multiple sources and/or multiple channels.  Based on their FAQ, I'd be surprised if the MIDI Solutions merger doesn't do it right, but take a look at the output using MIDIOX and see what you find.

Second, the Polytec appears to send CC 90 messages on Channel 1 simultaneously with start and stop.  It also doesn't look like you can disable that function.  That is not an issue with TEMPEST, which only sends MIDI Start, Stop, and Clock.  You should be able to use TEMPEST at the end of the chain (after the merger).

Keep in mind that System Realtime messages (Start, Stop, and Clock) must always take priority over all other MIDI data, per the MIDI protocol.

- William

[chrisaxeman]

Hi Chris,

First, a merger should keep track of the data coming into each port and re-insert the first byte if it is merging running status data from multiple sources and/or multiple channels.  Based on their FAQ, I'd be surprised if the MIDI Solutions merger doesn't do it right, but take a look at the output using MIDIOX and see what you find.

Second, the Polytec appears to send CC 90 messages on Channel 1 simultaneously with start and stop.  It also doesn't look like you can disable that function.  That is not an issue with TEMPEST, which only sends MIDI Start, Stop, and Clock.  You should be able to use TEMPEST at the end of the chain (after the merger).

Keep in mind that System Realtime messages (Start, Stop, and Clock) must always take priority over all other MIDI data, per the MIDI protocol.

- William

Hi William,

Am back into the working week, so won't be able to touch things for a few days. I tried a few things yesterday, and it appears that when the Polytec is running, the trouble starts. And that correlates with the clock data taking precedence.

I have to accept I'm sending a lot of data from the FX1 (11 channels is the biggest rig I've ever built - bit of spinal tap there ). The FX1 manual even sounds a warning about sending too much data, as it can send far more stuff than MIDI can take.

As you quite rightly assert,the merger is really doing what it is designed to do. I'm looking at work arounds, like using the Tempest actually inside the rack and controlling it via CC's, so the Clock data just gets to where it has to go (the rack splits MIDI to each of 4 drawers via a MIDI thru box, only 2 of them need the Clock data). And as you say, I can insert the Tempest after the Merger (depending how well it behaves running status wise ).

Be back in a few days........tbc......

Chris.....

[TauTau]

did you find a solution to this? I'm currently struggling with problems with a Peavey Vypyr and Sanpera2 when there's a midi merger in between...

(sorry for necro thread, didn't get a reply to a new one, hoping the the original poster might see this )

[ElectricDruid]

The trouble here isn't dealing with a "MIDI problem". It's dealing with a problem in either the device which is sending MIDI information (like a MIDI Merger which screws up running status - that's simply faulty) or a receiving device which doesn't understand what it's being sent.

The MIDI spec is pretty clear about most of this stuff, and there's years of precedent for all the slightly borderline cases. Can you tell it bugs me that people still get it wrong? Especially in major manufacturers gear! Jeez! Drives me crazy!

The OP shouldn't actually be having the problem they're having, if I understood it right. Something is broken somewhere is all, and the solution shouldn't really be to throw more hardware at it to find a workaround, although that is often what happens to get things going.

Tom

[TauTau]

sure... but since I can't fix the midi implementation of that amp or pedal, I have to look for a workaround