FriFlo

I am trying to send midi data (converted into my own protocol) via ethernet from one PC to another. The reason is, it is way more flexible with max this way and I would need huge numbers of midi ports that no virtual midi program handles (the limit is usually 64 ports). Also, I noticed, Cubase does not start with more than about 70 midi ports. For what I am up to, that is not enough, I am afraid.

Now, my question is, are there any new features in max 7 (or older features I didn't find yet)? In Max 6 the only way was TCP/IP send, which creates some problems: timing was not accurate, there is more latency than with midi over lan programs (I did a comparison a year ago) and the absolute no-go for midi: package loss! If not every information is sent reliably, it really makes no sense in a studio environment!

Is there any other way, possibly with new max 7 features, which did not buy, yet, to do this in the same reliable, accurate and low-latency way as it works with ipMidi, rtp midi or midi-over-lan?

I am trying to send midi data (converted into my own protocol) via ethernet from one PC to another. The reason is, it is way more flexible with max this way and I would need huge numbers of midi ports that no virtual midi program handles (the limit is usually 64 ports). Also, I noticed, Cubase does not start with more than about 70 midi ports. For what I am up to, that is not enough, I am afraid.
Now, my question is, are there any new features in max 7 (or older features I didn't find yet)? In Max 6 the only way was TCP/IP send, which creates some problems: timing was not accurate, there is more latency than with midi over lan programs (I did a comparison a year ago) and the absolute no-go for midi: package loss! If not every information is sent reliably, it really makes no sense in a studio environment!
Is there any other way, possibly with new max 7 features, which did not buy, yet, to do this in the same reliable, accurate and low-latency way as it works with ipMidi, rtp midi or midi-over-lan?


send-data-from-max-to-max-on-another-computer

We send timing critical data over ethernet all the time, at very high rates. We aren't suffering from package loss at all, and the latency is low enough to do stuff like fake side-chaining, by sending midi notes to trigger an envelope on a different machine.

Would you mind me asking why you're sending that much midi? It seems like you might be better off with something packed completely differently, that didn't require that many sequentially fired bits of data?

I'm not questioning your methodology, merely interested in hearing more about it. Maybe through that examination I could help you more?

We send timing critical data over ethernet all the time, at very high rates. We aren't suffering from package loss at all, and the latency is low enough to do stuff like fake side-chaining, by sending midi notes to trigger an envelope on a different machine. 

I'm not questioning your methodology, merely interested in hearing more about it. Maybe through that examination I could help you more?


Thanks for chiming in! I'll gladly tell you, why there are so many midi ports necessary. My plan is to build a film composer template-control software. The main instance running on the main DAW, receiving all hardware midi and controlling several sub-instances of max on each slave computer, stuffed with kontact sample libraries and other VST instruments. I plan to do that with max, as I could custom program every kind of behaviors, like loading Kontakt and presets, handling Midi data the way I want it, etc. But the problem is, that I want to take this midi routing:

Main-Max-Patch > Cubase (via 64 vitual Midi ports)

Cubase > Main-Max-Patch (via 64 vitual Midi ports)

Main-Max-Patch > slaves (via network - own protocol, that can easily be converted to midi)

With a program like midi-over-lan I have 64 In/Out ports - not enough to even do that, so I will already have to get the number of midi ports down to 32.

Why do I need as many Midi ports to send from max to cubase? Simply, because I want to record enable multiple channels on different ports and - inside max - exactly define which midi information goes to which track. Only possible with as many dedicated in-ports as there are out-ports in the template.

From then on, I would like to be able to quickly assign, to which instrument an some slave each port/channel goes. I hope it is clear, what I am after! ;-)

Going from/to Cubase has to be virtual midi ports, but going from max to max on another computer can really be any kind of protocol, kind of like OSC, where I just route to slaveX/LibraryX/InstumentX/articulationX. This way, it is way more flexible to handle and I don't have to spend any more virtual midi ports.

You could think, why not assign the virtual midi ports (over lan) directly to the slave. Yes, but this way I am limited to 32x16 Instrument/articulation combos. With my idea, the number of those is really without limits and easier to handle.

But the problem is, there is a lot of data transmitted, with a dense orchestration and any missing bit could be critical (like a midi not on or off). It has to be 100% reliable and 100% timing-accurate.

Actually, there is one more thing to discover, before I will take on that huge endeavour and that is how well max 7 handles great numbers of different VSTs loaded with lots of routing and changing midi data! How efficient is it CPU- and latency-wise.

It would be a really huge task, to program such a thing, so I am kind of reluctant to start without lots of investigation, how stable an well it can work.

Thanks for chiming in! I'll gladly tell you, why there are so many midi ports necessary. My plan is to build a film composer template-control software. The main instance running on the main DAW, receiving all hardware midi and controlling several sub-instances of max on each slave computer, stuffed with kontact sample libraries and other VST instruments. I plan to do that with max, as I could custom program every kind of behaviors, like loading Kontakt and presets, handling Midi data the way I want it, etc. But the problem is, that I want to take this midi routing:
HW Midi > Main-Max-Patch
Main-Max-Patch > Cubase (via 64 vitual Midi ports)
Cubase > Main-Max-Patch (via 64 vitual Midi ports)
Main-Max-Patch > slaves (via network - own protocol, that can easily be converted to midi)

With a program like midi-over-lan I have 64 In/Out ports - not enough to even do that, so I will already have to get the number of midi ports down to 32.
Why do I need as many Midi ports to send from max to cubase? Simply, because I want to record enable multiple channels on different ports and - inside max - exactly define which midi information goes to which track. Only possible with as many dedicated in-ports as there are out-ports in the template.
From then on, I would like to be able to quickly assign, to which instrument an some slave each port/channel goes. I hope it is clear, what I am after! ;-)
Going from/to Cubase has to be virtual midi ports, but going from max to max on another computer can really be any kind of protocol, kind of like OSC, where I just route to slaveX/LibraryX/InstumentX/articulationX. This way, it is way more flexible to handle and I don't have to spend any more virtual midi ports.
You could think, why not assign the virtual midi ports (over lan) directly to the slave. Yes, but this way I am limited to 32x16 Instrument/articulation combos. With my idea, the number of those is really without limits and easier to handle.
But the problem is, there is a lot of data transmitted, with a dense orchestration and any missing bit could be critical (like a midi not on or off). It has to be 100% reliable and 100% timing-accurate.
Actually, there is one more thing to discover, before I will take on that huge endeavour and that is how well max 7 handles great numbers of different VSTs loaded with lots of routing and changing midi data! How efficient is it CPU- and latency-wise.
It would be a really huge task, to program such a thing, so I am kind of reluctant to start without lots of investigation, how stable an well it can work.
Hope, this makes sense!


Send data from max to max on another computer