Well, I was right. The issue turned out to be an odd interaction between lib_juce/juce_opengl and the AMD driver GL library.
I noticed that 2.1.7 community 32 bit still showed fonts, and started doing a diff to see what might be happening. Found the hand off, and it told me where to look in the headers for libglx-mesa0 and… the interface changed. Old entrypoints were still in there, but they changed a bunch of later functions, and appear to have left in stubs that don’t do anything.
So juce was handing off render objects that required GL (fonts, and some UX elements), which GL was dropping on the floor and returning null objects.
If I step all the way back to JUCE 6.0.8, all the fonts are back.
6.0.8 uses a legacy GL api that is still supported in the AMD drivers.
This weirdness in in the commercial AMD supplied drivers AND the open source ones. So I kinda get the feeling that AMD is plundering the open source xdna-driver git repo. LOL.
Anyway, I hope this prevents anyone else from going spare.
Roll back the JUCE in lib_juce to 6.0.8 and make sure you have amdgpu-core 1:7:2 or earlier (max version tested, might work on later)
cool, but odd thats is such a low level issue - not common, as it’d usually affect a lot of apps.
hmm, so basically the new drivers dont support the legacy gl api, but juce has not been updated to the newer api.
rolling back is really only temp workaround, as I cant promise that later versions of juce will still be compatible with 6.0.8. i.e. we have to make breaking changes to support 8.x
might be ok for a while, as eigend doesn’t really use a lot of the juce of the api. but just so you know.
I’ve a feeling that it might be something that the AMD/ROCm drivers will fix tho, as there are a lot of games that still use GL, and not Vulcan, and proton doesn’t work with everything. So I imagine that there’s gonna be pressure on AMD to fix the interface issue, and there are more than a few issues open on the xdna driver repo that appear to be related.
So, I think that this is likely to be fixed on the AMD driver side before JUCE updates come down the pipe. fingers crossed
Besides, you’re absolutely right. It’s a bit of a niche case. There aren’t that many folk that need the ROCm enabled drivers, as those are used almost exclusively for ML or data visualization tasks where you have multi GPU setups. Not a whole lotta users out there buying high end workstation or server machines to run their audio apps, and if they do,they’ll likely be on a mac studio.
So, maybe it’s not gonna be a big problem. I just happen to be in an edge case scenario.
But it was an interesting lesson for me about how the rendering pipeline works in JUCE and got me to really get deep into how EigenD does things, and gave me a kick in the butt to learn SCons a lot better. LOL.
Thanks for all your help and insight. You got me pointed in the right direction. I’d never have got there without your help!
is it when you run the installer… Im wondering if for some reason that has been built as x86_64…
I’ve probably got rosetta installed on all my macs so didn’t notice… and, whilst I checked the EigenD process was running Arm, likely didn’t check installer.
hmm, weird, so when I run the installer, its all native.
until it runs the scanner, then its seems to run bash as Intel, not some unknown reason… as all scanner components are all arm
the only thing, I can think of on my machine is it might use the 2.2.1 install I have, i.e. a path issue? but Id assume you dont have 2.2.1 installed, so that would not be the case for you.
edit:
yeah, I cannot find an obvious reason…
do you get the prompt before it starts the installed (i.e. dialog comes up), or at a specific stage during the install process?
unfortunately, doesn’t look like I can uninstall Rosetta, so its very difficult for me to see whats going on.
Yes, it’s coming up as soon as I launch the installer. What might be relevant is that I used the Migration Assistant to pull everything from my old x86 MacBook when setting up the new one. (so yes, I probably do have 2.2.1 installed here!)
hmm, so if no dialog comes up, then that means the nothing has been run yet.
I only saw these 2 intel bash processes start when it got to running the scanner.
however, apparently, macOS will look at a package and if it sees a intel binary then you get this warning. so Im assuming thats what’s going on.
However, I just checked all the binaries that are exported to the package, and all binaries are arm64.
I wondered if some how the package manifest would tell macOS what ‘type’ it was, and if that was the issue, but I can’t find anything that says that is the case.
hmm, also just unpacked the package, and again, as above, no intel binaries.
so Ive no idea why it thinks it needs rosetta !
will have to muse on it a while, as Im out of ideas at the moment.
Installed Rosetta and the beta. Had a very quick play with a Pico over lunch, and noticed that with the cello rig, bowing via the strip only works in one direction (bottom to top).
so strip is -1,1, but thats it position, not its direction.
so there, shouldn’t be any difference (in direction of travel) as far as the hardware and input side to the cello is concerned.
looking at the cello code, the bow velocity is calculated as a change in position, and it actually is happy for that to go negative/positive. no changes in the code in this area of STK (which is how the cello is implemented)
so, I cannot see an obvious issue, or anything that has changed.
it’d need more testing for some more data points…
Id have to test on previous versions to check to see if this is new to 3.0 or an issue thats started at some previous time.
Id like to test it on an alpha/tau to test to see if its related to the pico.
perhaps Id test the strip against something else, eg. midi output? to see if the strip behaviour is as expected.