Sunday, February 13, 2011

LibPD with Thicket

Developing music software for iOS has been a thrill and a terrific frustration. I've been looking for weeks for an audio engine which could manage signal chains efficiently for me, has a license which won't force me to open-source my software, and can be configured in a c-flavor language. I've come up with basically nothing. My only option (and I'm very grateful for this option) seems to be libpd -- an embeddable version of pure data. This is great, except for the fact that PD designed as a graphical programming language, and to someone like me accustomed to writing code, strikes me as bizarre, wrong, difficult, painful. But I'm going to stick it out for a while and see if PD's beauty decides to present itself to me.

I'm not confident about my ability to write an efficient audio engine, but I am very confident about my ability to use code to express artistic and structural concepts. So I'll be using PD only for signal chain, keeping absolutely as much application logic as possible in code. This brings me to the question of which language to use. Of course, the iPHone's native language is objective-c. But I'm liking C++ a lot more. The syntax is simpler. And it allows me to write all of my code in the header files if I feel like it. I know this is considered bad form, but sometimes I like to take off my engineer's hat and put my artist hat on. With my artist hat, I'm allowed to look at a technique, and say "too slow, too many keystrokes". And that's how I'm feeling about Objective-C vs C++. So I'm tending to thing that for audio logic, C++ is the way to go.

Mixing languages on the iPhone is a pain in the ass. You can mix Objective-C and C++, but you have to jump through hoops in order to avoid compiling your entire application as Objective-C++. That can be necessary if you want to mix C and Objective-C in other parts of the application. I'm currently getting an inexplicable linker error in XCode: "libpd_bang(char const*)", referenced from:". This is maddening, especially to a relative newb. The complier doesn't complain, but the linker fails. I've come across a similar problem before, but I don't remember what the solution was. I'll post back here if I figure it out.

EDIT

I fount my previous linker error. It's described here:

http://stackoverflow.com/questions/4812183/xcode-is-not-even-trying-to-compile-some-of-my-mm-files-then-fails-while-link

This one is not the same however. The previous problem was that the file wasn't even being compile, because it wasn't added to the target. In this case, the file is being compiled. The function in error is even being called successfully from PDBase.m, but it's not being called successfully from other files.

EDIT

Ok. I think I've solved it. Using the "extern c" as recommended here helped:

http://iptrk.ionismus.de/post/94485387/mixing-ansi-c-and-c-in-a-xcode-3-x-project

EDIT

PD's patching graphical interface was driving me crazy. I've decided to to just become a better programmer and stick to low-level stuff. It's not that much more work in the end, and I get to keep my hands on the keys, rather than reaching for the mouse.

No comments: