2015 macbook pro 15" / OS10.15.7 / GP4 / ABLETON LIVE 11 / BLACKHOLE (most recent)
for my work flow it is vital to be able to record my GP-processed instrument directly into ableton live. as recommended elsewhere, i use the black hole audio virtual sound card (both 2 & 16 channel), which is such a useful concept. however, i am experiencing nasty dropouts even when CPU loads are low in both GP and ableton live!
i also have read this thread, suggesting that the use of blackhole is increasing CPU-usage non-proportionally:
but as mentioned, i even experience dropouts at low CPU levels, and especially when working with drones and feedback, you can spend the rest of the day trying to cut them out.
am i missing something? any special settings known to resolve this? are there any proven alternatives for blackhole? or other work-arounds for my task (record GP into ableton)?
(i also see on the blackhole makerās, existential audioās site a support section for logic & garage band - is this simply not approved to work with ableton?!)
I could reproduce with buffer size 64 samples and 44.1 kHz.
Then I changed to 128 Samples, I could reproduce.
Then I changed to samplerate 48 kHz (in Gig Performer and Ableton Live).
No sound could be heard.
I switched back to 44.1 kHz (in Gig Performer and Ableton Live) => no more issues.
it depends on the cpu load. if i get dropouts, i increase the buffer size. now before i posted here, i set myself to stay somewhat in the one-digit-cpu load - meaning under 10% in both ableton & GP4. stillā¦
i always turn off wifi and close most apps including anything sound like iTunes (but usually not all of them). but sure, maybe this is worth another go, trying to close ALL apps (like notes or acrobat reader)ā¦
What do you have in āAudio MIDI Setupā? Are you using an aggregate device, and do you have your interface set to be the master for clock, and drift correction enabled?
thanks for your answers and patience everyone - FYI: as far as i see the cpu monitors, the drop outs occur on ableton live 11ās and not on GPs side.
it turns out there was an app open in the background and the hick-ups have disappeared since i double checked nothing else is running in parallel - sorry for the false alarm, and as always thanks for the prompt and committed replies.
one question though: i could not really tell any difference in regards to how the settings in the audio/midi devices and the system prefs / audio affect the loopback - not at all? or are there any preferable settings?
ok in short i have NOT been able to get rid of audio drop outs trying to record from GP4 to ableton.
i have considered several possible sources for this problem, or, tried various alternative constellations to circle out the issue - to no avail:
computer / OS / software version constellation: in the meantime, my computer broke down and was replaced with a macbook M2 (ventura). everything has been updated. same problem.
BlackHole Audio is not the only virtual audio routing solution, i have installed and run rogue amoeba loopback. same problem.
ableton monitoring being a possible source of dropouts, i switched it off in ableton and monitored my bass playing via loopback only. same problem.
as i happened to play in GP4 through an instance of NI Guitar Rig 6, i switched off GP4, loaded my patch into GR6 stand-alone and routed it to record in ableton - no clicks or dropouts.
ultimately, this leads me to think that GP4 is the problem here.
is anyone routing their live-playing in GP4 to record into ableton live 11 via virtual audio (without workarounds such as running multiple instances etc.), but simply as successfully done with other audio softwares, such as Guitar Rig 6 in the above example?
yes (actually went through quite a process to get everything running on apple silicon). in this case, itās guitar rig 6 vst3 only. everything is set to 48khz in the apps as well as in the audio / midi settingsā¦
(i suppose if i set the buffer size so high that live recording playing makes no more sense it could work but have not tried that yet)
i think another āparameterā within all this is:
where is the audio stream finally routed to the Audio interface ? in which app ?
i personally try to avoid to setup up any Audio app, GP or DAW,
to a different IN vs. Out device. Speaking here anything, GP instances or DAW, which is ācreatingā sound.
The switch, going from blackhole (PC intern) over to my Audio interface, happens in a own GP instance.
allways ! This has helped me to deal with more consistent Latency numbers (vs. different setups / different settings). And i would say i deal with way less audio crackles overall.
Or the other way around: i use a own GP instance, just there for Audio routing purposes.
Audio-In is allways on all Audio apps: āBlakcholeā. (leaving here out the situation if i want to send external audio to the PC)
Audio-out is on All my audio apps: Blackhole ( different chanells / carefully selected / distributed between all the possible apps). With Racks in this GP instance, also containing mixing for all chanells at once.
only that one GP instance that is doing quasi nothing else, other than audio mixing and routing, is supposed to send audio out to my AI ! This GP instance is set to āautostartā. it loads when my PC is powered on. Its allways open.
Mac, M2pro Mini, 16GB RAM / Ventura 13.2.1 iirc
this works for me under any circumstances.
the whole setup is more complicated than just this,
since i also use Loopback to send other apps, mainly internet browsers also to this GP āAudio routingā instance. Thats then my multimedia setup.
This Routing instance is set to buffer: 64 samples.
( its never completly empty of plugins. Some Racks do even go up to 17% CPU load. Mostly not over 11%.
But its NEVER doing any audio creation. Mostly EQ + Compression, plus the imho mandatory End of audio chain limiter.
( It has more advantages, since i can also load my ātailor audio for headphone usageā plugins there)
its the best way to deal with complicated audio routing settups, i found for me.
True to keep audio crackling low, and true for easiest possible and most flexible handling, for inter app routing, working with different apps.
thank you, iāve read this before. with all respect to your expertise and finding a solution, i am currently looking for the simple, standardized way to make virtual audio work with GP4 (without a buffer size of 1024 etc.), as possible with other audio software - as in my example NI Guitar Rig 6.
canĀ“t comment vs. the left out part in my quote.
We both finally deal with one same thing:
To deal with: āmixing blackhole and the AIā into one setup.
iĀ“m since 3 years into GP, and had at first several attempts to make such a āmixed AIā setup.
I allways drived away from doing so.
I was allways running into some sort of problems.
Mostly latency. But not only.
The problems with crackling become in my system prominent when switching from a high-latency AI, NI kore 6, to a super low latency AI, Presonus Quantum2626.
From what i gathered overall, is it looking to me, like ālow latency devicesā are way more prone to crackling.
Here, in that sense, would i consider GP to be such a ālow latency deviceā.
Just on the software side of things
IĀ“m not saying GP āis the causeā of some of the crackling.
There is so much interactions going on. Could be some single plugins, etc. etc. etc.
Dealing with blackhole AND a AI is in my -noob- opinion definitly complicating the things.
( as mentioned, we are on the same pc plattform, Apple Silicon)
The solution i propose IS a workaround. Thats for sure.
IĀ“ve read, that youĀ“re not interested in workarounds
But there is this small detail:
by making my 2nd GP instance my 1st one, AND have it set to autoload, was half the deal for me, => vs. to take the āworkaround-feelā completly out.
The other half of my deal is this: to install the mac scripts vs. GP !
so that other instances can be loaded directly from the macs Titlebar.
I had this scripts loaded allready anyway,
since this is the quick and sober solution to be able to start GP in Rosetta2 mode, or in ARM native mode. As one would wish.
Each requires a own script, and creates you a own entry, accessible from the macs titlelbar.
The setup as i have it, does not feel anything like a workaround.
The only drawback i see vs. this type of setup is:
longer start-up times ( especially with a mac with only 8GB of RAM / with 16GB its ok)
its in general the best solution i found vs. dealing with this Situation:
run PC internal audio routings with āblackholeā or āLoopbackā in conjunction with your common audio interface.
i can only vouch here vs. AS macs ! But on those, is the multi GP instance approach the least problematic approach / the easiest one to deal with, that i found.
. - _ - _ - _ - _ - _ - _ - _
The scripts have been made, and been posted here in the forum by @rank13.
Script text vs. ARM native:
do shell script ā"/Applications/GigPerformer4.app/Contents/MacOS/GigPerformer4" -in=GP4_1ARM_MAIN-play &>/dev/null &ā
Script text vs. Rosetta2 mode:
do shell script āarch -x86_64 "/Applications/GigPerformer4.app/Contents/MacOS/GigPerformer4" -in=GP4-1Intel_Main-play &>/dev/null &ā
this is here the Name of my 2nd script.
Name the title of the script same, as you have it within the script.
GP4-1Intel_Main-play
check vs. which passage within the script this is.
you are free to chose your own name ofcourse
just open the script editor. ( personally, iĀ“m a computer idtiot. Means: everybody can do this ! )
=> IĀ“ve just posted this in case your interested to have a look, vs. āthat solutionā
or anybody else
@npudar, maybe you want to bookmark this thread/post
overall is my personal opinion that GP spits out more audio crackles then when using a DAW.
As seems to be the case with low latency AIs. at least with my presonus one.
i can live with it up to a certain degree.
My system is now on the āok-side of thingsā for me
here is a screenshot of how my mac titlebar looks, when clicking on the script icon
( yes, i created that many different GP instances i can chose from.
Its also a way to chose directly different audio settups at GP-main startup)
i could go and preach this setup, it works so good, haha
In a DAWs, most of the data is already stored in tracks. They can look forward, they can precalculate most of the the audio that plugins produce. So they donāt have to run all plugins in real time
Not to mention you usually use DAW-functions with a much higher buffer size, operating with latency that just wouldnāt be applicable to live performance.
