Post not yet marked as solved
Apple has confirmed this issue is a bug. I have filed a bug report.
Post not yet marked as solved
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"];
}
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
@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.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Well, this problem is related to using the SKScene (which is the root node of the scene) as the node to crop. This seems to be a known Apple bug (#29005461) that was submitted on 2016 and it seems it has never been fixed (Wow! 3 years. Every place that I have worked in, a bug this serious that hasn't been solved for 3 years is unheard of and totally unacceptable). There is a workaround, you have to create your own root SKnode and use the method on that node instead.
Post not yet marked as solved
Did you ever get a resolution for this issue? It is 2019 and this bug is still present. If you use the rootNode (SKScene) as the node to crop and generate a texture from, the texture is always the same regardless of changing the origin CGPoint of the CGRect defined for the crop. The workaround of creating a node as a root node still works. This is definitely still a bug.
