Generating a PD Plugin-Wrapper Abstraction

The test patch of Fig.K.8 was constructed in pd by manually attaching user-interface elements to the left (control) inlet of the plugin. As is well described in [31], one can alternatively use the faust2pd script to generate a pd abstraction containing the plugin and its pd controllers. When this abstraction is loaded into pd, its controllers are brought out to the top level using the ``graph on parent'' mechanism in pd, as shown in Fig.K.10.

The faust2pd script works from the XML file generated by Faust using the -xml option:

  > faust -xml -a puredata.cpp -o cpgrui-pd.cpp cpgrui.dsp
  > faust2pd cpgrui.dsp.xml

Adding the -xml option results in generation of the file cpgrui.dsp.xml which is then used by faust2pd to generate cpgrui.pd. Type faust2pd -h (and read [31]) to learn more of the features and options of the faust2pd script.

The generated abstraction can be opened in pd as follows:

  > pd cpgrui.pd

Figure K.9 shows the result. As indicated by the inlet~ and outlet~ objects, the abstraction is designed to be used in place of the plugin. For this reason, we will refer to it henceforth as a plugin wrapper.

Figure K.9: Pure Data abstraction generated by faust2pd from the XML file emitted by Faust for the constant-peak-gain resonator (cpgrui.dsp).

Notice in Fig.K.9 that a plugin wrapper forwards its control messages (left-inlet messages) to the encapsulated plugin, as we would expect (via faust-control and various route abstractions). However, it also forwards a copy of each control message to its control outlet. This convention facilitates making cascade chains of plugin-wrappers, as illustrated in faust2pd examples such as synth.pd.^K.12