I have long been expecting that the appearance of libpd would motivate a general refactoring of Pd that untangles the audio engine from other components, such as user interface and audio drivers. I consider such a refactoring a prerequisite for future maintenance and development, but I always assumed that it would have a new audio library at its core, and that this new library would eventually replace libpd.
Recent developments around libpd, however, have me wondering whether this refactoring of Pd might involve libpd itself. To wit, Dan Wilcox recently posted PdParty, a partial iOS port of the Pd GUI that’s based on libpd. PdParty follows in the footsteps of Chris McCormick’s PdDroidParty, which provides a partial Android port of the Pd GUI.
For the time being, neither PdDroidParty nor PdParty will let you create or edit patches. I suspect that libpd in its current form is not general enough to support the full functionality of the Pd GUI, but I don’t think it would take much work to retrofit libpd for this purpose.
So, given these developments, I see a new transition path to a general overhaul of Pd:
- Expand the libpd API to support the needs of the GUI.
- Build a new GUI on top of libpd.
- Retire the old GUI and revise the original core of Pd to remove everything that’s not immediately related to audio processing.
This seems like a realistic approach. It will allow for a smooth transition because the current version and the new version will peacefully coexist on top of the same core functionality. Every step will be a modification of components that already exist, and developers won’t have to learn a whole new API. Besides, it’s already happening.