Data altering cable?

[nphuma]

I understand this is far more than MIDI and I am honestly very impressed by the wide conceptual horizon. But could somebody explain, what's the concept behind converting MIDI Note On messages with 0 velocity into Note Offs "on the wire"? It might be discussable if that is technically totally incorrect, but If I run a Mackie Controller over CopperLan's VMidi Ports I have all LEDs on after a short while and nothing ever going off. Can that function be turned off?

[CopperPhil]

Hi,

Thanks for your feedback! Actually, MIDI is not "transported" over CopperLan, it is "translated" in CopperLan in order to allow native CopperLan application to be controlled from a MIDI controller.

So the MIDI Note On velocity 0 is often used as a note off in the MIDI world. If we do not translate it in CopperLan "event gate off", we could get a CopperLan synth going out of voices. In CopperLan, gating, velocity and pitch are distinct information that can be transferred independently, so it's not safe to consider an "event velocity 0" as an "event gate off". We can do that during the MIDI to CopperLan translation, but not later.

And so, when you are using a "virtual MIDI cable" through CopperLan, MIDI messages are translated from MIDI to CopperLan (note on V0 -> note off), they are routed to the target device, then they are translated from CopperLan to MIDI (and of course you miss the note on V0...).

I'll have a discussion with the team to bring a solution (certainly a parameter related to "MIDI to CopperLan" devices to enable/disable the "note on V0" translation). In the mean time, if you need it I can provide you with a temporary build without this translation. Just tell me the platform(s) you are using (winXP, Vista/7 32 or 64, MacOSX?).

[Copperhead]

But could somebody explain, what's the concept behind converting MIDI Note On messages with 0 velocity into Note Offs "on the wire"?

Interpret a Note-on velocity zero as a Note off is mandatory according to the MIDI specifications.
The goal is to reduce latency (in physical MIDI serial transmission).

The following string of data (e.g. from a drum pad):
90h, 11h, 7Fh
80h, 11h, 00h
90h, 22h, 7Fh
80h, 22h, 00h

These 12 bytes can be reduced to 9 thanks to Running Status combined with the Velocity-zero rule, as follows:
90h, 11h, 7Fh, 11h, 00h, 22h, 7Fh, 22h, 00h

3 bytes less makes for almost one millisecond less in overall latency (exactly 960uSec)

[nphuma]

@copperphil:
Thanks, that's pretty much what I expected to hear. Don't think I need a temporary build now. I can patch my software to handle the note-offs, but obviously I can't patch my or anybody else's hardware controller. And what's probably more of a concern to you, I can't recommend anybody to try CopperLan as an alternative to other loopback drivers (I know it's far more...) in the moment, because that conceptual glitch just renders it completely unuseable. That said, given that "replacing MIDI" is probably the main route for CopperLan to make its way onto the harddrives of the average user initially, I think whatever solution you come up with, must not require user interaction and needs to be totally transparent from the "MIDI side". Hope you can sort that out, 'cause I have the feeling that you created something great here.

@copperhead:
I don't know what running status has to with the root of the problem here, but if you interpret that part of the specs to make it mandatory to convert a 0 velocity note on into a note-off on the transport layer, then you may want to go and tell that to Mackie and all those that have built hardware over the years that interprets it differently and won't work with your interpretation. Sorry to say, but I think that's bullshit. You have a serious bug in your product here and are grasping at straws.

[Copperhead]

@copperhead:
I don't know what running status has to with the root of the problem here, but if you interpret that part of the specs to make it mandatory to convert a 0 velocity note on into a note-off on the transport layer, then you may want to go and tell that to Mackie and all those that have built hardware over the years that interprets it differently and won't work with your interpretation. Sorry to say, but I think that's bullshit. You have a serious bug in your product here and are grasping at straws.

Cool down, there is no interpretation of any kind on my side.
The spec I'm referring to is part of the official MMA documentation and was written before Mackie and others re-used the MIDI protocol for purposes that were not intended initially.

The original paper version of the document I have in front of me is:

The Complete MIDI 1.0 Detailed Specification
Incorporating all Recommended Practices
document version 96.1
Published by:
The MIDI Manufactured Association
Los Angeles, CA

In the second section of the document, on page 10, the NOTE-OFF chapter begins with:

MIDI provides two roughly equivalent means of turning off a note (voice). A note may be turned off either by sending a Note-Off message for the same note number and channel, or by sending a Note-On message for that note and channel with a velocity value of zero. The advantage to using "Note-On at zero velocity" is that it can avoid sending additional status bytes when Running Status is employed.

So, you see there was no bullshitting at all

There's nothing wrong in redefining the use of MIDI messages (limitations had to be circumvented).
But if and when someone does that, he should be careful to not create a possible conflict with equipment that follows the book.
It was surprising to read that we have a serious bug because we stick to the rules

Now, as Phil said above, since we are good willing guys, in a future version of the CopperLan Manager, there will be an option to disable that MIDI feature that annoys the Mackie way of using MIDI.

Side note:
CopperLan is not just a transport layer. Actually, it populates the 5 top layers of the 7 layer OSI model.

[nphuma]

So be it.

I know the specs and I equally know that if running status was mandatory then probably 95% of gear and software out there, not just Mackie's (whom I got nothing to do with and am not here to defend) violates it.
Thing is, I very much like your product and would be interested in using it commercially (still waiting for something to happen on my registration, though). However if real world usability is a matter of goodwillingness and it takes an individual little musician and developer like me to discover problems with real world usability shortly after "the commercial roadshow" began, then I don't know if I maybe should think about that again.
"Bullshit" really only referenced your argumentation in the speciific context. The moment you act as a cable it does not matter at all how smart the whole system underneath is. Copperlan then is neither the sender (that should eventually take care using running status) or the receiver. Data that goes in one end must come out the other end without being changed on the way and I stand by the claim that this is a bug that's causing actual real world problems. I can imagine that this has a huge piggytail of consequences for you, but still altering data simply may make a good part of the system useless.

In return to your sidenote: I have repeatedly tried to point out that I am aware of how much more than a transport layer Copperlan is. Again: I like it, I think it has huge potential, but you have a problem there that won't go away by citing the MIDI specs or pointing out the number of protocol layers.

[sounds]

could somebody explain, what's the concept behind converting MIDI Note On messages with 0 velocity into Note Offs "on the wire"? It might be discussable if that is technically totally incorrect, but If I run a Mackie Controller over CopperLan's VMidi Ports I have all LEDs on after a short while and nothing ever going off.

Which Mackie Controller? I have the MCU Pro, and I'm wondering if I can reproduce the issue you're having. Which LEDs are the ones that get stuck on? What software are you using? I use Metric Halo Labs MIO Console, primarily, and Logic Studio Pro at other times. I also wrote MCU emulation software before I purchased a real MCU Pro, so I am very curious about which Note numbers you've having get stuck. Also, if you happen to know what except message is expected by the Mackie Controller to turn the LED off, and which "incorrect" MIDI message is being sent by CopperLAN, then maybe this could help suggest a solution.

p.s. I am not affiliated with CopperLAN, but I am very interested in keeping an eye on its capabilities.

[nphuma]

I don't think it matters what MCU unit or what software is in use here. I was using a M-Audio Projectmix with Cubase for this test, had Cubase send to VMIDI 2 and then routed that to the control surface's internal MIDI port in CopperLan Manager.

The "Mackie Protocol" uses Note Ons with velocity 1 to turn on LEDs on its buttons (like solo, mute, arm etc. Basically all of them) and Note Ons with velocity 0 to turn them off again. Now when you send a Note on with velocity 0 through CopperLan what you get out is a Note off:

input 0x90 0x10 0x00
output 0x80 0x10 0x00

Other than what was previously said by Copperhead, this has absolutely nothing to do with with Running Status, as also a sequence like this:

0x90 0x10 0x7F
0xB0 0x07 0x40 // clear running status
0x90 0x10 0x00

results in this

0x90 0x10 0x7F
0xB0 0x07 0x40
0x80 0x10 0x00

coming out of CopperLan.

So like CopperPhil said in his first reply, it's really about the general conversion of CopperLan's Gate Off event into MIDI Note Offs, regardless of how the original MIDI event looked like.
Of course it's a valid claim to some point that Mackie (and Tascam and M-Audio and Euphonix and Behringer and...) should also turn off LEDs on Note Offs (and some may even do), however there are hundreds of thousands of MCU compatible units out there, that do not do that and that will not work with CopperLan.

Other than Copperhead I do not believe that Average Joe, once he witnessed this, will go and browse the MIDI specs and then complain with Mackie. He will uninstall CopperLan, because that was the last thing added to the system and obviously what made it fail. Then he will post stuff like "CopperLan did not work for me. My Mackie Controller turned into a christmas tree and then the computer crashed because too much power was pulled from the USB bus. This sucks!" or something to some completely unrelated forum.

As this can not be in the interest of CopperLan's authors, I think they should do something about it (like adding a 1 bit flag to Gate Off events so they can correctly reconvert it to the original MIDI event). I'm pretty sure that besides MCU units there will be other MIDI hard and software that will also be affected by that glitch. There's just no point in pulling out some 25 year old specs when what you really need to work with is gear that may not always perfectly follow those specs but exists in large quantities in the real world.

[CopperPhil]

Well, a new package [build 1.0(7)] is available. You should be notified next time you launch the CopperLan Manager (except if you disabled the "check for new version at startup" feature), anyway it will be available shortly from the web site download page (check the date/version).

We have included a solution for the problem related here. The Note On Vel(0) is still translated to CopperLan Gate Off message, but it is restored as a Note On Vel(0) in case of CopperLan to MIDI translation.

So this makes MIDI to MIDI through CopperLan acting as a tunnel while remaining compliant with native CopperLan applications.

Let me know if your are satisfied with this new version!

/Phil

[nphuma]

You know this was not about satisfying me. Just thought it was critical enough to make some wind. However, yes I am very satisfied. Thanks a lot and sorry if it wrecked your weekend.
One thing to mention: autoupdating failed with write access problems to CpoEth.dll (not 100% sure about the name). Clean install worked, though.

I have started to play around with the API and will have some related questions. Not sure what part of the forum you prefer those in (it's neither going to be feature requests, nor is it bug reports for the moment). SDKs/Generalities?

Also whom should I contact with licensing related questions?

Thanks

nils