I am having the same problem as @madsgranum and I feel the issue is with GP.
I’m using a Hapax MIDI sequencer and on it I’m sending a simple pattern of notes and I’m using two of its LFOs to send out CC data. If I increase the speed of the LFOs past a certain point GP starts to overload and MIDI messages start to stack up and become delayed. Even after I’ve stopped the sequencer, MID notes and CC’s continue to scroll in the Global MIDI monitor until it’s caught up.
I’m confident this is a GP issue for a number of reasons:
-I have GP’s Global MIDI Monitor visible and I’m running the MIDI Monitor app at the same time and I’m using the Hapax’s built-in MIDI monitor to view all the activity. When I stop the sequencer I can see the messages in the MIDI Monitor app and the Hapax stop immediately, but the messages in the Global MIDI in GP continues running for a few seconds (or longer) until it catches up. And if I change the buffer size in GP I will get better performance, but at some point it always becomes overloaded.
-To test this I had a VST instance of Reaktor in GP, a simple drum patch. Two of the parameters are mapped and controlled using GP’s mechanics (using Learn Parameter to assign a widget, then assigning a MIDI CC to control the widget). In this scenario I get the overload issue. But if I open the exact same patch in Reaktor standalone and set all of my audio interface parameters to match the ones I had in GP, then use Reaktor’s MIDI learn capabilities to assign the CC’s to parameters, I get perfect performance no matter how much MIDI data I throw at it.
Are there any settings in GP I can adjust to resolve this?
The GP MIDI monitor is only…well… a… monitor. It doesn’t display as quick as GP can handle MIDI messages. Beside the GP MIDI monitor display, could you notice any delayed MIDI message ?
Thanks for the quick replies @dhj@David-san, really appreciate it.
Nice one! This seems to be the issue.
GP is running native. If I try Reaktor or Massive, which are not native, I get the overload issues. But when I try Kontakt or Aalto, which are native, there are no issues and they run perfectly.
However, when I run either Reaktor or Massive in standalone mode and use the MIDI learn, I get no issues.
So, what’s the solution to being able to run both rosetta and native plugins in GP without overload issues? Should I be running GP in rosetta? I’ll experiment with that next.
Curious to see if I get these issues in any of my DAWs. I’ll report back.
The issue happens regardless of whether the Global MIDI Monitor is open or closed.
Well, I would say the Global MIDI Monitor is accurate to what I’m hearing actually. Here’s an example of what it sounds like: Let’s say I have a sequence of MIDI notes every 1/16th beat. Just a straight pulse of notes. If I start the sequence and have the MIDI LFOs from the sequencer turned off, everything sounds normal. If I turn on the LFOs, but have them at a slow rate, the 1/16th notes are consistent and I can hear/see the parameters moving at a slow pace. But if I start to ramp up the speed of the LFOs the 1/16th notes are no longer in time, they are dramatically slower and the GUI for the GP macro (and the plugin) are very slow. In fact, even if I stop the sequencer totally, GP will continue to send out the notes and the MIDI CC’s at the slow pace until it is caught up. If I’ve been running the sequencer long enough, this catching up process can take minutes until it’s caught up.
If you’d like, I can do a screen recording of it so you can see what I’m talking about.
Meh…sorry….all bets are off once you mix the two together….Rosetta is a remarkable achievement but mixing native and Rosetta doesn’t work well, IMO.
You could certainly try running everything in Rosetta. I know some users do that successfully but I don’t know how well it will work if you’re flooding the MIDI ports.
Personally, I’m still running an old Intel MacBook Pro and I’m not going to M1 for shows until every single plugin I need to use is available natively.
Quick report: If I run GP is Rosetta and flood the MIDI ports, GP is keeping up, with both rosetta plugins and native M1 plugins. Though this leads to a couple of questions:
If GP is running in rosetta and I open an M1 native plugin, is that plugin running natively or is it knocked to rosetta because GP is running in rosetta?
Theoretically, what kind of performance loss do I get if I’m running GP in Rosetta vs. native?
Fair enough. I really feel for developers, this whole moving to ARM has really complicated things, it’s going to be a messy landscape until all the developers have transitioned. Alas.
However, I would be remiss if I didn’t mention that I ran the above tests in both Ableton 11.2 and Reaper 6.68, both running in native, and both could handle flooded MIDI ports without choking when using combinations of both rosetta and native plugins. So, it’s not impossible.
That said, running those tests made me appreciate how elegant the GP system is, loading VSTs, assign macros to parameters, then CC’s to macros was so much clunkier in those two DAWs compared to GP. It’s so fluid and quick in GP. Kudos!
So, for the time being I’ll just have to pay a little more attention to rosetta/M1 until everyone is caught up. I’m pretty committed to making GP work for me, really enjoying the software.
