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 , 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.xmlAdding 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 ) to learn more of the features and options of the faust2pd script.
The generated abstraction can be opened in pd as follows:
> pd cpgrui.pdFigure 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.
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