Kineme Audio File Player crashing Cocoa Simulator

rishabh's picture

I'm trying to make an app out of a quartz composition but everytime i do a simulate interface. The simulator crashes. I think its because of the audio file player. I removed the audio file player and it doesnt crash. I noticed some one else had a similar problem and the fix involved removing the complete path. I tried that still didnt work. In fact i just put the .mp3s in the root folder along with the quartz composition and it still didnt work. Any ideas what I'm doing wrong? Thanks in advance.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

cwright's picture
Re: Kineme Audio File Player crashing Cocoa Simulator

submit a sample xcode project, some crash logs, or something.

rishabh's picture
Re: Kineme Audio File Player crashing Cocoa Simulator

ok. I clicked on report when simulator crashed and copes the info it gave me and put it in crash.txt I did the build despite the crash so you could check it out.

Thanks again.

PreviewAttachmentSize
Archive.zip2.39 MB

cwright's picture
Re: Kineme Audio File Player crashing Cocoa Simulator

The crash doesn't appear to be kineme-related (there's no kineme stuff in the backtrace) -- not necessarily the case, but it's not looking informative for us.

Further, the exception-throwing line is -[NSURL initFileURLWithPath:]; -- AudioTools has exactly zero calls to -initFileURLWithPath, so it's looking even less interesting.

Can you provide the composition? Extracting a composition from a nib is arduous, and I don't feel like using an alternative at the moment.

rishabh's picture
Re: Kineme Audio File Player crashing Cocoa Simulator

hey, Heres the quartz comp with the mp3 file.

PreviewAttachmentSize
Quartz Comp.zip358.81 KB

cwright's picture
Re: Kineme Audio File Player crashing Cocoa Simulator

ok, this is rather complicated (3 parts):

Part 1: Since you're using the file player, it takes 1 of 3 kinds of paths: An absolute path (/foo/bar/mysound.mp3), a relative path (~/foo/bar/mysound.mp3), or a composition-relative path (mysound.mp3). When using the last case, it attempts to resolve the path using composition information (compositionURL, specifically). If it fails, it just has nil for the string, and that's usually ok.

Part2: Internally, NSSound is used as the engine behind the AudioFile Player (part of the reason why it doesn't have many features. Apple's docs don't say anything about the input path not being nil. (nil is different from empty string -- it's much more difficult to get a nil string in QC, they're usually empty, so this slipped past testing) Apparently, when the input string is nil, it generates an exception internally, and 'splodes. We can catch that in a future version, but more ideally, apple should update their docs ("Don't pass in Nil strings!"), or add a single-line check ("if(inputString==nil)return nil;") to their NSSound code ... I'm not holding my breath for either, as they've got way more important stuff on their plates right now.

So, that gets us understanding what's going on -- next up: why you don't want to deal with this anyway.

Part 3: you're embedding a composition in a nib. When that happens, all metadata is lost (specifically, compositionURL). Without compositionURL, you're unable to use composition-relative paths. This means you have to use an absolute path (/Applications/3D NUMBERS.app/contents/resources/mysound.mp3), or a user-relative path (~/Applications/3D NUMBERS.app/contents/resources/mysound.mp3), neither of which are useful for your app (as users will have it in different locations).

Currently, the best way to solve this would be to not embed the composition, but load it manually in the code. Alternatively you can publish an input and have the app feed in the resources folder path, so the composition can build the proper absolute path for itself.