Page 1 of 3

Midi over ethernet

Posted: Fri Jul 10, 2009 11:59 pm
by Alex
I've just read a bit of info about midi over ethernet, written by our very own Sbenno.
It's currently a win only app, but Sbenno, how's the linux version progressing?

You'll see another thread here from dougal2, concerning challenges with porting midi across 2 machines, win and lin, and i wonder if your app would sort this out rather nicely.

:)

Alex.

Re: Midi over ethernet

Posted: Sat Jul 11, 2009 12:02 am
by dougal2
Is that the UDP based standalone app that requires a separate local midi-loopbak driver (like maple) ?

I have tried this with reasonable success between windows-windows. In fact the instructions for it is how I first became aware of Maple Virtual MIDI Cable.

Any cross-platform developments on this would be most interesting.

Re: Midi over ethernet

Posted: Sat Jul 11, 2009 1:03 am
by dahnielson

Re: Midi over ethernet

Posted: Sat Jul 11, 2009 1:04 pm
by sbenno
Hi,
yeah, EthernetMIDI needs a complete overhaul, I get a few emails per month from users asking about news :)
the number of monthly downloads is comparable to the number of downloads of LS, I find it interesting since the app was mainly a quick
technology demo.
The idea is to port EthernetMIDI to Qt4 and make it cross platform. the hard part is finding the time to do it :)
I was discussing with cuse about integrating midi and audio over ethernet in LS VST and use real linux boxes as sampler slaves.
One solution could be using netjack and jack as an intermediate layer but we think it would be better to implement it directly in order to
achieve maximum performance.
The advantage of such a solution would be very low resource usage on the windows VST box and low cost 64 bit LS linux slave machines,
no audio and midi interfaces needed.
And yet another advantage would be no more 16 MIDI ports limitation on Windows since the virtual midi ports would appear only in the LS VST
plugin.
Once the concept works it can be easily adapted to support all plugin standards LS supports (VST,AU,dssi,LV2 etc).

cheers,
Benno

Re: Midi over ethernet

Posted: Sat Jul 11, 2009 1:28 pm
by Alex
sbenno wrote:Hi,
yeah, EthernetMIDI needs a complete overhaul, I get a few emails per month from users asking about news :)
the number of monthly downloads is comparable to the number of downloads of LS, I find it interesting since the app was mainly a quick
technology demo.
The idea is to port EthernetMIDI to Qt4 and make it cross platform. the hard part is finding the time to do it :)
I was discussing with cuse about integrating midi and audio over ethernet in LS VST and use real linux boxes as sampler slaves.
One solution could be using netjack and jack as an intermediate layer but we think it would be better to implement it directly in order to
achieve maximum performance.
The advantage of such a solution would be very low resource usage on the windows VST box and low cost 64 bit LS linux slave machines,
no audio and midi interfaces needed.
And yet another advantage would be no more 16 MIDI ports limitation on Windows since the virtual midi ports would appear only in the LS VST
plugin.
Once the concept works it can be easily adapted to support all plugin standards LS supports (VST,AU,dssi,LV2 etc).

cheers,
Benno
Sounds like a great plan.

What about a command line version for Linux? LS could pick up the ports at one end, and the DAW can pick up the other end? Or have the ports visible in Qjackctl, or patchage?

Just an idea.

Alex.

Re: Midi over ethernet

Posted: Sat Jul 11, 2009 1:59 pm
by dougal2
That indeed sounds like an awesome plan. However, I know from experience that awesome plans take quite a while to implement.

Any chance of a quick fix-up and/or linux release in the mean time ?

Re: Midi over ethernet

Posted: Sun Jul 12, 2009 7:04 pm
by dougal2
edit: post removed due to lack of research before posting.

Re: Midi over ethernet

Posted: Mon Jul 13, 2009 12:06 pm
by moonskin
I'd love to have a standalone linux client.

Miditzer runs brilliantly on a windows box when set to high priority. It's sluggish under WINE.

I'd like to run Miditzer under windows and then send the MIDI (only) output to LS on another Linux box.

This would allow me to spread the processing load but especially to have the organ console (with windows box) linked remotely to the sound generation / amplification end of things.

Cheers
Graham

Re: Midi over ethernet

Posted: Sat Jul 18, 2009 10:51 am
by moonskin
Further to this topic, I came across multimidicast (http://llg.cubic.org/tools/multimidicast/ and I'm wondering whether we could be lucky enough to have it talk to ethernetMIDI if the ports were set correctly. Multimidicast claims to be compatible with ipMIDI.

I intend to try and test it by checking if ethernetMIDI will listen successfully to ipMIDI before I attempt to see if it will compile for Puppy Linux (Somehow I'm not confident.)

Cheers
Graham

EDIT: The answer is no. :cry:

I might try and have a look at the code for ethernetMIDI to see if I can rewrite it to send data in a way that ipMIDI (and multimidicast) understands. ( :ugeek: Yeah! in my dreams!)
I'll get back to you in the next life when I actually understand what I am doing. ;)

Re: Midi over ethernet

Posted: Sun Jul 19, 2009 3:02 pm
by dougal2
I had a look at what ethernetMidi sends over the net and successfully got a python script to listen to it on a linux machine. It appears the MIDI data is just sent raw, a packet at a time. I can easily print to screen the raw MIDI packets as a hex dump.

I also managed to get the same script to be a Jack MIDI client, however due to only having the high-level API available for Jack MIDI, I haven't yet worked out how to pipe the raw data into Jack.

At present, it looks like I'd actually have to write a MIDI parser, and then re-construct all the messages using Jack's API, which seems like a lot of pointless overhead.

Additionally, of course, ethernetMidi also only forwards a single MIDI port (due to the way it does direct MIDI -> network packet forwarding), so efforts in this direction are of limited use.

It would probably almost be easier to adopt another existing protocol (are the specs for ipMidi available?) and make all clients/servers compatible.