As a follow up: this approach is what we’ve taken with libpd and it’s worked very well so far.

Peter initially discussed with Miller what changes and api access would be needed to wrap libpd. Once those were in place, the rest of libpd is essentially just wrappers around the vanilla core without touching the core directly. All I need to do to update libpd to a newer version of vanilla is to update the pure-data submodule to a new commit/tag and update the makefile to reflect any source file name additions or changes.

libpd *is* pd vanilla without the GUI or audio backend, not a variant or custom version. I’m not sure if that has been fully stated on this list.

Of course, the api & messaging requirements of libpd are small by comparison to a full UI implementation but I feel a similar process should be possible.

Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/

On Oct 7, 2016, at 11:27 AM, Dan Wilcox danomatika@gmail.com wrote:

...

On Oct 6, 2016, at 3:49 AM, pd-list-request@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:

1. External developers who want to support purr-data (pd-l2ork) can #ifdef their guis.
2. For those who don't want to learn a new toolkit, and for unmaintained libraries, it'll be up to purr-data developers.

Until we have good documentation for integrating pd+nwjs, the first option may only work well for people who have a toe in both pools. I think that's me for cyclone, and I'll be glad to support purr-data directly in the new cyclone library as soon as I have a good chunk of time to do it, and some time to work out the kinks with Jonathan.

I know I’ve mentioned it before, but I wish there was a middle ground where the GUI calls were abstracted enough to make these kinds of version/fork specific approaches unnecessary.

A possibly solution would be to standardize around the tcl messages that vanilla already uses and provide a way to help parse and translate them into whatever is being used by the GUI implementation. “Draw a box here” and “draw some text”, “draw a line from this point to another point”, and “open this window” are all actions possible in tons of languages and environments, just done in a different syntax. Yeah, it’s probably not super efficient but this mechanism seems to have worked pretty well over the years on older, slower hardware to I’m in favor of proposing sticking to what works as a start.

My thought is if we could standardize some of the api interfaces and allow others to be overridable (say the undo/redo mechanisms in a separate .c file) or via default dummy implementations, vanilla/libpd could be uses as the lingua franca core and each variant of Pd adds on it’s extras without diverging.

I *really* hope we can talk about this idea in person at the pd con as I still feel that, overall, we should find a way to pool resources more effectively. For instance, Miller keeps the pd core solid & provides a Pd vanilla GUI while pd-l2ork & purr data have their extensions, expanded internals by overriding/extending aspects of the core, and custom GUI implementations. All of this, hopefully, wrapped upon the same core. I think it’s possible, we just have to figure out what kind of architecture would make this possible. Some of this would probably be possible by simply splitting some functions into separate .c files.

Forgive me if this has already been talked to death, but I have a feeling it hasn’t so far...

Relatedly, I’d like to be able to add an editing GUI to PdParty and have thoughts on making a console-based ncurses GUI for pd. That would be alot easier with the knowledge and help of those of you to wrap the GUI comm via a libpd api instead of me basically reverse engineering things myself. I’d rather be lazy and use the shared knowledge that is one of the best parts about open source.