Yes, but the exact link of the right product is:
2 Likes
you mean, NOT using it at all within any rackspace that uses a IAC midi port ?
for all midi connections, allways use the "port specifiic* midi In and out plugins from GP4 ?
do i understand you the right way ?
Correct — it should be understand that the MIDI (Omni) In is really intended just to help beginners get started — once people learn how GP works, they should replace MIDI (OMNI) In plugins with device specific MIDI In blocks (and eventually via the rig manager)
1 Like
Or LoopBe1, also free.
They also offer LoopBe30 (16,90 €; $19.90) if you need more MIDI ports. It’s what I use.
Yes but LoopBe1, as the name indicates, is free for only one channel, while you have many channels with loopMIDI.
2 Likes
I mentioned it only because I had latency issues with loopMIDI once, but others have not, so my problem may have been something else.
Still the case? Because I did a one-to-one comparison using the GP MIDI monitor displayed timings and couldn’t find any difference. 
a important piece of information ! Thank you !
you should add such “sidecomments” to the manual.
( but maybe i missed the passage…)
Yes! You missed it.
" Note: if you are using a virtual MIDI Port (such as the built-in IAC port in Mac), then you must not use OMNI blocks as you will get feedback (click here to learn more)."
Link: MIDI Inputs
2 Likes
ahhh, indeed ! …well, i did not remember 
since now i know where i stumbled the first time over the IAC term
indeed, very simple to just activate it ( beeing on a mac)
Thanks for point that one out !
Hey, there are many blog articles that mention IAC or other virtual MIDI ports. See here, for example: Gig Performer | How to synchronize Gig Performer's tempo to an external MIDI clock or Link-enabled products
Check out other articles on the GP blog 
- Gig Performer | Welcome to our blog
Also, share if you find something useful 
2 Likes
What I tried to say was that I “had” a problem once and switched to LoopBe. That problem may not have been (and, in retrospect, likely wasn’t) with loopMIDI. But once I purchased a license for LoopBe30, I’ve just kept using it. Never went back and retried loopMIDI.
1 Like
To follow up I did try LoopBe1 and it did work quite well. Had to assign each’s output to its own MIDI channel using GP MIDI (remap / constrain plugin? - long day) so GP to the rescue again. Works great! Thanks for the suggestion @dhj
2 Likes
Re sending MIDI to the Global rackspace, do you know how using OSC affects latency, compared to routing the MIDI to a plugin in the local rackspace? And what about using macOS’s IAC Driver instead of OSC, would that be better or worse?
I didn’t test latency, but you are an ideal person to test this
You use a tight setup and you wrote this:
Therefore, I believe that you might get us an answer
2 Likes
I think there is not measurable latency when you send OSC messages locally.
1 Like
I did a test and when there would be latency you should hear it
MidiOSCGlobal.gig (27.3 KB)
The receiving port used is 1235
Tested it and this solution is “clean”: be careful DON’T use Global Midi (Omni) as input to avoid Midi Loop 
@pianopaul this solution is smarter than OSC implementation or could create undesired effects?
I plan to use this blog again to add something the Global Rackspace using OSC.
The blog does not address the changes you have to make if you are using two midi in blocks. You might want to add the following (David’s response to my question why I could not get this working with a second midi in clock):
You can’t use the same OSC address for two blocks.
If you used MidiFromLocal for one MIDI In block then you need to use a different handle for a second MIDI In block and you need to use a different OSC address in the second MIDI Out block
E,g
For the second MIDI In block handle: MidiFromLocal2
For the second MIDI Out OSC address: /MidiFromLocal2/Midi
The full discussion is here: About to Move Ram Intensive Plug-ins to Global Rackspace