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
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
|
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="generator" content="Docutils 0.3.1: http://docutils.sourceforge.net/" />
<title>RRADical Pd</title>
<meta name="author" content="Frank Barknecht <fbar@footils.org>" />
<link rel="stylesheet" href="default.css" type="text/css" />
</head>
<body>
<div class="document" id="rradical-pd">
<h1 class="title">RRADical Pd</h1>
<table class="docinfo" frame="void" rules="none">
<col class="docinfo-name" />
<col class="docinfo-content" />
<tbody valign="top">
<tr><th class="docinfo-name">Author:</th>
<td>Frank Barknecht <fbar@footils.org></td></tr>
</tbody>
</table>
<div class="abstract topic">
<p class="topic-title">Abstract</p>
<p>RRADical Pd is a project to create a collection of Pd patches, that make
Pd easier and faster to use for people who are more comfortable with
commercial software like Reason(tm) or Reaktor(tm). RRAD as an acronym
stands for "Reusable and Rapid Audio Development" or "Reusable and Rapid
Application Development", if it includes non-audio patches, with Pd. In
the design of this system, a way to save state flexibly in Pd
(persistence) had to be developed. For communication among each other
the RRADical patches integrates the Open Sound Control protocol.</p>
</div>
<div class="section" id="what-it-takes-to-be-a-rradical">
<h1><a name="what-it-takes-to-be-a-rradical">What it takes to be a RRADical</a></h1>
<p>RRAD as an acronym stands for "Reusable and Rapid Audio Development" or
"Reusable and Rapid Application Development", if it includes non-audio
patches, with Pd. It is spelled RRAD, but pronounced "Rradical" with a
long rolling "R".</p>
<p>The goal of RRADical Pd is to create a collection of patches, that make Pd
easier and faster to use for people who are more used to software like
Reason(tm) or Reaktor(tm). For that I would like to create patches, that
solve real-world problems on a higher level of abstraction than the standard
Pd objects do. Where suitable these high level abstractions should have a
graphical user interface (GUI) built in. As I am focused on sound production
the currently available RRADical patches mirror my preferences and mainly
deal with audio, although the basic concepts would apply for graphics and
video work using for example the Gem and PDP extensions as well.</p>
<p>Pre-fabricated high-level abstractions may not only make Pd easier to use
for beginners, they also can spare lot of tedious, repeating patching work.
For example building a filter using the <tt class="literal"><span class="pre">lop~</span></tt> object of Pd usually
involves some way of changing the cutoff frequency of the filter. So another
object, maybe a slider, will have to be created and connected to the
<tt class="literal"><span class="pre">lop~</span></tt>. The typing and connecting work has to be done almost every time a
filter is used. But the connections between the filter's cutoff control and
the filter can also be done in advance inside of a so called abstraction,
that is, in a saved Pd patch file. Thanks to the Graph-On-Parent feature of
Pd the cutoff slider even can be made visible when using that abstraction in
another patch. The new filter abstraction now carries its own GUI and is
immediatly ready to be used.</p>
<p>Of course the GUI-filter is a rather simple example (although already quite
useful). But building a graphical note sequencer with 32 sliders and 32
number boxes or even more is something, one would rather have to do only
once, and then reuse in a lot of patches.</p>
</div>
<div class="section" id="problems-and-solutions">
<h1><a name="problems-and-solutions">Problems and Solutions</a></h1>
<p>To build above, highly modularized system several problems have to be
solved. Two key areas turned out to be very important:</p>
<dl>
<dt><strong>Persistence</strong></dt>
<dd>How to save the current state of a patch? How to save more than one
state (state sequencing)?</dd>
<dt><strong>Communication</strong></dt>
<dd>The various modules are building blocks for a larger application. How
should they talk to each other. (In Reason this is done by patching the
back or modules with horrible looking cables. We must do better.)</dd>
</dl>
<p>It turned out, that both tasks are possible to solve in a consistent way
using a unique abstraction. But first lets look a bit deeper at the
problems at hand.</p>
<div class="section" id="persistence">
<h2><a name="persistence">Persistence</a></h2>
<p>Pd offers no direct way to store the current state of a patch. Here's what
Pd author Miller S. Puckette writes about this in the Pd manual in section
"2.6.2. persistence of data":</p>
<blockquote>
Among the design principles of Pd is that patches should be printable,
in the sense that the appearance of a patch should fully determine its
functionality. For this reason, if messages received by an object
change its action, since the changes aren't reflected in the object's
appearance, they are not saved as part of the file which specifies the
patch and will be forgotten when the patch is reloaded.</blockquote>
<p>(I'll show an example of a float object changing "state" by a message in
its right inlet here.)</p>
<p>Still, in a musician's practice some kind of persistence turns out to be an
important feature, that many Pd beginners do miss. And as soon as patched
start to use lots of graphical control objects, users will - and should -
play around with different settings until they find some combination they
like. But unless a way to save this combination for later use is found, all
this is temporary and gone, as soon as the patch is closed.</p>
<p>There are several approaches to add persistence. Max/MSP has the
<tt class="literal"><span class="pre">preset</span></tt>-object, Pd provides the similar <tt class="literal"><span class="pre">state</span></tt>-object which saves the
current state of (some) GUI objects inside a patch. Both objects also
support changing between several different states.</p>
<p>But both also have at least two problems: They only save the state of GUI
objects, which might not be everything that a user wants to save. And they
don't handle abstractions very well, which are crucial when creating
modularized patches.</p>
<p>Another approach is to (ab)use some of the Pd objects that can persist
itself to a file, especially <tt class="literal"><span class="pre">textfile</span></tt>, <tt class="literal"><span class="pre">qlist</span></tt> and <tt class="literal"><span class="pre">table</span></tt>, which
works better, but isn't standardized.</p>
<p>A rather new candidate for state saving is Thomas Grill's <tt class="literal"><span class="pre">pool</span></tt> external.
Basically it offers something, that is standard in many programming
languages: a data structure that stores key-value-pairs. This structure also
is known as hash, dictionary or map. With <tt class="literal"><span class="pre">pool</span></tt> those pairs also can be
stored in hierarchies and they can be saved to or loaded from disk. The last
but maybe most important feature for us is, that several pools can be shared
by giving them the same name. A <tt class="literal"><span class="pre">pool</span> <span class="pre">MYPOOL</span></tt> in one patch will contain
the same data as a <tt class="literal"><span class="pre">pool</span> <span class="pre">MYPOOL</span></tt> in another patch. Changes to one pool
will change the data in the other as well. This allows us to use <tt class="literal"><span class="pre">pool</span>
<span class="pre">MYPOOL</span></tt>s inside of abstractions, and still access the pool from modules
outside the abstractions, for example for saving the <tt class="literal"><span class="pre">pool</span></tt> to disk.</p>
<p>A <tt class="literal"><span class="pre">pool</span></tt> object is central to the persistence in RRADical patches, but it
is hidden behind an abstracted "API", if one could name it that. I'll
come back to how this is done below.</p>
</div>
<div class="section" id="communication">
<h2><a name="communication">Communication</a></h2>
<p>Besides persistence it also is important to create a common path through
which the RRADical modules will talk to each other. Generally the modules
will have to use, what Pd offers them, and that is either a direct
connection through patch cords or the indirect use of the send/receive
mechanism in Pd. Patch cords are fine, but tend to clutter the interface.
Sends and receives on the other hand will have to make sure, that no name
clashes occur. A name clash is, when one target receives messages not
intended for it. A patch author has to remember all used send-names, which
might be possible, if he did write the whole patch himself and kept track of
the send-names used. But this gets harder to impossible, if he uses
prefabricated modules, which might use their own senders, maybe hidden deep
inside of the module.</p>
<p>So it is crucial, that senders in RRADical abstractions use local names only
with as few exceptions as possible. This is achieved by prepending the
RRADical senders with the string "$0-". So instead of a sender named <tt class="literal"><span class="pre">send</span>
<span class="pre">volume</span></tt>, instead one called <tt class="literal"><span class="pre">send</span> <span class="pre">$0-volume</span></tt> is used. $0 makes those
sends local inside their own patch borders by being replaced with a number
unique to that patch. Using $0 that way is a pretty standard idiom in the Pd
world.</p>
<p>Still we will want to control a lot of parameters and do so not only through
the GUI elements Pd offers, but probably also through other ways, for
example through hardware Midi controllers, through some kind of score on
disk, through satellite navigation receivers or whatever.</p>
<p>This creates a fundamental conflict:</p>
<dl>
<dt><strong>We want borders</strong> </dt>
<dd>We want to separate our abstraction so they don't conflict with each
other.</dd>
<dt><strong>We want border crossings</strong></dt>
<dd>We want to have a way to reach their many internals and control them
from the outside.</dd>
</dl>
<p>The RRADical approach solves both requirements in that it enforces a strict
border around abstractions but drills a single hole in it: the <strong>OSC
inlet</strong>. This idea is the result of a discussion on the Pd mailing list and
goes back to suggestions by <a class="reference" href="http://www.audionerd.com">Eric Skogen</a> and <a class="reference" href="http://www.ekran.org/ben/">Ben Bogart</a>. Every RRADical
patch has (to have) a rightmost inlet that accepts messages formatted
according to the OSC protocol. OSC stands for <a class="reference" href="http://www.cnmat.berkeley.edu/OpenSoundControl/">Open Sound Control</a> and is a
network transparent system to control (audio) applications remotely and is
developed at CNMAT in Berkley by Matt Wright mainly.</p>
<p>The nice thing about OSC is that it can control many parameters over a
single communication path (like a network conneciton using a definite port).
For this OSC uses a URL-like scheme to address parameters organized in a
tree. An example would be this message:</p>
<pre class="literal-block">
/synth/fm/volume 85
</pre>
<p>It sends the message "85" to the "volume" control of a "fm" module below a
"synth" module. OSC allows many parameters constructs like:</p>
<pre class="literal-block">
/synth/fm/basenote 52
/synth/virtualanalog/basenote 40
/synth/*/playchords m7b5 M6 7b9
</pre>
<p>This might set the base note of two synths, <cite>fm</cite> and <cite>virtualanalog</cite> and
send a chord progression to be played by both -- indicated by the wildcard
<cite>*</cite> -- afterwards.</p>
<p>The OSC-inlet of every RRADical patch is intended as the border crossing:
Everything the author of a certain patch intends to be controlled from the
outside can be controlled by OSC messages to the OSC-inlet. The OSC-inlet is
strongly recommended to be the rightmost inlet of an abstraction. At least
all of my RRADical patches do it this way.</p>
</div>
</div>
<div class="section" id="trying-to-remember-it-all-memento">
<h1><a name="trying-to-remember-it-all-memento">Trying to remember it all: Memento</a></h1>
<p>To realize the functionality requirements laid out so far I resorted to a so
called <cite>Memento</cite>. <cite>"Memento"</cite> is a very cool movie by director Christopher
Nolan where - quoting IMDB:</p>
<blockquote>
A man, suffering from short-term memory loss, uses notes and tattoos to
hunt down his wife's killer.</blockquote>
<p>Here's a scene from "Memento":</p>
<p><img alt="memento.png" src="memento.png" /></p>
<p>The movie's main character Leonard has a similar problem as Pd: he cannot
remember things. To deal with his persistence problem, his inability to save
data to his internal harddisk (brain) he resorts to taking a lot of photos.
These pictures act as what is called a Memento: a recording of the current
state of things.</p>
<p>In software development Mementos are quite common as well. The computer
science literature describes them in great detail, for example in the
Gang-Of-Four book "Design Patterns" <a class="citation-reference" href="#gamma95" id="id1" name="id1">[Gamma95]</a>. To make the best use of
a Memento science recommends an approach where certain tasks are in the
responsibility of certain independent players.</p>
<table class="citation" frame="void" id="gamma95" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<col />
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id1" name="gamma95">[Gamma95]</a></td><td>E. Gamma and R. Helm and R. Johnson and J. Vlissides: "Design
Patterns: Elements of Reusable Object-Oriented Software" Addison-Wesley 1995</td></tr>
</tbody>
</table>
<p>The Memento itself, as we have seen, is the photo, i.e. some kind of state
record. A module called the "Originator" is responsible for creating this
state and managing changes in it. In the movie, Leonard is the Originator,
he is the one taking photos of the world he is soon to forget.</p>
<p>The actual persistence, that could be the saving of a state to harddisk,
but could just as well be an upload to a webserver or a CVS check-in, is
done by someone called the "Caretaker" in the literature. A Caretaker could
be a safe, where Leonard puts his photos, or could be a person, to whom
Leonard gives his photos. In the movie Leonard also makes "hard saves" by
tattooing himself with notes he took. In that case, he is not only the
Originator of the notes, but also the Caretaker in one single person. The
Caretaker only has to take care, that those photos, the Mementos, are in a
safe place and no one fiddles around with them. Btw: In the movie some
interesting problems with Caretakers, who don't always act responsible,
occur.</p>
<div class="section" id="memento-in-pd">
<h2><a name="memento-in-pd">Memento in Pd</a></h2>
<p>I developed a set of abstractions, of patches for Pd, that follow this
design pattern. Memento for Pd includes a <tt class="literal"><span class="pre">caretaker</span></tt> and an
<tt class="literal"><span class="pre">originator</span></tt> abstraction, plus a third one called <tt class="literal"><span class="pre">commun</span></tt> which is
responsible for the <strong>internal</strong> communication. <tt class="literal"><span class="pre">commun</span></tt> basically is
just a thin extension of <tt class="literal"><span class="pre">originator</span></tt> and should be considered part of
it. There is another patch, the <tt class="literal"><span class="pre">careGUI</span></tt> which I personally use instead
of the <tt class="literal"><span class="pre">caretaker</span></tt> directly, because it has a simple GUI included.</p>
<p>Here's how it looks:</p>
<p><img alt="caregui.png" src="caregui.png" /></p>
<p>The <tt class="literal"><span class="pre">careGUI</span></tt> is very simple: select a FILE-name to save to, then
clicking SAVE you can save the current state, with RESTORE you can restore
a state previously saved. After restore, the outlet of <tt class="literal"><span class="pre">careGUI</span></tt> sends a
<tt class="literal"><span class="pre">bang</span></tt> message to be used as you like.</p>
<p>Internally <tt class="literal"><span class="pre">caretaker</span></tt> has a named <tt class="literal"><span class="pre">pool</span></tt> object using the global pool
called "RRADICAL". The same <tt class="literal"><span class="pre">pool</span> <span class="pre">RRADICAL</span></tt> also is used inside the
<tt class="literal"><span class="pre">originator</span></tt> object. This abstraction handles all access to this pool. A
user should not read or write the contents of <tt class="literal"><span class="pre">pool</span> <span class="pre">RRADICAL</span></tt> directly.
The <tt class="literal"><span class="pre">originator</span></tt> patch also handles the border crossing through OSC
messages by it's rightmost inlet. The patch accepts two mandatory
arguments: The first on is the name under which this patch is to be stored
inside the <tt class="literal"><span class="pre">pool</span></tt> data. Each <tt class="literal"><span class="pre">originator</span> <span class="pre">SomeName</span> <span class="pre">secondarg</span></tt> stores
it's data in a virtual subdirectory inside the RRADICAL-pool called like
its first argument - SomeName in the example. If the SomeName starts with a
slash like "/patch" , you can also access it via OSC through the rightmost inlet of
<tt class="literal"><span class="pre">originator</span></tt> under the tree "/patch"</p>
<p>The second argument practically always will be $0. It is used to talk to
those <tt class="literal"><span class="pre">commun</span></tt> objects which share the same second argument. As $0 is a
value local and unique to a patch (or to an abstraction to be correct) each
<tt class="literal"><span class="pre">originator</span></tt> then only can talk to <tt class="literal"><span class="pre">commun</span></tt>s inside the same patch and
will not disturb other <tt class="literal"><span class="pre">commun</span></tt> objects in other abstractions.</p>
<p>The <tt class="literal"><span class="pre">commun</span></tt> objects finally are where the contents of a state are read
and set. They, too, accept two arguments, the second of which was
discussed before and will most of the time just be $0. The first argument
will be the key under which some value will be saved. You should use a slash
as first character here as well to allow OSC control. So an example for a
usage would be <tt class="literal"><span class="pre">commun</span> <span class="pre">/vol</span> <span class="pre">$0</span></tt>.</p>
<p><tt class="literal"><span class="pre">commun</span></tt> has one inlet and one outlet. What comes in through the inlet is
send to <tt class="literal"><span class="pre">originator</span></tt> who stores it inside its Memento under the key, that
is specified by the <tt class="literal"><span class="pre">commun</span></tt>'s first arg. Actually <tt class="literal"><span class="pre">originator</span></tt>. The
outlet of a <tt class="literal"><span class="pre">commun</span></tt> will spit out the current value stored under its key
inside the Memento, when <tt class="literal"><span class="pre">originator</span></tt> tells it to do so. So <tt class="literal"><span class="pre">commun</span></tt>s
are intended to be cross-connected to some thing that can change. And
example would be a slider which can be connected as seen in the next
picture:</p>
<p><img alt="communslider.png" src="communslider.png" /></p>
<p>In this patch, every change to the slider will be reflected inside the
Memento. The little print button in <tt class="literal"><span class="pre">careGUI</span></tt> can be used to print the
contents to the console from which Pd was started. Setting the slider will
result in something like this:</p>
<pre class="literal-block">
/mypatch 0 , /volume , 38
</pre>
<p>Here a comma separates key and value pairs. "mypatch" is the top-level
directory. This contains a 0, which is the default subdirectory, after that
comes the key "/volume", whose value is 38. Let's add another slider for
pan-values:</p>
<p><img alt="moresliders.png" src="moresliders.png" /></p>
<p>Moving the /pan slider will let careGUI print out:</p>
<pre class="literal-block">
/mypatch 0 , /volume , 38
/mypatch 0 , /pan , 92
</pre>
<p>The <tt class="literal"><span class="pre">originator</span></tt> can save several substates or presets by sending a
<tt class="literal"><span class="pre">substate</span> <span class="pre">#number</span></tt> message to its first inlet. Let's do just this and
move the sliders again as seen in the next picture:</p>
<p><img alt="substates.png" src="substates.png" /></p>
<p>Now careGUI prints:</p>
<pre class="literal-block">
/mypatch 0 , /volume , 38
/mypatch 0 , /pan , 92
/mypatch 1 , /volume , 116
/mypatch 1 , /pan , 27
</pre>
<p>You see, the substate 0 is unaffected, the new state can have different
values. Exchanging the <tt class="literal"><span class="pre">substate</span></tt> message with a <tt class="literal"><span class="pre">setsub</span></tt> message will
autoload the selected state and "set" the sliders to the stored values
immediately.</p>
</div>
<div class="section" id="osc-in-memento">
<h2><a name="osc-in-memento">OSC in Memento</a></h2>
<p>The whole system now already is prepared to be used over OSC. You probably
already guess, how the message looks like. Any takers? Thank you, you're
right, the messages are built as <tt class="literal"><span class="pre">/mypatch/volume</span> <span class="pre">#number</span></tt> and
<tt class="literal"><span class="pre">/mypatch/pan</span> <span class="pre">#number</span></tt> as shown in the next stage:</p>
<p><img alt="osccontrol.png" src="osccontrol.png" /></p>
<p>Sometimes it is useful to also get OSC messages out of a patch, for example
to control other OSC software through Pd. For this the <strong>OSC-outlet</strong> of
<tt class="literal"><span class="pre">originator</span></tt> can be used, which is the rightmost outlet of the
abstraction. It will print out every change to the current state.
Connecting a <tt class="literal"><span class="pre">print</span> <span class="pre">OSC</span></tt> debug object to it, we get to see what's coming
out of the OSC-outlet when we move a slider:</p>
<pre class="literal-block">
OSC: /mypatch/pan 92
OSC: /mypatch/pan 91
OSC: /mypatch/pan 90
OSC: /mypatch/pan 89
</pre>
</div>
</div>
<div class="section" id="putting-it-all-to-rradical-use">
<h1><a name="putting-it-all-to-rradical-use">Putting it all to RRADical use</a></h1>
<p>Now that the foundation for a general preset and communication system are
set, it is possible to build real patches with it that have two main
characteristics:</p>
<dl>
<dt><strong>Rapidity</strong></dt>
<dd>Ready-to-use high-level abstraction can save a lot of time when building
larger patches. Clear communication paths will let you think faster and
more about the really important things.</dd>
<dt><strong>Reusability</strong></dt>
<dd>Don't reinvent the wheel all the time. Reuse patches like instruments
for more than one piece by just exchanging the Caretaker-file used.</dd>
</dl>
<p>I already developed a growing number of patches that follow the RRADical
paradigm, among these are a complex pattern sequencer, some synths and
effects and more. All those are available in the Pure data CVS, which
currently lives at <a class="reference" href="http://pure-data.sourceforge.net">pure-data.sourceforge.net</a> in the directory
"abstractions/rradical".
The RRADical collection comes with a template file, called
<tt class="literal"><span class="pre">rrad.tpl.pd</span></tt> that makes deploying new RRADical patches easier and lets
developers concentrate on the algorithm instead of bookkeeping. Some
utilities help with creating the sometimes needed many <tt class="literal"><span class="pre">commun</span></tt>-objects.
Several usecases show example applications of the provided abstractions.</p>
</div>
<div class="section" id="much-but-not-all-is-well-yet">
<h1><a name="much-but-not-all-is-well-yet">Much, but not all is well yet</a></h1>
<p>Developing patches using the Memento system and the design guidelines
presented has made quite an impact on how my patches are designed. Before
Memento quite a bit of my patches' content dealed with saving state in
various, crude and non-unified ways. I even tried to avoid saving states at
all because it always seemed to be too complicated to bother with it. This
limited my patches to being used in improvisational pieces without the
possibility to prepare parts of a musical story in advance and to "design"
those pieces. It was like being forced to write a book without having access
to a sheet of paper (or a harddisk nowadays). This has change: having
"paper" in great supply now has made it possible to "write" pieces of art,
to "remember" what was good and what rather should not be repeated, to
really "work" on a certain project over a longer time.</p>
<p>RRADical patches also have proven to be useful tools in teaching Pure Data,
which is important as usage of Pd in workshops and at universities is
growing -- also thanks to its availability as Free Software. RRADical
patches directly can be used by novices as they are created just like any
other patch, but they already provide sound creation and GUI elements that
the students can use immediatly to create more satisfactory sounds that the
sine waves used as standard examples in basic Pd tutorials. With a grown
proficiency the students later can dive into the internals of a RRADical
patch to see what's inside and how it was done. This allows a new top-down
approach in teaching Pd which is a great complement (or even alternative) to
the traditional, bottom-up way.</p>
<p>Still the patches suffer from a known technical problem of Pd. Several of
the RRADical patches make heavy use of graphical modules like sliders or
number boxes, and they create a rather high number of messages to be send
inside of Pd. The message count is alleviated a bit by using OSC, but the
graphical load is so high, that Pd's audio computation can be disturbed, if
too many GUI modules need updating at the same time. This can lead to
dropouts and clicks in the audio stream, which is of course not acceptable.</p>
<p>The problem is due to the non-sufficient decoupling of audio and graphics
rsp. message computations in Pd, a technical issue that is known, but a
solution to my knowledge could require a lot of changes to Pd's core system.
Several developers already are working on this problem, though.</p>
<p>The consistent usage of OSC throughout the RRADical patches created another
interesting possibility, that of collaboration. As every RRADcial patch not
only can be controlled through OSC, but also can control another patch of
its own kind, the same patch could be used on two or more machines, and
every change on one machine would propagate to all other machines where that
same patch is running. So jamming together and even the concept of a "Pd
band" is naturally build into every RRADcial patch.</p>
</div>
</div>
</body>
</html>
|
