Alternative for Apple IAC Midi busses?
I have been using those a long time, but I keep reading they are an old relic from OS9 and not reliable, although I have so far not noticed it, except for a slight latency ... could you specify, what exactly the problem is with the IAC busses?
And more importantly: what would be an alternative virtual midi port? I need plenty, so it would be great, if there was not limit of how many can be created. They also must be permanent, so, I do not want them to be created by max, as those would cease to exist with max closed. Further, being able to name them would be great.
I am on Mac OS for now, but depending on this years Mac Pro news I might switch to PC next year, hence, Windows 10 hints would be welcome, but for now, it must be Apple. Thanks!
Music Lab MIDI Over Lan is a paid app that allows users to create lots of MIDI ports that can be bussed internally (loopback) or out via Ethernet.
It is updated regularly with good customer support.
On macOS MIDI Over LAN MIDI ports can be named; Windows versions of MIDI over LAN do not allow port naming.
However, if you are not experiencing issues with MIDI via the IAC bus and do not require MIDI via Ethernet I do not recommend abandoning the IAC bus.
I agree that there are a lot of forum postings about timing, jitter, and other issues with the IAC Bus. There is also anthropology about how the IAC bus is not/has never been as robust as needed.
Given all that I have personally tested many MIDI functions, including very elaborate stress tests, and do not see any difference between the IAC bus and any other way of getting MIDI around a Mac OS machine. This testing has been about various DAW integrations, including integrations with MaxMSP, and networking machines via LAN. Accurate MTC/MIDI realtime messages have been a focus. The tests have not been about live performance.
I have also posted in various places requesting a specific reproducible example of the IAC bus being less reliable than any other MIDI bus, with no response. Out of curiosity, what is the "slight latency" you experience?
As far as I can tell, in high-volume MIDI environments DAW systems all respond differently when synchronizing/organizing MIDI output. Audio buffer size, number of MIDI events/tracks, whether a system is applying plugin delay compensation, any track or region based MIDI delays, and a number of other factors have a much larger impact on timing than the MIDI port itself.
I'm using the IAC bus since many years without any problems and latency less than 1ms. Probably some people have issues with the IAC bus just because it's bidirectional. So you must be careful to avoid infinite feedback loops, in particular with Apps like Logic receiving MIDI by default on all ports.
Thanks guys!
@1 off by: Maybe latency was the wrong word ... I experienced the iPad with Lemur reacting much quicker with a lot of data being streamed, when connected via the recently acquired iConnectMidi Interface and the Mac via USB, compared to the IAC bus routed to an iPad virtual midi software. But you are right, this could be more related to that software ...
So, IAC bus is still good to use, I guess? I will eventually probably move my whole template from VEpro network to hosting in standalone on each slave-PC, getting the audio to the main machine via Madi stream. Then, I would need a lot of mid tracks being routed! With the slaves, the number of midi channels being provided by MidiOverLan would be enough, but since I need additional routing options to Max, I could use a lot of additional virtual ports on the main machine. Would IAC still be reliable with such dense streams of mid data on 64 or more ports?
By the way: I found a new thing for virtual midi cables! Check this out:
https://www.bome.com/products/bomenet
I am actually just hoping for one software that will allow me to create unlimited namable virtual midi ports with network and loopback option. Only the "unlimited" part seems to be the missing thing ATM. Maybe the Bone thing will be able to do that ...
Friflo; I have never used the iConnect, so can't comment.
RE VEPro to satellite machines:
I have had good results using the VEPro MIDI out over Ethernet and audio back over ethernet setup that VEPro supports. Except with Logic Pro X, which has a bad habit of putting all processing onto a single core when live MIDI input and dense MIDI playback are mixed.
Also, in my tests MIDI throughput (MIDI device>DAW>satellite machine) is much faster using VEPro than any other method.
Caveat: using VEPro for MIDI and audio I/O prevents any intermediary MIDI processing between DAW and satellite machine (for example Max or the useful TransMIDIFier). One solution: put all MIDI processing like Max before the DAW input. Then send MIDI from Max through something like a custom named IAC Bus ("MIDI From Max") into the DAW.
Yes, I do it similarly. I process the hardware midi in max and send it to Cubase via IAC, as you suggested. But in Cubase, other than the connection to VEpro, each midi track has a midi send, directed to another IAC bus, I call "Return". I have just programmed a generic remote for a 2000-miditrack template to let max know, which track is selected. And max tells Cubase, which tracks midi Sends to enable. This way I get full feedback of CCs for max to send to my tablet running lemur. It's really great to look at you tablet and know these are the actual values at that position in your song.
The only problem is: Cubase doesn't recall midi send settings with track presets, so I can't disable the midi tracks! I can hide them, but I hope I won't get any Asio/realtime spike with 2000 activated midi tracks in the session ... it shouldn't be problematic, as long as they are not all connected to VEpro, I hope!