1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
|
%---------------------------------------------------
\chapter{Architecture files} \label{sec:audio}
%---------------------------------------------------
A \faust program describes a \emph{signal processor}, a pure computation that maps \emph{input signals} to \emph{output signals}. It says nothing about audio drivers or GUI toolkits. This missing information is provided by \emph{architecture files}.
%The role of \emph{architecture files} is to provide this missing information.
An \emph{architecture file} describes how to relate a \faust program to the external world, in particular the audio drivers and the user interface to be used. This approach allows a single \faust program to be easily deployed to a large variety of audio standards (Max/MSP externals, PD externals, VST plugins, CoreAudio applications, Jack applications, iPhone, etc.).
The architecture to be used is specified at compile time with the \lstinline'-a' options. For example
\lstinline'faust -a jack-gtk.cpp foo.dsp' indicates to use the Jack GTK architecture when compiling \code{foo.dsp}.
\begin{table}[htp]
\begin{center}
\begin{tabular}{|l|l|l|}
\hline
\textbf{File name} & \textbf{Description} \\
\hline
\texttt{alchemy-as.cpp} & Flash - ActionScript plugin \\
\texttt{ca-qt.cpp} & CoreAudio QT4 standalone application \\
\texttt{jack-gtk.cpp} & Jack GTK standalone application \\
\texttt{jack-qt.cpp} & Jack QT4 standalone application \\
\texttt{jack-console.cpp} & Jack command line application \\
\texttt{jack-internal.cpp} & Jack server plugin \\
%%\texttt{jack-wx.cpp} & Jack wxWindows standalone application \\
\texttt{alsa-gtk.cpp} & ALSA GTK standalone application \\
\texttt{alsa-qt.cpp} & ALSA QT4 standalone application \\
\texttt{oss-gtk.cpp} & OSS GTK standalone application \\
%%\texttt{oss-wx.cpp} & OSS wxWindows standalone application \\
\texttt{pa-gtk.cpp} & PortAudio GTK standalone application \\
\texttt{pa-qt.cpp} & PortAudio QT4 standalone application \\
%%\texttt{pa-wx.cpp} & PortAudio wxWindows standalone application \\
\hline
\texttt{max-msp.cpp} & Max/MSP external \\
\texttt{vst.cpp} & VST plugin \\
\texttt{vst2p4.cpp} & VST 2.4 plugin \\
\texttt{vsti-mono.cpp} & VSTi mono instrument \\
\texttt{vsti-poly.cpp} & VSTi polyphonic instrument \\
\texttt{ladspa.cpp} & LADSPA plugin \\
\texttt{q.cpp} & Q language plugin \\
\texttt{supercollider.cpp} & SuperCollider Unit Generator \\
\texttt{snd-rt-gtk.cpp} & Snd-RT music programming language \\
\texttt{csound.cpp} & CSOUND opcode \\
\texttt{puredata.cpp} & PD external \\
\hline
\texttt{sndfile.cpp} & sound file transformation command \\
\texttt{bench.cpp} & speed benchmark \\
\texttt{octave.cpp} & Octave plugin \\
\texttt{plot.cpp} & Command line application \\
\texttt{sndfile.cpp} & Command line application \\
\hline
\end{tabular}
\end{center}
\caption{Available architectures.}
\label{tab:availablearch}
\end{table}%
The main available architecture files are listed table \ref{tab:availablearch}. Since \faust 0.9.40 some of these architectures are a modular combination of an \emph{audio module} and one or more \emph{user interface modules}. Among these user interface modules OSCUI provide supports for Open Sound Control allowing \faust programs to be controlled by OSC messages.
\section{Audio architecture modules}
An \emph{audio architecture module} typically connects a \faust program to the audio drivers.
It is responsible for allocating and releasing the audio channels and for calling the \faust \code{dsp::compute} method to handle incoming audio buffers and/or to produce audio output. It is also responsible for presenting the audio as non-interleaved float data, normalized between -1.0 and 1.0.
A \faust audio architecture module derives an \emph{audio} class defined as below:
\begin{lstlisting}[basicstyle=\ttfamily\footnotesize\color{yotxt}]
class audio {
public:
audio() {}
virtual ~audio() {}
virtual bool init(const char*, dsp*) = 0;
virtual bool start() = 0;
virtual void stop() = 0;
};
\end{lstlisting}
The API is simple enough to give a great flexibility to audio architectures implementations. The \code{init} method should initialize the audio. At \code{init} exit, the system should be in a safe state to recall the \code{dsp} object state.
Table \ref{tab:aarch} gives the audio architectures currently available for various operating systems.
\begin{table}[htp]
\begin{center}
\begin{tabular}{|c|c|}
\hline
\bf{Audio system} & \bf{Operating system} \\
\hline
Alsa & Linux \\
Core audio & Mac OS X, iOS \\
Jack & Linux, Mac OS X, Windows \\
Portaudio & Linux, Mac OS X, Windows \\
OSC & Linux, Mac OS X, Windows \\
VST & Mac OS X, Windows \\
Max/MSP & Mac OS X, Windows \\
CSound & Linux, Mac OS X, Windows \\
SuperCollider & Linux, Mac OS X, Windows \\
PureData & Linux, Mac OS X, Windows \\
Pure & Linux, Mac OS X, Windows \\
\hline
\end{tabular}
\end{center}
\caption{\faust audio architectures.}
\label{tab:aarch}
\end{table}%
% \begin{table}[htp]
% \begin{center}
% \begin{tabular}{|c|l|}
% \hline
% Name & System \\
% \hline
% ladspa & \href{http://www.ladspa.org/}{LADSPA} plugins \\
% csound & \href{http://csounds.com/}{CSOUND} opcodes \\
% csounddouble & double precision CSOUND opcodes \\
% maxmsp & \href{http://cycling74.com/products/maxmspjitter/}{Max/MSP} externals \\
% vst & native \href{http://en.wikipedia.org/wiki/Virtual_Studio_Technology}{VST} plugins \\
% w32vst & windows VST plugins \\
% supercollider & \href{http://www.audiosynth.com/}{Supercollider} plugins \\
% puredata & \href{http://puredata.info/}{Puredata} externals \\
% Q & \href{http://q-lang.sourceforge.net/}{Q} plugins \\
% Pure & \href{http://code.google.com/p/pure-lang/}{Pure} plugins \\
% \hline
% \end{tabular}
% \end{center}
% \caption{\faust plugins architectures}
% \label{tab:aarch}
% \end{table}%
%
%---------------------------------------------------
\section{UI architecture modules} \label{sec:gui}
%---------------------------------------------------
A UI architecture module links user actions (via graphic widgets, command line parameters, OSC messages, etc.) with the \faust program to control.
It is responsible for associating program parameters to user interface elements and to update parameter's values according to user actions. This association is triggered by the \code{dsp::buildUserInterface} call, where the \code{dsp} asks a UI object to build the DSP module controllers.
Since the interface is basically graphic oriented, the main concepts are \emph{widget} based: a UI architecture module is semantically oriented to handle active widgets, passive widgets and widgets layout.
A \faust UI architecture module derives an \emph{UI} class (Figure \ref{tab:ui}).
\begin{figure}[htp]
\begin{center}
%\begin{lstlisting}[basicstyle=\ttfamily\tiny\color{yotxt}]
\begin{lstlisting}[basicstyle=\ttfamily\footnotesize\color{yotxt}]
class UI
{
public:
UI() {}
virtual ~UI() {}
-- active widgets
virtual void addButton(const char* l, float* z) = 0;
virtual void addCheckButton(const char* l, float* z) = 0;
virtual void addVerticalSlider(const char* l, float* z,
float init, float min, float max, float step) = 0;
virtual void addHorizontalSlider(const char* l, float* z,
float init, float min, float max, float step) = 0;
virtual void addNumEntry(const char* l, float* z,
float init, float min, float max, float step) = 0;
-- passive widgets
virtual void addHorizontalBargraph(const char* l,
float* z, float min, float max) = 0;
virtual void addVerticalBargraph(const char* l,
float* z, float min, float max) = 0;
-- widget layouts
virtual void openTabBox(const char* l) = 0;
virtual void openHorizontalBox(const char* l) = 0;
virtual void openVerticalBox(const char* l) = 0;
virtual void closeBox() = 0;
-- metadata declarations
virtual void declare(float*, const char*, const char* ) {}
};
\end{lstlisting}
\end{center}
\caption{UI, the root user interface class.}
\label{tab:ui}
\end{figure}
%---------------------------------------------------
\subsection{Active widgets}
\label{sec:awidget}
Active widgets are graphical elements that control a parameter value. They are initialized with the widget name and a pointer to the linked value.
The widget currently considered are \code{Button}, \code{CheckButton}, \code{VerticalSlider}, \code{HorizontalSlider} and \code{NumEntry}. \\
A GUI architecture must implement a method \\
\code{addXxx(const char* name, float* zone, ...)} for each active widget.
Additional parameters are available for \code{Slider} and \code{NumEntry}: the \code{init}, \code{min}, \code{max} and \code{step} values.
%---------------------------------------------------
\subsection{Passive widgets}
\label{sec:pwidget}
Passive widgets are graphical elements that reflect values. Similarly to active widgets, they are initialized with the widget name and a pointer to the linked value.
The widget currently considered are \code{HorizontalBarGraph} and \code{VerticalBarGraph}. \\
A UI architecture must implement a method \\
\code{addXxx(const char* name, float* zone, ...)} for each passive widget.
Additional parameters are available, depending on the passive widget type.
%---------------------------------------------------
\subsection{Widgets layout}
\label{sec:wlayout}
Generally, a GUI is hierarchically organized into boxes and/or tab boxes.
A UI architecture must support the following methods to setup this hierarchy : \\
\htab\code{openTabBox(const char* label)} \\
\htab\code{openHorizontalBox(const char* label)} \\
\htab\code{openVerticalBox(const char* label)} \\
\htab\code{closeBox(const char* label)} \\
Note that all the widgets are added to the current box.
%---------------------------------------------------
\subsection{Metadata}
\label{sec:metadata}
The \faust language allows widget labels to contain metadata enclosed in square brackets. These metadata are handled at GUI level by a \code{declare} method taking as argument, a pointer to the widget associated zone, the metadata key and value: \\
\htab\code{declare(float* zone, const char* key, const char* value)} \\
%%Table \ref{tab:uiarch} gives the UI architectures currently available.
\begin{table}[htp]
\begin{center}
\begin{tabular}{|c|l|}
\hline
\bf{UI} & \bf{Comment} \\
\hline
console & a textual command line UI \\
GTK & a GTK-based GUI \\
Qt & a multi-platform Qt-based GUI \\
FUI & a file-based UI to store and recall modules states \\
OSC & OSC control (see \ref{sec:oscgui}) \\
\hline
\end{tabular}
\end{center}
\caption{Available UI architectures.}
\label{tab:uiarch}
\end{table}%
|
