I want to ENCOURAGE the dev community and JUCE team to resolve this ASAP
Hi folks, First of all, I’m a fan of much of what is being accomplished, with JUCE, I own and use many of these plugins.
Central to what I do is PluginGuru’s Unify since about 18 months ago. As Apple has dead-ended all of my Intel machines, excepting one maxed out i9, which is still under AppleCare which is probably why they can’t obsolete it yet, I’m now embarking on the transition to Apple Silicon for all of my music-making gear (live and studio rigs).
Unify is severely under-performing on AS, to be specific a Mac Studio. Audio is cracking and popping under as good as zero load. This would appear to be a problem of Unify also utilizing energy cores versus performance cores, with no mean by which, we, as users, can instruct Unify to stay away from the e-cores.
Realtime audio, especially performance-oriented software needs to be up and in the p-cores only. Even Apple understands this as MainStage won’t even offer e-core selection, and Logic allows users to select e-cores if needed, but there are p-core only options. Again, Unify cannot do this as what I’m hearing from the developer (who is always responsive!) is that he’s dependent on a long-promised solution via the platform, but none available yet…
I have taken a few days to read through the relevant threads here, and… I’m not just a musician, I have worked for “those guys in Redmond” and have decades of work in product launches, product development, and implementations. I’m retired from that world, but “I get it”. Folks are searching for a solution, and kludging solutions that maybe work for AU, but not VST… so forth and so on…
Hence the encouragement to get this issue solved. Cleanest is obviously to have p-only core affiliation handled by JUCE. It appears that folks aren’t clearly in understanding how Apple wants this accomplished, is it a priority, a flag, or some high-road QoS based audio workers workgroup solution??? Dunno… That last one is a lot of work for something Apple shows to users as p-core preference and affiliation in their own products. I don’t know - I just know they’re doing something, and it appears that high-end SoCs that have a bare minimum e-cores are causing issues in one or more products that leverage the JUCE platform.
As an end-user - just need Unifi’s developer supported, either direct, peer-developer support, or… a move “up” the priority list for getting this somehow into JUCE.
To be clear… not all of my JUCE-based products are manifesting this unusable show-stopper behavior. I don’t know why. It raises a question for me as well, okay, how are developers then “rolling their own” solutions where this is not handled in JUCE??? How resilient are those solutions? Again, dunno. Don’t need to know… am an end-user.
Just need, and hence this request, in the form of encouragement, to see how to implement anything at all that resembles what Apple seems to be doing in their own products, which is presented to users as p-core affinity and not what might behind the scenes actually be a workgroup of processes that are in reality, either set by priority or some other mechanism to be p-core processes.
Dunno, and as an end-user, don’t need to know either - just need what BillG once described to me as the “promise of technology” to manifest itself here so that we can continue to do what folks not all that long ago, could only dream of.
Again, couldn’t be happier in general, but this issue is a real show-stopper.
In closing, am not complaining. I just can’t use this product if it cracks and pops within seconds. Just can’t. Could never recommend to use that layer for live touring acts. That’s just a reality.
What I can do, and that is the point of this post, is to raise awareness of a problem and encourage all to help enable each other to get over this new asymmetric model of e-core and p-core computing.
When “up there” in the p-cores, it seems to behave as expected.
How can I help more than just encouraging y’all to have a look into this (soon, if not yesterday)?