Midi Patch cable

8 posts / 0 new
Last post
Royce
Royce's picture
Midi Patch cable

Hi Mark.

I thought you might be interested in this site http://www.tobias-erichsen.de/software/loopmidi.html

It is a dynamic Midi patch cable like MidiYoke but it isn't an installable driver.

You create Midi ports as you need them.

Like MidiYoke it is great for examining what another program is putting out without  using a loopback Midi cable in a hardware Midi interface.

Tobias offers the source code in a SDK.

I thought I would incorperate it in to a new project of mine, but I thought it would also be a good addition to MidiTools.

I want to extend a Roland Editor by putting my program between the editor and the synth using MidiYoke.

Strangely with every Midi patch cable I tried (Midi Yoke and LoopBE1) the Roland software stopped working but worked perfectly with Tobias' program.

 

Royce

Mark van den Berg
Mark van den Berg's picture

Hi Royce,

About 2 years ago I first came across loopMIDI, in a forum discussion (can't find it quickly right now) about MIDI Yoke's problems with Windows Vista/7 (esp. 64-bit): Jamie O'Connell wrote that he wasn't going to update MIDI Yoke, but gave loopMIDI as an alternative.

LoopMIDI did indeed work for me, so I started mentioning it in the list of virtual MIDI I/O drivers in the MIDI Tools and BC Manager manuals.
I also made MIDI Tools and BC Manager recognize I/O devices with "loopMIDI" in their names as "MIDI pipes" (my term for virtual MIDI I+O devices): on first startup the user is asked whether s/he wants to enable or disable all MIDI pipes (this already applied to all MIDI Yoke devices).

However, a few months later I found that loopMIDI didn't correctly pass SysEx messages (or not at all - can't remember).
Around the same time, on his website Tobias Erichsen mentioned (in vague terms) a bug in loopMIDI, which may indeed have been the same bug I was experiencing.

Consequently, I focused on MIDI Yoke again, and last year I finally managed to get it working "perfectly" under Windows 7 64-bit (see the manual for BC Manager 2.4.2, section 6), at least for 32-bit DAWs.
However, if I've understood Jamie correctly, MIDI Yoke doesn't work with 64-bit DAWs. I've never tried this myself, but if this is so, this is of course a "terminal" problem.

Meanwhile, I think the bug in loopMIDI has been fixed (though I can't remember whether I've actually verified this), so in the end loopMIDI indeed seems the best solution. (Though, as you mention, the drawback is that loopMIDI devices don't persist after a reboot.)

I now see that the link to the loopMIDI website in the BC Manager and MIDI Tools manuals is buried in the "version notes" section; I'll move the link to its proper place, i.e. the "MIDI setup" section.

The existence of the loopMIDI SDK is new to me, let alone the idea of using it in MIDI Tools.
So thanks very much for pointing this out!
I'll start thinking about it.

Mark.

JAPP
JAPP's picture

Hello Mark,

I just thought I would mention another tool - the Copperlan Midi Manager - give it a google some time. I've been using it for 4 or 5 years now and can honestly say that I can't ever remember having any problems with it. It seems to be as solid as a rock.

JAPP

Mark van den Berg
Mark van den Berg's picture

Thanks very much for mentioning this. I had never heard of it.

I've tried it briefly now. My first thoughts:

  • Its primary focus is MIDI connections between computers via Ethernet, so it's a bit of overkill for users who don't need that. (During installation it installed three drivers, if I remember correctly.) Tobias Erichsen offers MIDI-over-Ethernet too ('rtpMIDI'), but that's separate from his loopMIDI, which is thus much more lightweight: just virtual MIDI ports on one computer. (I haven't had any experience with rtpMIDI - it might be interesting to compare rtpMIDI and CopperLan.)
  • loopMIDI and many (all??) other virtual MIDI port systems offer pairs of ports (what I call 'pipes' in my manuals): MIDI data sent to output N is automatically received at input N. However, in CopperLan this is not the case: you have to connect an output port to an input port manually.
  • I don't particularly like CopperLan 1.4's user interface. For instance, connecting a virtual output and input port seems much more complicated than it should be. But maybe it's a matter of getting used to it.

In any case I'll add CopperLan to the list of virtual MIDI port systems in my manuals.

Mark.

Alex71 (not verified)
Anonymous's picture

It seems Sysex does not get passed from a Midi Input Device to its selected Thru Output Device. Regardless of whether we're using Midi Yoke or LoopMidi ports.

Can this be made possible?

I've been using MidiTools for a while now. It's awesome to the point that it had completely replaced MidiOx for me, until I ran into this issue. Thanks.

Mark van den Berg
Mark van den Berg's picture

This issue is discussed at length in section 14 ("Known problems") of the MIDI Tools manual.

To summarize:
MIDI Tools simply sets up Windows' MIDI Thru facility, which doesn't pass SysEx.
So to make MIDI Tools pass SysEx I'd have to set up a completely new, independent Thru system.
This would probably be a lot of work, because it requires an independent SysEx buffer system: very tricky.
The fact that MIDI-OX already has such a system, has also been a reason why I haven't got round to implementing this (why reinvent the wheel?), and I won't have time in the foreseeable future, but who knows.

Mark.

Royce
Royce's picture

HI Mark,
 after all that trouble I had with that Delphi Midi code I showed you, I found some Midi Components that have worked really well and make sysex transfer really easy.

https://bitbucket.org/h4ndy/midiio-dev/

It comes with Delphi source you you can make changes if you need to.

I had to re-write a bit to make it work that way I do in C++, but I haven't had too much trouble.

 

All the best

Royce

Mark van den Berg
Mark van den Berg's picture

Hi Royce,

Thanks very much for the reference.
As I stated in my reply to Alex71's complaint, I won't have much time for programming in the foreseeable future, but if and when I do, the code at Bitbucket may indeed prove useful.

Cheers,
   Mark.