The catalyst for this is that recently some users have been seeking all sorts of creative audio/midi routing workarounds and this taps into a larger area that we already had been working on years ago.
With 3.0.53 BETA we introduce the first peek into running MIDI GUITAR over networks. This simply comprise two new MG modules: One for sending and one for receiving information/audio/midi.
Since MIDI GUITAR is so focused on latency, our networking solution is too. It will give the lowest possible latency over whatever infrastructure is used (lan, wifi, wan/internet). It’s also easier to configure and does not mess with the drivers on your systems.
At the moment its limited to a single machine, and we are just testing the waters to see what users will make of it, but some of the use cases for now:
Sending MIDI from MG3 Standalone to a MG3 plugin in a DAW or application, with guaranteed MPE and without installing any midi loop drivers.
Using MGHEX with 6 channel inputs in a DAW that doesn’t support such flexible cabling.
Sending MIDI from one track to another in a host that doesn’t support this.
Offloading MIDI GUITAR tracking to a server, for doing other intensive tasks, such as screen casting.
Later, we may enable it to communicate among different machines to enable:
Jam sessions among more people over local WIFI.
Offloading MIDI GUITAR tracking to a server, while using a smaller/handheld computer.
Use Mac or PC plugins from iOS.
Online jamming (as every other online jamming solution, latency and the speed of light will make it unfeasible for most)
How to enable this:
In MG 3.0.53 and later: Preferences => Plugins, Make sure it says “Enable Networking” (wording here is wrong and confusing). Restart MG3.
On the sending side, you have your audio interface and the MG3 application. Add the MIDI CASTER module from the TOOLS category, anywhere in a chain. No other modules are needed on this side.
On the receiving side (say a MG3 plugin in a DAW), select MIDI GUITAR NETWORK as a tracker (Preferences => Select tracker). This instance now runs without any audio interface.
JamKazam (https://jamkazam.com/) has been working on low latency audio and video jamming for 6 years. It will be interesting to see what you come up with. Good luck!
FWIW, I noticed that a quite heavy MG3 preset with three chains running (Nolly X, Diva and Animoog Z) works fine in standalone at 128 samples (or 64) but loading the same preset in a DAW with the MG3 network MIDI CASTER tips the CPU scales. As the audio isn’t present I could kill Nolly X and it helped but I still got the odd crackle. Though, to be fair to MG3, I think I was running Live 12 at 64 samples.
In my prototypes here it felt a little bit like having all the VSTs and terabytes of sample libraries right on an iPad.
The UI framework of MG3 (like it or not) was made from the ground to be a client/server thing. This is not so much like the iOS/Android audio “control/bluetooth/player apps”, where only commands are sent to change a patch or a knob, but more like a remote desktop, where the server actually draws the MG UI to be shown on the client iPad, at every frame.
But I’m unsure how much we want to go into this. Support for all the edge cases and making a polished solution would take too much of my time as the situation is now.
I’ve tried all the options: standalone only, standalone with loopmidi and Ableton, standalone with caster and receiver (I found the caster-receiver to have higher latency than loopmidi) in Ableton, and standalone with Ableton.
I have settled on standalone with Ableton. I use the standalone for hex audio and mpe synths and feed this audio output of the GM-800 audio interface to my firewire interface that I use with Ableton (5ms RTL). So many ways to configure, but this works best for me.
I’m comparing midi to a track sent from the caster in standalone and received by the plugin and sent out to a track. Significantly higher latency than loopmidi in this use case. On windows.
Ah, yes I see now. It makes sense if we are just interested in getting MIDI into the piano roll or a new track!
In the case of using virtual midi, the midi is all prepared and the DAW can just read it.
In the case of this networking, the transport is actually fast, but its only arriving as notes in the MG VST plugin, which has to first process a buffer and then output midi, before the DAW can read this midi (plus maybe any scheduling or routing overhead in the DAW).
So this is really not so useful if all you want is the MIDI, rather than the full MG VST processing, in the DAW,
I find that casting to the MG3 plugin and playing the synth inside the MG3 plugin stresses the cpu more–I get crackles. So for now, I’m going with standalone and output from GM-800 interface to the interface I use with my DAW. If I had a M2 Mac Studio this might not happen, but all I have is a lowly 3.7 Ghz Ryzen 2700x Octacore.
i believe that in a mg3net setup, the string filter works only when placed before the caster. if i put in on the receiver it passes notes thru from blocked strings.
it would be handy to have it in the receiver, as that is where i spend most of my time. also i will have multiple patches on the receiver end, but just one setup for the caster.
