On Feb 24, 2014, at 6:00 AM, pd-dev-request@iem.at wrote:
when i (last) looked into the libpd API, i noticed that libpd works on a global namespace as well...what i mean is, that the API (at least the C-API, i haven't checked the others) does not allow to specify an "instance" of pd.
That's correct. Because there isn't currently a way to multiple instances beyond previously mentioned hacks to the core or non-portable linker flags, the api isn't in place to support it.
but i fail to see why libpd doesn't provide the API for this, even if the "instance" pointer would not be used (until Pd does support multiple instances).
e.g. the application programmer would have to check that libpd_init() returns non-NULL anyhow, and in the current implementation it would always return NULL but the first time being called.
this would have allowed for a transition to multiple instances without having to change the API...
Good point. I wasn't involved when Peter first started the project and I'm sure, back then, multiple PD instances seemed waaay off into the future. I think the best/easiest way to handle this without breaking anyone's current code, would be to shadow all of the functions with functions that take an instance pointer, as you suggest. The default ones would simply handle a single internal pointer to the first opened instance, as it does now. If you use the pointer manually, then it's up to you to keep track of it. I we don't mind breaking compatibility, we can simply add an instance handle to each function we have now. Either way, not that difficult.
The C++ wrapper I wrote has api support for multiple instances (aka you can create multiple PdBase classes). Internally, that is handled by a PdContext static class which would theoretically return new instance pointers but, for now, it simply calls the global libpd functions and there is a big warning in the documentation about only using 1 PdBase instance for now.
Again, wouldn't be too hard to add, just currently waiting whether this could become a reality.
-------- Dan Wilcox @danomatika danomatika.com robotcowboy.com
Good point. I wasn't involved when Peter first started the project and I'm
sure, back then, multiple PD instances seemed waaay off into the future.
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
-
Dan Wilcox -
Peter Brinkmann