Today Apple released their first ARM-based Mac processor. Since I am in the process of renewing my MackBook Pro I wonder how the new M1 processor behaves and performs when running Gig Performer.
Any thoughts or information?
Yeah, we have already tested the current version of GP and it works remarkably well, kudos to Apple.
We have also tested a version of Gig Performer compiled specifically for ARM and it also works fine. Unfortunately at this time I cannot provide a release date for that version.
3 Likes
Thanks @dhj! That’s great news!
RME also seem to have a beta driver for the ARM-based Mac available.
Great news that GP is already well performing on M1.
Can we expect that the future native M1 version from GP is also usable with an iPAD? One universal app for all?
This new develpment has thrown my plans of a new macbook pro, in flux. I was disappointed to see that the new 13" pro, maxes out at 16 gig RAM. Any thoughts on whether or not this even matters, given the speed of the new chip? Worth mentioning; i was running gigperformer pretty comfortably with a late 2011 pro with 16 G RAM and a 4 core 17.
RAM and CPU are 2 different things.
When you do not use huge sample libraries then RAM is not that important.
When you use plugins like DIVA or the new Softube MiniMoog then CPU is important.
When you use for example B-5V2 with UVI then RAM could be important because this plugin does not stream samples from disk.
So in short: the more RAM and the more CPU, the better 
My guess is that Apple will increase CPU cores, RAM and GPU performance in upcoming M-series processors. The M1 seem to focus more on the mass products like MacBook Air. Processors made for the more power demanding products and applications (iMac Pro, MacPro…) will likely follow.
However, I am impressed with the performance so far and think that it will be more than enough for most Gig Performer applications and live settings. At least for me.
Thanks pianopaul. My previous machine was a late 2011 MBP with 16 gig Ram and a SSD. I ran things pretty comfortably at a 128 buffer. The only compromise I needed to make was to disable Amplitube which I was using with my rhodes and wurli libraries. I found that Amplitube added just enough extra latency than I was comfortable with.
question, (suits perfectly here )
what benchmarks are the more relevant ones to judge on the M1 performance versus my old macs, -----> specifically versus using GP3 + VST FX, ----> versus running on small(-er) buffer sizes.
( The pointer here lies on FX!, …not using instruments / creating kind of a hardware FX box)
whats your tip, to which benchmark types to look at ?
is there even any of the (SC) benchmarks that is doing justice to this specific music usecase ?
i have a M1 macmini now, and bevore was it a macmini 2012, i7, 2,66Ghz, , both with 8MB RAm.
The power increase with the nw M1 is not as much as i hoped !
but its enough to lift me into a conftable territory.
still, i have to play my actual patch with a buffer of 512samples.
( working on it to overcome my interconnection problems with blackhole so that i can patch from one GP instance to another)
what i can say is, well it was just a initial feel,
that the relations between buffer settings, cPU load, and the real latency is a different one on my M1 vs. my old macmini.
The win in latency going from 512samples buffer down to 128 was not as much as expected,
while the cPU increase was not as high as expected.
problems i had so far is with the midi CC mapping.
i mainly just imported one Gig file form my old computer into GP* on the new one so far,
and i had to “remap” my GW midi controller !
all settings were still there, all mappings, but the hardware faders were not recognised.
…i just had to assign the faders new, …the specific “value” settings and the specific mappings were kept in place.
i´m still working on that same "instrument2 ( Gig)
so i´ve not tryed out how this will be with the next of my old gig files,
and if i have to do the same reassign work for every gig.
also not shure how much my chnaged USB hub setup could play a role here.
the M1 mac is getting NOTHING Hot, a slight bit warm at worst.
What i read has the macbook air M1 a bit less power assoon you would frive it hot ( or warm?).
i can´t say if its possible to reach that state by just using GP3.
i run for now on only one GP3 instance, thus only on one core,
but i have allways firefox with many tabs opne in parallel.
my CPU load in my patch is between 79-84% assoon i play.
it will be interesting to see if my M1 mac gets warm when i use 4 instances of GP3.
i´ll begin to do that, assoon i can overcome the interconnection problems.
i have had two crashes, but that was when i did ALOTS of audio interface and buffer settings switching.
also have i had a macOS update which chnged allready some strange behave with the mac keyboard.
the crashes were both bevore that update.
i´ve not had any crash while doing music
Remember that if you’re running applications intended for Intel (and the currently released GP3 is compiled for Intel), then on an ARM machine, there’s going to be an intermediate layer that is translating Intel instructions to ARM and that will have an impact.
Having tried it myself, I have to admit though that Apple did a rather amazing job getting Intel apps to run on ARM.
Yup, what i read in reviews is that the intel-based code is rather running fine on Rosetta.
How much faster a converted code will run has to be seen.
I don´t expect too much win.
my main remaining question mark in my brain is:
how much more singlecore power could a top intel cPU give me ?
according to given benchmarks, iirc, just very little.
and thats the other question mark in my brain:
how much do these benchmarks tell us versus the specific usecase of working with GP3 and loading (hungry) VSTs into it ?
-----> since a main aim here with GP3 IS "realtime use*
my personal “guess” is,
that the M1 architecture is working towards small latencys,
and that the old architecture (14nm intels) does not !
and that the performance difference between a small M1mac and a fat intel CPU would increase when we deal with bigger latencys, and decrease while going for smaller latencys.
Just a guess, but i think a “justified” one 
.
Right now is it NOT realistic for me and my “patches”/Rackspaces to get it down under 512 samples of buffer setting,
also not with my M1mac, ----> aslong i keep running my patches on just one GP3 instance.
While i had to run the same patch on 1224 samples buffer on the old macmini2012, and maybe had to take the last 2-3 FX out that i just added to that patch ( for even more fun, hehe)
While it gave not much win to go up to 2048 samples buffer with GP3 on my macmini2012 and anyway not on the M1 chip.
( i did go up to 2048buffer when i was on Ableton live9 as my Host, same macmini 2012)
so, my verdict with my M1 mac so far:
when i would begin to spilt of my rackspaces into: instruments, creating the primary sound" = 1 GP instance,
then the FX patch behind would become = the second GP3 instance,
then things will begin to work for me, working with macminis, and a dream will become even more true than allready is.
And since i should be able to bring then the buffers down, “could” this also change the balance vs. how much win a fat intel CPU could give vs. the small and affordable initial M1 chip does.
…just some thoughts.
But i think interesting ones, and in relation to real live ( at least for me who “can” live with dealing with buffers of 512 samples, can “take it” to deal with buffers of 1024 samples, BUT: would like to bring things down to buffers of 128 samples)
i can give here some numbers, vs. my patches/rackspaces: (running on a M1macmini, 8MB)
i run right now 3x GP3 instances for a check:
_the first one is my complete patch/rackspace.
it consists of both: the VST instruments, and the VST-FX behind it.
I was running it with a buffer setting of 512 samples and could bring it to make drop outs, going to 99%CPU power, by playing many notes. watching a bit what i do could i play it with a buffer of 512 samples.
i went right now down to 704samples, which should do.
( but i still have the same amount of dropouts, much likely cause i opened 2 more GP instances for this check ( and for the debugging process of the audio interconnections)
_now, the same Instrument patch as one GP instance alone, can run with 128 samples buffer setting,
and will go up to only 80% CPU power.
the patch is: 4x Instruments = 2x Pianoteq ( quite cPU friendly) and 2x Chromaphone3 ( quite cPU heavy)
plus also 5 GP internal modules ( mixers and gain controls) for the interconnection.
_ while the FX part of that patch, ( now the second GP3 instance) which is my delicate part that i´d like to expand, is also running with 128 samples buffer, but is just going up to a CPU load of 50%.
it uses 12x VST FX, and also 5 GP internal modules ( mixers, gaincontrols)
means, if this all would work with the internal audio connection (still have problems to make it work), would i had some Air to add another 6 or so FX to that whole patch,
thats probably exactly where i´d like to go up to, to finally finalize this patch.
so yes, this cheap little M1 macmini should be good for BIG things.
the patches i do won´t be possible to do with any piece of hardware btw.
since a main main main point here is the possible audio routing and controlling it by hand while playing.
And there is no FX hardware available as capable as todays VST FX ( at least not for where my aims are)
btw. i indeed patch ALOTS of crossfaders into my patches.
its a important ingredient for modern electronic music making, IMHO.
it would be nice to have a crossfader as a slim “in-one” module (GP internal function block)
.
Thanks for sharing your experience. Really interesting.
TBH, after such a drastic change in the underlying CPU architecture (Apples swich to ARM-based CPU) and using a real-time emulation software (Rosetta 2) to run software made for Intel CPU’s I expected more challanges in the beginning.
I’ve looked around and haven’t seen this referenced. My bkgd: I’m a player … and that’s all. In the worst sense of the term. I don’t get how playing samples works, I just play them; how much power/RAM it takes is beyond me. Looking to get M1 Air but does lack of fan matter? The video guys talk about needing a fan for sustained work. So, in an hour set playing Omnisphere, Keyscape, Triton app, one or two NI instruments (sometimes), some layering but not a ton - is that a sustained load? I will definitely spec 16GB RAM because … well, that’s what we’ve always done. And future proofing. Any thoughts?
all videos i saw on YT were vs. video and rendering.
Make the question to yourself: how many instances of GP3 do yo run at a time ?
edit: i stand corrected on this one sentence ! **:
** one Instance of GP is taking ONE Core, but not more ! thats afaik a fact.
/ …see the corrections in belows post from @djogon
Video rendering is eating cores, RAM and SSD power.
so, the whole System is there heavily under load at the same time !
(i´m not doing such, so, not my territory)
i have also a M1Air, you much likely won´t make it throtteling when using 1-2 or even more GP3 instances. What has an influence vs. warmth is, if i have to use the PSU, or if its only running on battery.
i took the M1Air in belive that it will have the same power for GP3 as my M1mini has.
Even if i would run two GP3 instances under heavy/max load.
I´ve not had my M1Air so far under stronger load (even not within the one GP instance i run. 30-40% CPU or so).
Can´t comment vs. harder real live uses, just vs. the whole logic behind it 
1 Like
This is only partially true. Many plugins will use multiple cores when “rendering” audio and some have explicit options to control this.
1 Like
Yes for example Kontakt
2 Likes
unfortunately this is only true for SOME plugins.
It would be great to get a GigPerformer for M1 with an enhanced Multi GP set-up: Define one Main Rackspace with Sub rackspaces like Browser Tabs - each assigned to a core to distribute load.
Oops, your suggestion would lead to a total new/different design.
Rackspaces do not work in parallel, only 1 can be active at a time.