I found this hack solution in Stack Overflow which seems to solve the issue. Edit the Scheme, go to the Info tab and turn off Debug Executable. It would be great to know why this works.
Post
Replies
Boosts
Views
Activity
Apple has confirmed this issue is a bug. I have filed a bug report.
This is an old post but maybe someone is still looking for a solution. I found that you can just override the fullStateForDocument property and just archive your settings using a Dictionary. No need to play with parameter trees if you don't need your settings to be modified by the Host.
// Save an NSString named setting.
- (NSDictionary<NSString *,id> *)fullStateForDocument {
NSMutableDictionary *state = [[NSMutableDictionary alloc] initWithDictionary: super.fullStateForDocument];
NSDictionary<NSString*, id> *settingsToSave = @{@"setting": setting,};
state[@"savedSettings"] = [NSKeyedArchiver archivedDataWithRootObject:settingsToSave requiringSecureCoding:NO error:nil];
return state;
}
// Retrieve settings
- (void)setFullStateForDocument:(NSDictionary<NSString *,id> *)fullStateForDocument {
NSData *data = (NSData *)fullStateForDocument[@"savedSettings"];
NSDictionary *savedSettings = [NSKeyedUnarchiver unarchivedObjectOfClass:[NSDictionary class] fromData:data error:nil];
setting = (NSString *)savedSettings[@"setting"];
}
Hi @JHostetler2, did you find a way to solve this? I have exactly the same issue. Did you have to transform everything you wanted to save into parameters in a parameter tree and then use the fullStateForDocument to be able to save everything? If so, how is the fullStateForDocument used? I really can't find good documentation of how to use this. Thanks.
I am having hte same issue. I talked to a representative and sent them all the information they requested but haven't received any response. I need to send these promo codes on the next day or two.
@Claude31, thanks for taking the time to comment and come up with a workaround.
In my example, both buttons are children of the default view of a view controller. This view is the Superview for both buttons, and the Safe Area is the one defined for that view.
In my example I expected to see a result like you got in your second screen shot. It seems like you have come up with a workaround for this issue by creating an extra view that matches the Safe Area and placing the button there. I think there is a problem in Interface Builder. Height and width constraints with respect to the Safe Area (without a need for an extra view) work (I have tested those and they work), but horizontal and vertical alignment constraints don't. I guess I will have to implement your workaround. It is very unfortunate that something as simple as this doesn't work correctly.
My first entry on this question has a lot of errors and misconceptions but I can't edit it anymore.
First, the MIDIOutputEventBlock is a property of the Audio Unit plug-in. According to the header on this property: "The host can set this block and the plug-in can call it in its renderBlock to provide to the host the MIDI data associated with the current render cycle."
Second, in the example code that I referenced, the class that calls the allocateRenderResourcesAndReturnError and the internalRenderBlock methods is the actual AudioUnit class. In the template currently being generated by Xcode, these methods are part of the xxxDSPKernelAdapter so, of course, using self will generate a compile error.
Any insight anybody could provide on how to obtain and then cache the MIDIOutputEventBlock property, would be greatly appreciated.
To complement the answer above, the sample rate can vary depending on the device, or the audio output (speakers, headphones, bluetooth, etc). It is necessary to determine the sample rate, by looking into the sample rate of the audio session:
let audioSession = AVAudioSession.sharedInstance()
let sampleRate = audioSession.sampleRate
let audioFormat = AVAudioFormat(standardFormatWithSampleRate: sampleRate, channels: 2)
I had been misled in my research on how to do this, that you had to use the MIDIReceived method (which was strange) to send MIDI packets to the source and then these would be sent out on the output port. Well, turns out that the answer was to use the MIDISend method which actually sends the MIDI data from an output port to the destination ref.
Having the same issue. Agree, unacceptable that Apple can't inform of outages or issues with their "Sales and Trends" system.
I printed out the AVAudioPCMBuffer format and for some undocumented reason (not the first time, this seems to be a recurring theme with Apple's APIs) the sample rate defaults to 48000Hz. This is what is causing the speed discrepancy. Changing the following line of code, fixes the issue:let audioFormat = AVAudioFormat(standardFormatWithSampleRate:48000, channels: 2)
It seems like
AVAudioRecorderonly records from the microphone. The solution is to install a tap on the
mainMixerNode. This tap provides an
AVAudioPCMBufferwhich can be written into an
AvAudioFile which can be an MPEG4AAC file.
I know this is an old question but I was running into the same problem where the diagnosticd and the ReportCrash processes started to consume high percentages of CPU and the fans would start spinning. After trying many things I found that the only thing that worked was to go to the simulator "Hardware" menu and select "Erase All Content and Settings...". Then quit the simulator and start it again. After that, the problem goes away. Hope this helps anybody searching for a fix for this issue which is still happening in XCode 11.2.1 running on Mojave 10.14.6.
I know this is an old question but I was running into the same problem where the diagnosticd and the ReportCrash processes started to consume high percentages of CPU and the fans would start. After trying many things I found that the only thing that worked was to go to the simulator "Hardware" menu and select "Erase All Content and Settings...". Then quit the simulator and start it again. After that, the problem goes away. Hope this helps anybody searching for a fix for this issue which still is happening in XCode 11.2.1 running on Mojave 10.14.6.