O/T, but this winds me up : Could NOT give a fuck. Or “couldn’t”.
“Could give a <X>” literally changes the meaning of the sentence to the opposite of what is intended.
O/T, but this winds me up : Could NOT give a fuck. Or “couldn’t”.
Somebody needs a lesson in American idiom.
Hi Markus here – from the MusicApps Team at Apple,
I’ve tried to contact as many Audio Unit developers as possible before WWDC to get your contact information. I’ve gotten a lot, but obviously not all. We have started a brand new ProAudio Seed program last week and if you were contacted by me or we already had your contact info, you should have received an invitation to the seed program. Some did not, simply because your email provider considers invite emails from Apple spam. We are not sure, how we can resolve that on our side.
We are seeding universal versions of Logic Pro, MainStage and GarageBand build against the macOS 11 SDK, which should help you significantly to test your Audio Units. The seed program also allows you give direct feedback to the MusicApps team. For Apple Silicon development and testing you need the DTK. But for Big Sur compatibility testing on Intel, the seed is also extremely helpful.
I am sorry, but I am not able to provide support or answer questions here. If you are an Audio Unit developer, please contact me with your website, some of the AUs you are working on, your full name, and preferable the Apple ID email used for your developer account at email@example.com. I know, that might sound like phishing, but it is not – maybe some people here can back me up on that
There, see, @asimilon. They could give a fuck, as it turns out.
Are you using the American idiom now, and they could not give a fuck?
For what it’s worth I’ve received the email from you and you were very helpful in responding to the question I had, so I’m pretty sure you’re legit
getMsgSendSuperFn() (&s, @selector (keyUp:), ev);
Crashes on BigSur with EXC_BAD_ACCESS on keyUp. So I can’t log into Projucer.
SystemStats::getOperatingSystemType() needs updates. It doesn’t have macOS 10.15, and it fails if the major OS version is 11.0 and instead returns the OS version as 10.0.
So macports doesn’t seem to have too much of its build tools and related ports arm64 ready. How does it compare to brew? Any experience?
I finally got brew working. They have an issue here with the state of all the packages: https://github.com/Homebrew/brew/issues/7857
Just a warning, do not ask the Brew team for any help with Big Sur, they will delete your comments.
Thanks to everyone who has already tried out JUCE on macOS11/ARM and raised issues on this topic.
I’ve pushed some initial changes to
develop which should make it possible to build and test ARM binaries without needing to tweak JUCE itself. In particular, I’ve fixed the
Edit: the link above is just the first commit in a series of several commits that improve compatibility with the new OS + hardware. Please check out the current state of develop if you’re interested in using JUCE on macOS/ARM.
Having some crashes when touching the keyboard in plugins and the AudioPluginHost sample. It’s fine if I do a universal and select Rosetta, but crashes when running natively on Apple Silicon, all I did here was build, run, touch a keyboard button and it fell. (I incorporated the latest changes above.)
Crashed Thread: 0 JUCE Message Thread Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000001 Exception Note: EXC_CORPSE_NOTIFY Termination Signal: Segmentation fault: 11 Termination Reason: Namespace SIGNAL, Code 0xb Terminating Process: exc handler  VM Regions Near 0x1: --> __TEXT 102100000-102dcc000 [ 12.8M] r-x/r-x SM=COW /Volumes/*/AudioPluginHost.app/Contents/MacOS/AudioPluginHost Thread 0 Crashed:: JUCE Message Thread Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x00000001d3388f48 objc_msgSend + 8 1 com.apple.AppKit 0x00000001916f58e0 -[NSView _nextResponderForEvent:] + 60 2 com.apple.AppKit 0x00000001916f57b4 forwardMethod + 84 3 com.juce.pluginhost 0x00000001028eae04 juce::JuceNSViewClass::keyDown(objc_object*, objc_selector*, NSEvent*) + 284 (juce_mac_NSViewComponentPeer.mm:1780) 4 com.apple.AppKit 0x000000019166f840 -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 5644 5 com.apple.AppKit 0x000000019166dfd4 -[NSWindow(NSEventRouting) sendEvent:] + 352 6 com.apple.AppKit 0x000000019166cdac -[NSApplication(NSEvent) sendEvent:] + 2512 7 com.apple.AppKit 0x000000019192d4ac -[NSApplication _handleEvent:] + 76 8 com.apple.AppKit 0x00000001914e17b4 -[NSApplication run] + 640 9 com.juce.pluginhost 0x0000000102652fe0 juce::MessageManager::runDispatchLoop() + 164 (juce_mac_MessageManager.mm:348) 10 com.juce.pluginhost 0x0000000102652ea4 juce::JUCEApplicationBase::main() + 364 (juce_ApplicationBase.cpp:262) 11 com.juce.pluginhost 0x0000000102652ccc juce::JUCEApplicationBase::main(int, char const**) + 68 (juce_ApplicationBase.cpp:240) 12 com.juce.pluginhost 0x00000001022337f4 main + 56 (HostStartup.cpp:155) 13 libdyld.dylib 0x00000001d44e2844 start + 4
Is this using the absolute latest develop? This crash looks very similar to an issue I thought I’d fixed yesterday.
It’s the public download of Juce 6.0.1, and I manually added the fixes you posted 3 hours ago.
Update: pulled the latest from develop, it’s fixed there.
Glad to hear it’s working now. I should have made it clearer in the earlier post that the fixes were spread over a few commits, sorry for any confusion.
Thanks @mfritze ,
I sent you a mail 2 days ago to enroll but didn’t get a reply and was wondering if maybe if it went to you spam folder.
Lorcan Mc Donagh
- Build and run DemoRunner.
- WidgetsDemo > Misc
- Type in text box
- Beep, beep, beep, beep
Anybody else hear that? Or just me because I’m using screen sharing?
I was hearing random beeps when entering my JUCE login and password.
Today was my first test using the DTK MacMini and the Xcode 12 beta for Universal Apps.
I updated my copy of JUCE to today’s latest on Develop and was able to build Projucer without any issues. I then opened up a jucer file of my latest plugin in development and Projucer created the Xcode project.
And the good news…my plugin builds and runs as a standalone app as well as loading into MainStage and playing as expected, all without issues.
Now, onto my full released plugin…
EDIT: Wonderful news…my current release plugin builds and runs as a standalone app and as an AU in MainStage. No issues.
Anybody know if it’s possible to set a different deployment target per architecture? And link different libraries per architecture?
So in the past this would have been done with settings like so…
MACOSX_DEPLOYMENT_TARGET[arch=i386] = 10.11 MACOSX_DEPLOYMENT_TARGET[arch=x86_64] = 10.12
project.pbxproj file it will get formatted like this…
"MACOSX_DEPLOYMENT_TARGET[arch=i386]" = "10.11"; "MACOSX_DEPLOYMENT_TARGET[arch=x86_64]" = "10.12";
I suspect for arm the arch value will be arm64 but I don’t know because I haven’t played with Xcode 12 or the DTK yet.
However you can’t enter it like that in the jucer file anyway because it seems the projucer will try to split it at the first
= sign and it won’t correctly quote the setting name and architecture attribute.
To be clear I haven’t tried this with the latest version of Xcode but if it hasn’t changed you should be able to follow these steps, but I’m running Xcode 9 in these screenshots!!
macOS Deployment Targetexpand the arrow on the left to reveal settings for each configuration (Debug, and Release)
- Hover over the configuration you want to create variants for
- Click the plus symbol that appears (see the first screen shot below)
- Click on the new label that appears to select the architecture you want to customise (see the second screen shot)
- Change it’s value on the right like you would any other setting
- To add more variants go back to step 3