That's not actually what I was thinking when I was putting together the API of libpd. My goal was simply to create the thinnest possible wrapper in C that would make Pd embeddable, and then to add the thinnest possible Java bindings that would make the C API available to Android devices. The latter, with all the static methods in PdBase.java, drew some criticism from some Java people, but I still believe that minimality is the way to go for a library like this.

I also figured that support for multiple instances, if it ever happened, would be an excellent excuse to start over and create a new API that would be informed by the mistakes of the original API. I have little faith in up-front design that tries to imagine what might happen in the future, but I do believe in Brooks's admonition that you need to be prepared to throw the initial version away.

As it happens, the original API has held up rather nicely, and I would change relatively little if I were to start over right now. One minor regret is that the libpd API has a few function names that don't include verbs, a vestige of the initial rush to get stuff to work. A bigger concern is that in virtually all use cases, it's good to have lock-free ring buffers between the messaging functions and the audio processing callback, for both input and output. We've been retrofitting ring buffers as needed and that worked out okay, but it probably would have been cleaner to have them in the core library.

Cheers,

     Peter