Pure Data, Android audio, and random stuff

Noisepages: Websites for smart artists.

Refactoring Pure Data

by Peter Brinkmann

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.

6

6 Responses

  1. Pawel Cyrta

    I would recommend to make GUI in HTML and Javascript + controller module as native.
    Then, controler module will manage prezentation layer and communication with libpd. 
    On desktop one can use QT 4.8+ and QWebkit to show prezentation gui (html+js).
    I’ve recently tested QT as a mobile/desktop platform as a alternative to PhoneGap and Titanium. It works great. Although there is one difference. You have to program JSC++ interface on your own, but I consider this as prons.

  2. Krzysztof

    Hi Peter, nice blog! You seem to envisage editor API as part of libpd.
    Wouldn’t you consider encapsulating it in a separate library?

    Thinking about overall redesign (this is not directly related to
    editor API): I wonder whether you agree with Hans and Johannes about
    the need to replace the current low-level, graphics oriented
    coregui protocol with something higher-level, and, as a consequence, handling two
    synchronized copies of patch definition?

    @Paweł: cześć… looking for ways of making pd core toolkit-agnostic
    is probably better in the long run (avoiding the “zamienił stryjek
    siekierkę na kijek” danger).

  3. Peter Brinkmann

    @Krzysztof: I totally agree with Hans and IOhannes that the new GUI will maintain its own copy of the patch.

    About a separate library for editing patches, I don’t think that’s necessary or even desirable. Most of the editing functionality can be expressed in terms of the existing message passing/array access API of libpd. I wouldn’t be surprised if that turned out to be enough for editing patches. If it’s not enough, then I expect that can be remedied by adding a smallish collection of callback hooks to libpd.

    Moreover, because of the possibility of dynamic patching, editing a patch and executing a patch are basically the same operation. Since libpd is for running patches, it’s for editing, too.

    @Pawel: I agree with Krzysztof; I’m mostly looking at the implications for libpd, and that is independent of the GUI toolkit. I expect that we’ll see several GUI implementations, and I’m sure that one of them will use HTML and JavaScript. Chris McCormick’s PdWebKitDroid already gives a glimpse of this.

  4. Alexander

    So where do the externals and pd-extended come in to this?
    How will things like GEM fit in to this picture?
    (you appear to underline the audio processing in this post)

  5. Peter Brinkmann

    Externals generally work fine with libpd; that should include GEM (at least on platforms where GEM is currently available; I’m not sure how much work it would take to get it to work on Android or iOS). The one exception is externals that use the sys_lock and sys_unlock calls from m_pd.h because they aren’t a good fit for the synchronization needs of most libpd-based apps.

    I did a brief audit of pd-extended before deciding to not to support sys_lock/sys_unlock, and I recall that I only found one external that actually uses them.

    So, the upshot is, virtually all of pd-extended will still work after the refactoring discussed here.

  6. Andrei Petrovici

    Finding pd core will be a real challenge…:)

Leave a Reply