View Full Version : EthernetMIDI, free MIDI over Ethernet tool released !
sbenno
07-17-2005, 08:39 PM
Hi guys,
as promised here is the first version of a free, open source MIDI over Ethernet tool.
It has no restrictions, use it on as many machines you want.
You can forward MIDI from one machine to as many machines you want.
The initial version is Windows only, but an OS X and Linux version will follow soon.
I tested it using the following setup:
Windows XP machine 1:
Winamp plays a MIDI file -> MIDI data forwarded over ethernet
Windows XP machine 2:
MIDI data coming from ethernet -> USB MIDI interface (Midisport 2x2) -> Roland Soundcanvas SC-88
I played dozen of files (on machine 1) and it works fine.
As said this is an initial version we can improve things further.
If you have suggestions, ideas, problems or feedback let me know (you can post here too).
BTW: my tool requires either the Maple MIDI tool or equivalent ones (MIDIYoke).
Maple works fine and is reported working fine with GigaStudio too (MIDIYoke does not work with GigaStudio, see EthernetMIDI README file).
BTW: the Maple site: http://www.marblesound.com/
seems not working so at the moment you cannot download it.
Can someone contact Jeff about this ?
PMI has an older version on their site.
If he has hosting bandwidth problems I can mirror the tool without problems if that's ok to Jeff.
Here the link where you can download EthernetMIDI:
http://www.linuxsampler.org/ethernetmidi/
let me know your experiences with the tool.
cheers,
Benno
Garritan
07-17-2005, 08:48 PM
Benno,
Fantastic tool you are providing. This is going to be very helpful for many of us. That's very generous to provide this tool to the community.
I spoke with Jeff this morning and his site is down and he expects to have it back up soon.
Gary Garritan
The screen shot makes it look like it works only with a fixed ip. Is this the case?
sbenno
07-17-2005, 09:15 PM
Thanks Gary, it will get improved further over time, providing more flexibility and ease of use (eg saving network midi setups useful when dealing with a larger number of machines).
Bill:
in what sense works only with a fixed IP ?
Basically when you send data over network you have to specify an IP address or a DNS name (eg yourhostname.com).
Do you mean working in LAN enviroments where all machines use DHCP to automatically obtain the IP address ?
In that case my tool cannot know the IP address of a certain machine without using some kind of address discovery mechanism.
For now to see the IP address of your machines just
do
Start -> Run Command and enter
cmd
it opens a DOS window.
here you enter the command:
ipconfig
and press RETURN
it displays the IP address assigned of the machine.
for example: 192.168.0.20
Adding a IP discovery mechanism by assigning names to machines would not be a big problem but it's not my priority now.
In my opinion, in case of audio networks it's better to use fixed IP addresses anyway.
cheers,
Benno
JonFairhurst
07-17-2005, 11:36 PM
Very cool.
I run MIDIoverLAN+ (the older version, before CP), and found it best to use with fixed IP. You can use computer names, but you will then have to start your machines in a particular order, or else things don't work, or hang. forcing reboots to fix it. With fixed IP, I can start only the machines I need in whatever order I want.
Fixed IP is the way to go for Audio/MIDI LAN software.
-JF
Benno,
I'm looking forward to giving this a try. Given your openness with it, I wonder if it might be a good fit to become a project at www.sourceforge.net.
Best,
Stefan
Marcussen
07-18-2005, 06:43 AM
Awesome Benno... thanks! :)
Sounds very good. I'll give it a try.
KevinKauai
07-18-2005, 09:10 AM
Benno, this looks very intriguing.
Here's a specific usage scenario and questions:
[1] Cubase SX running on primary Windows XP system;
[2] Stand-alone Kontakt 2 running on second Windows XP system; Set up a "bank" of (say) 16 instruments in the (remote) Kontakt 2 specific to the project at hand;
[3] Can the sequencer (Cubase SX in this case) send a group of MIDI signals over your "device" to be received by the Kontakt 2 stand-alone application?
[4] Would it then be feasible to take (for example) a S/PDIF stereo audio out from the second Windows XP system (where the Kontakt 2 stand-alone app is running) and bring it into the S/PDIF stereo audio input of a "sound card" (or sound box, such as the M-Audio Firewire 410)?
[5] Does the sequencer then simply process the incomring audio as if it were an "outboard" audio instrument and are we "home free" ?
Thanks, in advance. (I am still trying to figure out manageable ways of getting more capacity and I have a spare Windows XP 2.66 gHz system.)
KevinKauai :)
PolarBear
07-18-2005, 01:36 PM
Awesome! Thanks Benno. Anyone knows how much latency it introduces compared to running Midi-File and Sampler on the same machine?
Thanks,
PolarBear
Tobias Erichsen
07-18-2005, 01:48 PM
Hi Benno,
is there any specific reason, why you have implemented this
as an application instead of a user-mode midi-driver?
If implemented as a midi-driver, one would not need to use
any loopback-midi-drivers to use it with applications?
I have already implemented a driver which runs over the
network which has minimal latency - but I have not yet
released it, since I'd really like to make it compatible to
the new Apple Tiger network midi - unfortunately I don't
own an Apple and all the people I know only have 10.3,
so I was yet unable to get an ethereal-trace of the
Apple network-midi communication...
Tobias
Bruce A. Richardson
07-18-2005, 02:18 PM
Hi Benno,
is there any specific reason, why you have implemented this
as an application instead of a user-mode midi-driver?
If implemented as a midi-driver, one would not need to use
any loopback-midi-drivers to use it with applications?
This, or something which appeared to the user like this, is also a direction I'd suggest encouraging (perhaps through the open-source community).
Do you mean working in LAN enviroments where all machines use DHCP to automatically obtain the IP address ?
Also, having now read the explanations of fixed-IP issues, I understand why my initial stab at getting this running was not working out for me.
Although I understand the logic of a fixed IP network, I have been using a DHCP "automatic" assignment routine. I have a studio in my home, but also a studio at my theatre. I just unplug machines from one network, pull the racks, and plug them into the other.
Although perhaps this is not a high priority, my idea of the most ideal tool would be one where the user simply invoked it, and every single aspect of the installation was "sniffed, searched, presented, and plugged," so to speak. Something so automatic and automated that a person who cannot decipher a VCR could do it (although I must admit that VCRs tend to confuse me more than complex computer applications).
None of this is to say that I don't consider this tool a generous and amazing piece of work. I am just presenting suggestions which are unfiltered "ideal world" ideas. I think the major problem with MIDI over LAN and other devices of this type is that they don't present a more abstracted "top layer" UI, which speaks the language of non-computer musicians. I think that obviously one needs the fine level and detail of control that only "network-speak" can deliver, but that this might not be the best top-level UI for musicians in general.
I would equate it to the difference in the "surface" UI of Reaktor, versus, the Structure View where everything is actually configured and routed. Under there, it looks very complex. On top, it looks very simple, and everything is happening automatically underneath.
I have some stuff to get through today, but when I have finished it, I will try to make time to draw up some ideas that would illustrate what I am talking about...that would probably make more sense than babbling on about it for paragraphs and paragraphs.
Best regards,
Bruce
> Do you mean working in LAN enviroments where all machines use DHCP
> to automatically obtain the IP address ?
Yes, I also use DHCP. With MIDIOverLan, I use the computer name. I haven't had any problem with that, although maybe I'm booting in the needed order without knowing it.
sbenno
07-18-2005, 02:31 PM
sbkb:
the parent project (LinuxSampler) already uses some facilities of sourceforge like the developer mailing list , but we use our own web space and code repository since sourceforge had some reliability problems so we opted to set up our own web/development infrastructure.
Kevin:
yes you can do what you said easily. Just install a virtual MIDI port and fire up EthernetMIDI on each PC.
On the cubase PC you send out the MIDI data to the virtual MIDI port and tell EthernetMIDI to forward data to the host running Kontakt.
On the Kontakt PC you tell EthernetMIDI to output the data to the local virtual MIDI port and tell Kontakt to receive MIDI from that port.
That's all.
PolarBear:
I expect the pure MIDI latency be very low in the order a few 1/10th of milliseconds max.
If you run a slave PC with a sampler and feed back the audio to the sequencer PC via analogue/SPDIF in then the latency will be mostly determined by the audio buffer size you use on the slave PC and on the sequencer PC. But I guess it will be in the same order as running the sampler locally.
What you will loose is sample accuracy, just like when you use hardware MIDI interfaces to drive MIDI devices (either hardware or PC based) from your sequencer.
But people are using sequencers and slave GigaStudio machines (which do not provide sample accuracy) all over the place. So it means its usually ok except in some very rare cases.
Tobias:
We already exchange private mail about technical issues.
Perhaps we can join forces to improve the project even further.
As you told you in the private mail I made a normal user space application (instead of a driver) because it is easier to maintain across operating systems, easier to make it cross platform and the difference between a low level MIDI over ethernet driver in terms of performance is probably negligible.
I performed lots of testing and I could not hear either latency or timing problems.
Folks, please try it out, put the tool under stress and let me know about your findings.
cheers,
Benno
Dave Bourke
07-18-2005, 04:21 PM
Nice one, Benno, and thanks very much! I'm looking forward to trying the Mac version of this.
Kind regards.
gugliel
07-18-2005, 06:34 PM
Good work! Benno, if you haven't already you might look at the free midi over ethernet in the package called "div's midi utilities for windows". Source code is included, and you can check out how the hostnames are resolved in netmidic.c. (Uses the call "gethostbyname" in c, probably part of the windows c library?)
When i use this package, I give host names, not fixed ip addresses, then my dhcp network works fine. Nice to have another alternative, none of my explanations to other people seemed adequate to get them running with div.
sbenno
07-18-2005, 07:33 PM
Guglielmo,I already implemented hostname lookup in this version, you can use them too.
I use the replacement function of gethostbyname (which is obsolete): getaddrinfo
I don't know how this works in DHCP enviroments under Windows. I thought it resolved only names to IP addresses by querying the DNS ? (or the lmhosts file but it must contain fixed IP addressed)
Can you specify a windows machine name in the address field and have the windows look it up for you by resolving it to an IP address ?
cheers,
Benno
sbenno
07-19-2005, 06:32 AM
Hi Bruce, thanks for your comments.
Please outline your idea regarding the ideal user interface when you have time.
Don't worry, over time EthernetMIDI should become as user friendly as possible. (with all the VCR-like fluff).
My point was, first one needs to build solid foundation walls in a house, then think about the ornaments. And the MIDI streaming routines are the foundation walls of the application.
Without good MIDI streaming even the fanciest GUI will not matter anything.
cheers,
Benno
Although I understand the logic of a fixed IP network, I have been using a DHCP "automatic" assignment routine. I have a studio in my home, but also a studio at my theatre. I just unplug machines from one network, pull the racks, and plug them into the other.
Although perhaps this is not a high priority, my idea of the most ideal tool would be one where the user simply invoked it, and every single aspect of the installation was "sniffed, searched, presented, and plugged," so to speak. Something so automatic and automated that a person who cannot decipher a VCR could do it (although I must admit that VCRs tend to confuse me more than complex computer applications).
None of this is to say that I don't consider this tool a generous and amazing piece of work. I am just presenting suggestions which are unfiltered "ideal world" ideas. I think the major problem with MIDI over LAN and other devices of this type is that they don't present a more abstracted "top layer" UI, which speaks the language of non-computer musicians. I think that obviously one needs the fine level and detail of control that only "network-speak" can deliver, but that this might not be the best top-level UI for musicians in general.
I would equate it to the difference in the "surface" UI of Reaktor, versus, the Structure View where everything is actually configured and routed. Under there, it looks very complex. On top, it looks very simple, and everything is happening automatically underneath.
I have some stuff to get through today, but when I have finished it, I will try to make time to draw up some ideas that would illustrate what I am talking about...that would probably make more sense than babbling on about it for paragraphs and paragraphs.
Best regards,
Bruce
gugliel
07-19-2005, 08:42 AM
Benno, sorry i don't know too much about how it works -- but on the command line, what you provide to the midi utilities is the NAME of the remote computer, not its ip address. And my local net uses dhcp, provided by my dsl router.
Bruce A. Richardson
07-19-2005, 11:23 AM
My point was, first one needs to build solid foundation walls in a house, then think about the ornaments. And the MIDI streaming routines are the foundation walls of the application.
Without good MIDI streaming even the fanciest GUI will not matter anything.
cheers,
Benno
Yes, absolutely so. I could not agree more. I will try to get to it in the next couple of days.
Thank you again for your gesture of service to the community. It is very generous to have spent your time in this way.
sbenno
07-20-2005, 05:56 AM
Guglielmo,
I remember that when I configured a Netgear DSL home router (which does DHCP for the local LAN too) when you enter the configuration web interface you see the attached machines and in case of Windows machines you see it's name too. I don't use Windows extensively so I sometimes miss those user friendly features :)
So could you please test my tool in your LAN and see if you can enter the names in the Address field ?
If this works then I will add it to the documentation.
Bruce, you are welcome :)
It was only a couple of days of work, thank the bad weather in during the weekend :)
It was a good programming exercise and I hope it will be of good use for many people.
Let me know here when you have your GUI proposal for the MIDI tool.
cheers,
Benno
howardv
07-20-2005, 10:51 AM
Hi, Benno. Just downloaded your package and it looks great. I have to commend your pd spirit. Look forward to release of the source. And EthernetAudio if you get the chance.
Howard
Ragtime (http://www.rtpress.com) Press (http://www.rtpress.com)
sbenno
07-21-2005, 06:18 AM
Thanks Howard. Did you only download it or did you test it too ? :) So far I haven't heard from anyone that said it works. Is it that complicated to make it run ? :)
The source will be released next week I think.
cheers,
Benno
http://www.linuxsampler.org
Hi, Benno. Just downloaded your package and it looks great. I have to commend your pd spirit. Look forward to release of the source. And EthernetAudio if you get the chance.
Howard
Anytempo
07-21-2005, 10:10 AM
Thanks Howard. Did you only download it or did you test it too ? :) So far I haven't heard from anyone that said it works. Is it that complicated to make it run ? :)
The source will be released next week I think.
cheers,
Benno
http://www.linuxsampler.org
http://www.marblesound.com/ is still not available. Waiting on that to test out your utility.
Thanks for sharing it.
sbenno
07-21-2005, 10:28 AM
I've mirrored a copy of the free Maple MIDI utility on my page at least until marblesound.com comes up again. I hope it's ok to Jeff.
go to (refresh the page if you have an old version in your browser's cache)
http://www.linuxsampler.org/ethernetmidi/
to find the local download link for the Maple virtual MIDI cable.
let me know how if works for you.
cheers,
Benno
http://www.marblesound.com/ is still not available. Waiting on that to test out your utility.
Thanks for sharing it.
Marcussen
07-23-2005, 12:19 PM
Hi Benno.. are you or anyone else further developing the app?
In which case hare are a few notes:
It would be lovely to have the program work under the hood, like MOL does.
It would also be nice if maple or similar was somehow integrated, like I think I recall bruce requested. Lastly it would be nice if it would support more than 16 ports :)
Just a few notes on what would make this thing rock
sbenno
07-23-2005, 12:40 PM
Hi Marcussen,
Of course the application will be developed further, it's only the beginning ... :)
So does the application work for you ? I'd like to hear what your experiences are with it ? (timing etc)
In what sense the program work under the hood ?
Regarding the 16 ports. The program does not have any kind of limitation. For now the only limitation is given by the number of virtual midi ports provided by Maple or MidiYoke etc. Did you mean this with "16 ports limitation" ? Maple is limited to 4 ports.
Regarding Maple. Yes we will look at this issue and try to provide an all in one product.
I noticed some usability problems reported by a user.
Assume you have maple installed.
It provides 4 midi outs and for midi in ports. If you send data to maple out 1 it will appear on maple in 1.
Since in EthernetMIDI when you press Start it opens both an input and an output MIDI port from the list. Since the user wanted only to forward data from that PC to another when he clicked start EthernetMIDI was using Maple Out 1 and Maple In 1. But then he wanted to user Maple In 1 in Logic (which is forwarded to Maple Out 1 and then to the LAN), it was already in use by EthernetMIDI thus Logic was not able to use it.
So if you want to send MIDI to LAN only in the MIDI Out port list in EthernetMIDI please select an unused MIDI port (eg Maple Out 2).
I will change the behaviour to allow send or receive only via a checkbox so that those kind of user errors can be avoided.
cheers,
Benno
Hi Benno.. are you or anyone else further developing the app?
In which case hare are a few notes:
It would be lovely to have the program work under the hood, like MOL does.
It would also be nice if maple or similar was somehow integrated, like I think I recall bruce requested. Lastly it would be nice if it would support more than 16 ports :)
Just a few notes on what would make this thing rock
Marcussen
07-23-2005, 12:51 PM
Hi.. good to hear its still under works. I did not have time to fiddle with it.. I opned it, tried out a few things but did not have time to fiddle enough with it to get it to work. Just realized the limitations, and how the program could be improved.
By under the hood I mean that after its installed you dont ever see it again, and dont have to do anything. Take MOL for instance. You install it, set it up and viola... its now part of cubase.
Regarding the ports, yes thats exactly what I meant. That maple is limited to 4 ports, and if you also install Yoke then you have in all 8 ports. But its still too few (MOL suppots 16 in teh standard version and 64 or something in the platinum version). Also its too much fiddeling installing and setting up various virtual midi cables from different companies. It would be great if it was interegrated into EM (EthernetMIDI).
Again keep up the good work - and as I have said earlier, its very generous of you to share this thing with the world :) So please dont think of my post as whining... just trying to give you some contructive feedback :)
sBenno, I haven't tried your new utility yet, but this is just wonderful. :)
I'll probably give it a whirl this weekend time allowing.
Has anyone tried using it yet with the VSL performance tool? Does it handle it properly?
gugliel
07-23-2005, 10:49 PM
Greetings, Benno --
Installed your new utility quite easily and it makes one connection per instance as advertised. I'm using maple midi on an environment with kontakt2 on one computer and gigastudio and sonar sharing a second computer.
Sonar is the sequencer, sending midi directly to gigastudio and using 2 ethernet midi ports and 2 hardware midi ports to k2. For full recording, I use a third computer running gigastudio with 2 hardware midi ports and 2 ethernet midi ports. Some observations:
Most important: it does not interact correctly with my sequencer, sonar: if ethernet midi is running and connected, then sonar makes the midi port in use unavailable. This does not happen with the midi utilities for windows. I can override that, but then the newly available port is in a different order in the sonar sequence file -- making all instrument assignments for the 16 midi channels on that port wrong for a given file.
On the otherhand, if I start sonar first, then ethernet midi gives message "failed to open midi out port". Also does not happen with the midi utilities.
Secondary, ease of use:
To start up my customary 4 ethernet ports using div's utilities, I made a script file. To get things started for daily work, I click to open a command window and type a three character command filename once on each computer -- four user interface ticks each computer, done extremely rapidly. To get four of yours running, I need to click the icon, type a 12-character ip address and type a port # four times on each computer. Even if I make a command file to run the program four times, I'll still need to type in the ip and port four times per computer. Since I do exactly the same thing every day, a configuration option or settable default would be VERY helpful. I'm not TOO lazy -- had to change the assignments for 171 midi tracks in my current project in order to test your work -- but hate repetitive waste of time!
Theodor
07-23-2005, 11:17 PM
Thanks for this! I don't have 2 pc's but its very generous of you.
sbenno
07-24-2005, 01:16 PM
Guglielmo thanks for your valuable feedback.
Your problem (cannot open MIDI port) is probably what I described in the posting above.
I expected this to become a problem so I will add checkboxes to allow receive only or transmit only (which is the most common setup, bidirectionaly MIDI between machines is not needed very often I think).
The next enhancements I plan are the following:
- checkboxes to select receive or transmit only
- get rid of the UDP port field and replace it with a MIDI port number, this makes it more user friendly and has the advantage that you can send to multiple MIDI ports over a single UDP network ports.
- allow receiving / transmitting MIDI from/to multiple machines without needing to fire up multiple instances of EthernetMIDI
I will implement this by using a tabbed widget where you can select how many instances you need, each own having it's own config window (remote address, midi port, which local MIDI port you want forward to, etc).
- load / save of settings with autoload of settings on startup.
This way in Guglielmo's case, it should be sufficient to configure the MIDI ports and hostnames / IP addresses once and then all you need to do is to fire up the application on each machine in order to start working.
This will allow for getting up and running quickly in larger setups and allow loading multiple templates in case you need it.
Marcussen: don't worry feedback is always welcome ! It's people like you and FV that motivated me to write this tool and I hope that with further enhancements all the whining will soon be gone :)
jc5: I don't have the VSL performance tool but I assume it creates or uses normal Windows MIDI ports so yes EthernetMIDI should work without problems with the VSL perforamance tool. If someone can try this out on their machines please let us know.
BTW I released the source code too (GNU GPL license) you can get on the EthernetMIDI page:
http://www.linuxsampler.org/ethernetmidi/
Developers interested to partecipate should send me an email.
cheers,
Benno
howardv
07-25-2005, 10:55 PM
Thanks Howard. Did you only download it or did you test it too ? :) Just back from a road trip but I'll give it a workout this coming weekend and report back.
Howard
gugliel
07-26-2005, 06:32 AM
Those sound like excellent enhancements. Had wondered about the bi-directional midi, since everything I do goes one direction only.
Will wait for your next update!
jbrave
08-26-2006, 05:52 PM
Hello Benno,
Did you ever get the copy of Apple's OS X midi over ethernet spec I sent you a few months ago? Let me know, and If I can find the document again, I'll send it to you if you don't have it.
Joel
Hi Benno,
I won't be able to try this tool out in its current form, but wanted to say thanks for this generous work. I have some thoughts about this technology that I wanted to put out here (maybe some suggestions & some rambling!)
As to the need to open tools in a specific order, it sounds like a midi driver is not multi-client. Single client drivers are a mysterious pain to work with. There are at least 2 different midi driver models you can program to, I believe they are WDM (windows driver model) and the older multimedia driver standard. Most drivers I see are multimedia drivers which in theory should have higher latency and looser timing though in my experience the driver model is not the sloppiest link in most midi chains.
It's easy to compare latency from a hardware midi interface to an ethernet stack - trigger an instantaneous impulse sample ('pop') on an external sampler with say 16th notes, and record the audio onto 2 different tracks. See how much the audio lags behind the beat for the 2 midi stacks. In my experience (old midiOverLan, multimedia driver) the ethernet trigger had less latency and substantially less variability (jitter). The hardware midi was good enough, but there was no question that the ethernet solution was tighter.
In my dream world (ha ha) these midi drivers should be client agnostic. The midi data stream is standardized. The network stack is standardized. Why should there by myriad application protocols to broker a proprietary hookup? It would be cool if EthernetMIDI could speak to midiOverLan and (macMidi, whatever the name is). If several protocols are already frozen, maybe you could pick a standard and allow the other protocols to be spoofed.
Once the kinks are ironed out of the protocol stack, it would be cool if the implementation were simplified to a standalong configurator plus just a driver that could be loaded at startup. It's a royal pain when a project consists of the sequencer files plus an external midi routing program plus an external network routing program, plus a similar setup on an external machine. Good luck reconstructing such a project in 6 months, particularly after anything else in the setup has been changed, which it will.
I won't run Maple here since this is the suspect tool that a developer here bragged of trojan'ing to spy on his users. Until these parties come clean on their violation I would not trust this tool.
Tobias Erichsen
08-27-2006, 07:33 AM
Hello Benno,
Did you ever get the copy of Apple's OS X midi over ethernet spec I sent you a few months ago? Let me know, and If I can find the document again, I'll send it to you if you don't have it.
Joel
Hi,
if you have this specification around, please let me know, as I'm
very interested in implementing it on the PC...
Best regards,
Tobias
seclusion
08-27-2006, 12:46 PM
Hey there
Has there been any development with OSX? I'd really like to get Logic Pro (Mac) to see my Gigastudio (PC) system over IP.
Thanks
Brian
Tobias Erichsen
08-28-2006, 04:33 AM
Hey there
Has there been any development with OSX? I'd really like to get Logic Pro (Mac) to see my Gigastudio (PC) system over IP.
Thanks
Brian
I have so far written a win32-only midi-driver that works pretty
nice, but I would really like to implement the OS-X way to do
this... but as I have no spec & no Mac there is not much I can
do about it currently...
Best regards,
Tobias
derekderek
10-16-2006, 01:57 PM
About the OSX thing...the more recent versions of OSX (not sure which) have some sort of lan midi driver built in, so it would be very nice to see Ethernet Midi talk to this. Especially as many people use Logic as sequencer to trigger Gigastudio/Kontakt on PCs.
cinemascore
11-17-2006, 09:49 PM
The next enhancements I plan are the following:
- checkboxes to select receive or transmit only
- get rid of the UDP port field and replace it with a MIDI port number, this makes it more user friendly and has the advantage that you can send to multiple MIDI ports over a single UDP network ports.
- allow receiving / transmitting MIDI from/to multiple machines without needing to fire up multiple instances of EthernetMIDI
I will implement this by using a tabbed widget where you can select how many instances you need, each own having it's own config window (remote address, midi port, which local MIDI port you want forward to, etc).
- load / save of settings with autoload of settings on startup.
Benno,
I know it has been a long while, but have you made any progress implementing new features since this post, specifically adding extra panes for simultaneous multiple port I/O and auto load and save for EthernetMIDI?
Thanks!
Hardy Heern
11-18-2006, 07:50 PM
Benno,
Although I'm not in a position to make use of this at the moment I can only thank you for your generosity in sharing such a piece of software with the community. There are a few good souls who do this and they are much admired and appreciated.
Thank you.
Frank
Steve_Karl
03-26-2007, 12:58 AM
Benno,
Thank you. Nice work.
I'm currently using MidiOverLan but finding that I'll soon be needing more than 16 ports.
If you can get this up to 32 ports you'll be the most powerful one on the planet and could make some money for you effort.
Please keep us informed!
belbin
03-28-2007, 11:09 PM
Not sure if I wrote in this thread when it started, and am too lazy to check right now, but I jsut wanted to say I used this not long after its release, and agree that it is a great tool. It was generous of you to share it.
Thanks, SBenno!
Belbin
vBulletin® v3.7.3, Copyright ©2000-2008, Jelsoft Enterprises Ltd.