I also noticed this happed when running auvaltool. As with all things AU, I find it better to err on the safe side and do (what should be unnecessary) checks in the render block. The flags can be useful but not always.
Also it's certainly a good idea to always assume the host app will do something horrible. IMHO ( and it's only my opinion) This day and age with CPUs being so much faster, it's not so bad to do a few checks at the start of the render block before proceeding with the main DSP ...
Post not yet marked as solved
You could use group defaults?
Post not yet marked as solved
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 AppKit 0x7ff80b5535c5 -[NSWindow _setKeyViewGroupBoundaryNeedsRecalc:] + 32
1 AppKit 0x7ff80b53b4e9 -[NSView _primitiveSetNextKeyView:] + 227
2 AppKit 0x7ff80b57989a -[NSView _removeNextPointersToMe] + 602
3 AppKit 0x7ff80b579428 -[NSView _removeFromKeyViewLoop] + 203
4 AppKit 0x7ff80b578ddb -[NSView _finalize] + 797
5 AppKit 0x7ff80b578986 -[NSView dealloc] + 119
6 libdispatch.dylib 0x7ff808886317 _dispatch_client_callout + 8
7 libdispatch.dylib 0x7ff808892c78 _dispatch_main_queue_drain + 943
8 libdispatch.dylib 0x7ff8088928bb _dispatch_main_queue_callback_4CF + 31
9 CoreFoundation 0x7ff808b459c7 CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE + 9
10 CoreFoundation 0x7ff808b0693f __CFRunLoopRun + 2771
11 CoreFoundation 0x7ff808b057ac CFRunLoopRunSpecific + 562
12 HIToolbox 0x7ff81178cce6 RunCurrentEventLoopInMode + 292
13 HIToolbox 0x7ff81178ca4a ReceiveNextEventCommon + 594
14 HIToolbox 0x7ff81178c7e5 _BlockUntilNextEventMatchingListInModeWithFilter + 70
15 AppKit 0x7ff80b52c5cd _DPSNextEvent + 927
16 AppKit 0x7ff80b52ac8a -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1394
17 ViewBridge 0x7ff8100581c2 __75-[NSViewServiceApplication nextEventMatchingMask:untilDate:inMode:dequeue:]_block_invoke + 111
18 ViewBridge 0x7ff810058003 -[NSViewServiceApplication _withToxicEventMonitorPerform:] + 114
19 ViewBridge 0x7ff810045bf3 -[NSViewServiceApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 151
20 AppKit 0x7ff80bcfd55e -[NSTextView _bellerophonTrackMouseWithMouseDownEvent:originalSelection:granularity:extending:rectangular:toggling:multiple:autoscrollEvent:] + 1402
21 AppKit 0x7ff80b8e8710 -[NSTextView mouseDown:] + 7259
22 AppKit 0x7ff80b72a1f1 -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 4859
23 AppKit 0x7ff80b69e39e -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 2582
24 AppKit 0x7ff80b69d76e -[NSWindow(NSEventRouting) sendEvent:] + 352
25 AppKit 0x7ff80b69bb44 -[NSApplication(NSEvent) sendEvent:] + 352
26 ViewBridge 0x7ff81004666b __65-[NSViewServiceApplication sendEventWithoutCatch:withForwarding:]_block_invoke + 115
27 ViewBridge 0x7ff8100465bd -[NSViewServiceApplication eventHasNotHitWindow:actions:] + 62
28 ViewBridge 0x7ff810046337 -[NSViewServiceApplication sendEventWithoutCatch:withForwarding:] + 344
29 ViewBridge 0x7ff8100d37ce +[ViewBridgeUtilities allowSettingMousePointerImageInBackground:whilePerformingActions:] + 239
30 ViewBridge 0x7ff81004612f -[NSViewServiceApplication sendEvent:withForwarding:] + 103
31 AppKit 0x7ff80b95496b -[NSApplication _handleEvent:] + 65
32 AppKit 0x7ff80b51d35e -[NSApplication run] + 623
33 AppKit 0x7ff80b4f12b7 NSApplicationMain + 817
34 libxpc.dylib 0x7ff808785874 _xpc_objc_main + 867
35 libxpc.dylib 0x7ff808785239 xpc_main + 99
36 ViewBridge 0x7ff81003f406 -[NSXPCSharedListener resume] + 16
37 ViewBridge 0x7ff8100417e6 NSViewServiceApplicationMain + 1326
38 AUHostingServiceXPC 0x105c738c8 0x105c6d000 + 26824
39 dyld 0x10cd5d51e start + 462
Thread 1:
0 libsystem_pthread.dylib 0x7ff808a3cf48 start_wqthread + 0
…
Answering my own question with RTFM!
Yes is it possible:
AUMIDIEventListBlock,
AUScheduleMIDIEventBlock scheduleMIDIEventBlock
kMIDIProtocol_2_0 etc .
I just stumbled upon this question while I was looking for something else, and I am making the assumption you've only recently started programming (apologies if not, but then you probably wouldn't have asked) ....
Ask yourself why would dividing 2 Ints yield 0?
Also perhaps, It's interesting that the Swift documentation doesn't often discuss the fundamental building blocks of all programming languages. It does assume the programmer already has that in their arsenal before launching themselves into the ether.
Here's a page (i found in a quick google search) that might explain what you need to know just as well as anyone here could...
[https://www.programiz.com/swift-programming/data-types]
The documentation appears to have been updated recently....
An audio unit may choose to dynamically rearrange the tree. When doing so, it must
issue a KVO notification on the audio unit's parameterTree property. The tree's elements are
mostly immutable (except for values and implementor hooks); the only way to modify them
is to publish a new tree.
But sadly it seems most of the important hosts don't appear to respond to the notification and so it's probably not a good idea to change the tree after it's created.
Some time later ... ...
In the end my solution to the compression bit-rate was to revert to using the old ExtAudioFile API with an input consisting of one or two 32 bit uncompressed float channels and utilising the kAudioConverterEncodeBitRate property on the compressed formats I needed.
The problem with the WAV files incorrect format turned out to be a bug which Apple acknowledged and is now fixed :)
NB: For my purpose, after a deeper read of the documentation, rather than set the entire shader to -fno-fast-math I've also found using the namespace metal::precise:: seems to work as expected. But my original question about the compiler setting is still valid I think. I don't consider myself an expert in MSL so I'm interested in knowing what is considered best practice etc.
Post not yet marked as solved
Thank you!!! Hunting down this issue was driving me mad!
Post not yet marked as solved
Interestingly, on iPadOS 13 beta 1 my UITableViewCell subclass is now rendering images at their x3 size instead of resizing to the height of the cell. Working around it at the moment by setting the view and text frames explicitly in layoutSubviews().[and before I get the "are you calling super" reply ... yes I was/am 😉 ]Still seeing the warning as described above in the log, as far as I can see, code that has always worked previously is now generating this warning. Maybe just one of the initial bugs in iOS 13?
Post not yet marked as solved
+1, same issue.Installed Catalina beta on a partititionBooted into CatalinaInstalled XCode 11 betaRan XCode to install it's files.Downloaded iPad mini (5th generation), iPad Air (3rd generation)Brand new iPad Air 2019, visible in Catalina's Finder.Attempt to restore to the iPad ... - "firmware incompatible"( re-downloaded the restore image 3 times, get the same error each attempt ).
Post not yet marked as solved
+1, seeing the same warning hereSomething to do with custom table view cells?
Thanks Scott, Since originally writing this post I've discovered 2 things ...1) Integers being written to WAV files when float is specified is actually a bug in Core Audio. It's been there a very long time from what I can see, others have reported it in the past and I have also just reported it. But I'm not holding my breath for a fix.At the moment it seems one must use AIFC or CAF to successfully write floating point audio files using core audio.2) You're quite right. It doesn't seem possible to specify an actual bit rate in compressed forms. ( So I've stopped worrying about that ! 😉 )
Post not yet marked as solved
Still have this issue, it’s not gone away with even the latest beta. The Bluetooth module appears to crash occasionally. Sometimes even requires a restart. Nothing non-apple in the loop. Magic mouse, magic keyboard that’s all.
Post not yet marked as solved
In fact I just lost BT altogether, had to connect a usb mouse and keyboard to reboot! If anything the problem is now worse than it was in the previous beta.
