[PD-cvs] abstractions/rradical/doc rradicalpd.html,1.1.1.1,1.2 rradicalpd.pdf,1.1.1.1,1.2 rradicalpd.rst,1.1.1.1,1.2 rradicalpd.tex,1.1.1.1,1.2
Frank Barknecht
fbar at users.sourceforge.net
Sat Jun 26 14:19:49 CEST 2004
Update of /cvsroot/pure-data/abstractions/rradical/doc
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv7316
Modified Files:
rradicalpd.html rradicalpd.pdf rradicalpd.rst rradicalpd.tex
Log Message:
New version.
Index: rradicalpd.html
===================================================================
RCS file: /cvsroot/pure-data/abstractions/rradical/doc/rradicalpd.html,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -C2 -d -r1.1.1.1 -r1.2
*** rradicalpd.html 23 Apr 2004 16:26:02 -0000 1.1.1.1
--- rradicalpd.html 26 Jun 2004 12:19:43 -0000 1.2
***************
*** 22,31 ****
<div class="abstract topic">
<p class="topic-title">Abstract</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 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. It
! is spelled RRAD, but pronounced Rradical. ;)</p>
</div>
<div class="section" id="what-it-takes-to-be-a-rradical">
--- 22,33 ----
<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">
***************
*** 33,64 ****
<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. ;)</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 GUIs
! built in.</p>
! <p>So for example instead of a basic <tt class="literal"><span class="pre">lop~</span></tt> low pass filter something more
! complete like a recreation of the Sherman filter bank could be included in
! that collection. My older sseq and angriff patches followed this idea in
! general, but there are much more patches needed. Like this:</p>
! <ul class="simple">
! <li>a sample player (adapt Gyre?)</li>
! <li>Various OSC/LFO with preset waveforms</li>
! <li>drum machine</li>
! <li>guitar simulator</li>
! <li>grain sample player</li>
! <li>more sequencers</li>
! <li>basically a lot of things like these things in Reason</li>
! </ul>
! <p>Not that I want to make Pd be Reason, no way. But 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.</p>
</div>
<div class="section" id="problems-and-solutions">
<h1><a name="problems-and-solutions">Problems and Solutions</a></h1>
! <p>To building above system several problems are to be solved. Two key areas
! already targetted are:</p>
<dl>
<dt><strong>Persistence</strong></dt>
--- 35,70 ----
<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>
***************
*** 88,118 ****
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. So there are several
! approaches to add it. Max/MSP has the <tt class="literal"><span class="pre">preset</span></tt>-object, Pd has the
! <tt class="literal"><span class="pre">state</span></tt>-object which saves the current state of (some) GUI objects inside
! a patch. Both also support changing between several different states.</p>
! <p>Both have at least two problems: They save only the state of GUI objects,
! which might not be all 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
! also is known as hash, dictonary 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.</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 haw this is done late.</p>
</div>
<div class="section" id="communication">
<h2><a name="communication">Communication</a></h2>
! <p>Besides persistance 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
--- 94,131 ----
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
***************
*** 121,137 ****
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, but
! this gets harder, if he uses prefabricated modules, which might use their
! own senders.</p>
! <p>So it is crucial, that senders in RRADical abstractions use local senders
! only with as few exceptions as possible. This is achieved by prepending the
! RRADical senders with the string "$0-". So you'd not use <tt class="literal"><span class="pre">send</span> <span class="pre">volume</span></tt>,
! but instead use <tt class="literal"><span class="pre">send</span> <span class="pre">$0-volume</span></tt>. $0 makes those sends local inside their
! own patch borders. This might be a bit difficult to understand to the
! casual Pd user, but 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 Pd offers, but probably also through other ways, for
! example through Midi controllers, through some kind of score on disk,
! through satellite navigation receivers or whatever.</p>
<p>This creates a fundamental conflict:</p>
<dl>
--- 134,153 ----
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>
***************
*** 143,156 ****
from the outside.</dd>
</dl>
! <p>The RRADical approach adheres to this in that it enforces a strict border
! 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 developed at CNMAT in Berkley.</p>
<p>The nice thing about OSC is that it can control many parameters over a
! single communication path. This is so, because OSC uses a URL-like scheme
! to address parameters. An example would be this message:</p>
<pre class="literal-block">
/synth/fm/volume 85
--- 159,174 ----
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
***************
*** 168,195 ****
<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 rightmost inlet.</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 developed 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>If you haven't already done so: Watch this movie! It's much better than
- Matrix 2 and 3 and also stars Carrie-Anne "Trinity" Moss.</p>
<p>Here's a scene from "Memento":</p>
<p><img alt="memento.png" src="memento.png" /></p>
! <p>We see the film's main character Leonard who 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 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. To make the best use of
a Memento science recommends an approach where certain tasks are in the
responsibility of certain independent players.</p>
<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
--- 186,222 ----
<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
***************
*** 204,208 ****
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 noone fiddles around with them. Btw: In the movie some
interesting problems with Caretakers, who don't always act responsible,
occur.</p>
--- 231,235 ----
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>
***************
*** 232,236 ****
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 accesse 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
--- 259,263 ----
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
***************
*** 261,265 ****
/mypatch 0 , /volume , 38
</pre>
! <p>Here a comma separates key and value pairs. "mypatch" is the toplevel
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
--- 288,292 ----
/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
***************
*** 285,289 ****
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
! immediatly.</p>
</div>
<div class="section" id="osc-in-memento">
--- 312,316 ----
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">
***************
*** 315,319 ****
<dl>
<dt><strong>Rapidity</strong></dt>
! <dd>Ready-to-use highlevel 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>
--- 342,346 ----
<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>
***************
*** 324,333 ****
<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. The RRADical collection comes with a template file,
! called <tt class="literal"><span class="pre">rrad.tpl</span></tt> that makes deploying new RRADical patches easier and
! lets developers concentrate on the algorighm instead of bookeeping. Some
! utils (footils?) 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>
--- 351,406 ----
<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>
Index: rradicalpd.tex
===================================================================
RCS file: /cvsroot/pure-data/abstractions/rradical/doc/rradicalpd.tex,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -C2 -d -r1.1.1.1 -r1.2
*** rradicalpd.tex 23 Apr 2004 16:26:20 -0000 1.1.1.1
--- rradicalpd.tex 26 Jun 2004 12:19:45 -0000 1.2
***************
*** 61,70 ****
\subsection*{~\hfill Abstract\hfill ~}
! 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 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. It
! is spelled RRAD, but pronounced Rradical. ;)
--- 61,72 ----
\subsection*{~\hfill Abstract\hfill ~}
! 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.
***************
*** 78,121 ****
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. ;)
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 GUIs
! built in.
!
! So for example instead of a basic \texttt{lop{\~{ }}} low pass filter something more
! complete like a recreation of the Sherman filter bank could be included in
! that collection. My older sseq and angriff patches followed this idea in
! general, but there are much more patches needed. Like this:
! \begin{itemize}
! \item
! a sample player (adapt Gyre?)
!
! \item
! Various OSC/LFO with preset waveforms
!
! \item
! drum machine
!
! \item
! guitar simulator
!
! \item
! grain sample player
!
! \item
! more sequencers
!
! \item
! basically a lot of things like these things in Reason
! \end{itemize}
! Not that I want to make Pd be Reason, no way. But 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.
--- 80,113 ----
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''.
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.
! 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 \texttt{lop{\~{ }}} 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
! \texttt{lop{\~{ }}}. 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.
! 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.
***************
*** 126,131 ****
\pdfbookmark[0]{Problems and Solutions}{problems-and-solutions}
! To building above system several problems are to be solved. Two key areas
! already targetted are:
\begin{description}
%[visit_definition_list_item]
--- 118,123 ----
\pdfbookmark[0]{Problems and Solutions}{problems-and-solutions}
! To build above, highly modularized system several problems have to be
! solved. Two key areas turned out to be very important:
\begin{description}
%[visit_definition_list_item]
***************
*** 178,190 ****
Still, in a musician's practice some kind of persistence turns out to be an
! important feature, that many Pd beginners do miss. So there are several
! approaches to add it. Max/MSP has the \texttt{preset}-object, Pd has the
! \texttt{state}-object which saves the current state of (some) GUI objects inside
! a patch. Both also support changing between several different states.
! Both have at least two problems: They save only the state of GUI objects,
! which might not be all that a user wants to save. And they don't handle
! abstractions very well, which are crucial when creating modularized
! patches.
Another approach is to (ab)use some of the Pd objects that can persist
--- 170,188 ----
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.
! There are several approaches to add persistence. Max/MSP has the
! \texttt{preset}-object, Pd provides the similar \texttt{state}-object which saves the
! current state of (some) GUI objects inside a patch. Both objects also
! support changing between several different states.
!
! 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.
Another approach is to (ab)use some of the Pd objects that can persist
***************
*** 192,208 ****
works better, but isn't standardized.
! A rather new candidate for state saving is Thomas Grill's \texttt{pool}
! external. Basically it offers something, that is standard in many
! programming languages: a data structure that stores key-value-pairs. This
! also is known as hash, dictonary or map. With \texttt{pool} 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 \texttt{pool MYPOOL} in one patch will
! contain the same data as a \texttt{pool MYPOOL} in another patch. Changes to one
! pool will change the data in the other as well.
A \texttt{pool} 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 haw this is done late.
--- 190,208 ----
works better, but isn't standardized.
! A rather new candidate for state saving is Thomas Grill's \texttt{pool} 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 \texttt{pool} 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 \texttt{pool MYPOOL} in one patch will contain
! the same data as a \texttt{pool MYPOOL} in another patch. Changes to one pool
! will change the data in the other as well. This allows us to use \texttt{pool
! MYPOOL}s inside of abstractions, and still access the pool from modules
! outside the abstractions, for example for saving the \texttt{pool} to disk.
A \texttt{pool} 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.
***************
*** 213,217 ****
\pdfbookmark[1]{Communication}{communication}
! Besides persistance 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
--- 213,217 ----
\pdfbookmark[1]{Communication}{communication}
! 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
***************
*** 220,238 ****
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, but
! this gets harder, if he uses prefabricated modules, which might use their
! own senders.
! So it is crucial, that senders in RRADical abstractions use local senders
! only with as few exceptions as possible. This is achieved by prepending the
! RRADical senders with the string ``{\$}0-''. So you'd not use \texttt{send volume},
! but instead use \texttt{send {\$}0-volume}. {\$}0 makes those sends local inside their
! own patch borders. This might be a bit difficult to understand to the
! casual Pd user, but is a pretty standard idiom in the Pd world.
! Still we will want to control a lot of parameters and do so not only
! through the GUI Pd offers, but probably also through other ways, for
! example through Midi controllers, through some kind of score on disk,
! through satellite navigation receivers or whatever.
This creates a fundamental conflict:
--- 220,241 ----
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.
! 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 \texttt{send
! volume}, instead one called \texttt{send {\$}0-volume} 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.
! 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.
This creates a fundamental conflict:
***************
*** 258,272 ****
\end{description}
! The RRADical approach adheres to this in that it enforces a strict border
! but drills a single hole in it: the \textbf{OSC inlet}. This idea is the result
! of a discussion on the Pd mailing list and goes back to suggestions by
! \href{http://www.audionerd.com}{Eric Skogen} and \href{http://www.ekran.org/ben/}{Ben Bogart}. Every RRADical patch has (to have) a
! rightmost inlet that accepts messages formatted according to the OSC
! protocol. OSC stands for \href{http://www.cnmat.berkeley.edu/OpenSoundControl/}{Open Sound Control} and is a network transparent
! system to control audio applications remotely developed at CNMAT in Berkley.
The nice thing about OSC is that it can control many parameters over a
! single communication path. This is so, because OSC uses a URL-like scheme
! to address parameters. An example would be this message:
\begin{ttfamily}\begin{flushleft}
\mbox{/synth/fm/volume~85}
--- 261,277 ----
\end{description}
! The RRADical approach solves both requirements in that it enforces a strict
! border around abstractions but drills a single hole in it: the \textbf{OSC
! inlet}. This idea is the result of a discussion on the Pd mailing list and
! goes back to suggestions by \href{http://www.audionerd.com}{Eric Skogen} and \href{http://www.ekran.org/ben/}{Ben Bogart}. Every RRADical
! patch has (to have) a rightmost inlet that accepts messages formatted
! according to the OSC protocol. OSC stands for \href{http://www.cnmat.berkeley.edu/OpenSoundControl/}{Open Sound Control} and is a
! network transparent system to control (audio) applications remotely and is
! developed at CNMAT in Berkley by Matt Wright mainly.
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:
\begin{ttfamily}\begin{flushleft}
\mbox{/synth/fm/volume~85}
***************
*** 287,291 ****
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 rightmost inlet.
--- 292,298 ----
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.
***************
*** 296,302 ****
\pdfbookmark[0]{Trying to remember it all: Memento}{trying-to-remember-it-all-memento}
! To realize the functionality requirements developed so far I resorted to a
! so called Memento. ``Memento'' is a very cool movie by director
! Christopher Nolan where - quoting IMDB:
\begin{quote}
--- 303,309 ----
\pdfbookmark[0]{Trying to remember it all: Memento}{trying-to-remember-it-all-memento}
! To realize the functionality requirements laid out so far I resorted to a so
! called Memento. ``Memento'' is a very cool movie by director Christopher
! Nolan where - quoting IMDB:
\begin{quote}
***************
*** 305,325 ****
\end{quote}
- If you haven't already done so: Watch this movie! It's much better than
- Matrix 2 and 3 and also stars Carrie-Anne ``Trinity'' Moss.
-
Here's a scene from ``Memento'':
\includegraphics{memento.png}
! We see the film's main character Leonard who 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 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.
In software development Mementos are quite common as well. The computer
! science literature describes them in great detail. To make the best use of
a Memento science recommends an approach where certain tasks are in the
responsibility of certain independent players.
The Memento itself, as we have seen, is the photo, i.e. some kind of state
--- 312,334 ----
\end{quote}
Here's a scene from ``Memento'':
\includegraphics{memento.png}
! 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.
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'' [\hyperlink{gamma95}{Gamma95}]. To make the best use of
a Memento science recommends an approach where certain tasks are in the
responsibility of certain independent players.
+ \begin{figure}[b]\hypertarget{gamma95}[Gamma95]
+ E. Gamma and R. Helm and R. Johnson and J. Vlissides: ``Design
+ Patterns: Elements of Reusable Object-Oriented Software'' Addison-Wesley 1995
+ \end{figure}
The Memento itself, as we have seen, is the photo, i.e. some kind of state
***************
*** 336,340 ****
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 noone fiddles around with them. Btw: In the movie some
interesting problems with Caretakers, who don't always act responsible,
occur.
--- 345,349 ----
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.
***************
*** 374,378 ****
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 accesse it via OSC through the rightmost inlet of
\texttt{originator} under the tree ``/patch''
--- 383,387 ----
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
\texttt{originator} under the tree ``/patch''
***************
*** 409,413 ****
\end{flushleft}\end{ttfamily}
! Here a comma separates key and value pairs. ``mypatch'' is the toplevel
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
--- 418,422 ----
\end{flushleft}\end{ttfamily}
! 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
***************
*** 439,443 ****
values. Exchanging the \texttt{substate} message with a \texttt{setsub} message will
autoload the selected state and ``set'' the sliders to the stored values
! immediatly.
--- 448,452 ----
values. Exchanging the \texttt{substate} message with a \texttt{setsub} message will
autoload the selected state and ``set'' the sliders to the stored values
! immediately.
***************
*** 483,487 ****
%[visit_definition]
! Ready-to-use highlevel 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.
--- 492,496 ----
%[visit_definition]
! 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.
***************
*** 502,511 ****
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. The RRADical collection comes with a template file,
! called \texttt{rrad.tpl} that makes deploying new RRADical patches easier and
! lets developers concentrate on the algorighm instead of bookeeping. Some
! utils (footils?) help with creating the sometimes needed many
! \texttt{commun}-objects. Several usecases show example applications of the
! provided abstractions.
\end{document}
--- 511,575 ----
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 \href{http://pure-data.sourceforge.net}{pure-data.sourceforge.net} in the directory
! ``abstractions/rradical''.
! The RRADical collection comes with a template file, called
! \texttt{rrad.tpl.pd} 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 \texttt{commun}-objects.
! Several usecases show example applications of the provided abstractions.
!
!
! %___________________________________________________________________________
!
! \hypertarget{much-but-not-all-is-well-yet}{}
! \section*{Much, but not all is well yet}
! \pdfbookmark[0]{Much, but not all is well yet}{much-but-not-all-is-well-yet}
!
! 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.
!
! 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.
!
! 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.
!
! 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.
!
! 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.
\end{document}
Index: rradicalpd.rst
===================================================================
RCS file: /cvsroot/pure-data/abstractions/rradical/doc/rradicalpd.rst,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -C2 -d -r1.1.1.1 -r1.2
*** rradicalpd.rst 23 Apr 2004 16:26:20 -0000 1.1.1.1
--- rradicalpd.rst 26 Jun 2004 12:19:45 -0000 1.2
***************
*** 6,15 ****
Frank Barknecht <fbar at footils.org>
:Abstract:
! 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 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. It
! is spelled RRAD, but pronounced Rradical. ;)
What it takes to be a RRADical
--- 6,18 ----
Frank Barknecht <fbar at footils.org>
:Abstract:
! 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.
!
What it takes to be a RRADical
***************
*** 18,52 ****
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. ;)
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 GUIs
! built in.
! So for example instead of a basic ``lop~`` low pass filter something more
! complete like a recreation of the Sherman filter bank could be included in
! that collection. My older sseq and angriff patches followed this idea in
! general, but there are much more patches needed. Like this:
! * a sample player (adapt Gyre?)
! * Various OSC/LFO with preset waveforms
! * drum machine
! * guitar simulator
! * grain sample player
! * more sequencers
! * basically a lot of things like these things in Reason
- Not that I want to make Pd be Reason, no way. But 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.
Problems and Solutions
----------------------
! To building above system several problems are to be solved. Two key areas
! already targetted are:
**Persistence**
--- 21,61 ----
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".
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.
! 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 ``lop~`` 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
! ``lop~``. 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.
! 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.
Problems and Solutions
----------------------
! To build above, highly modularized system several problems have to be
! solved. Two key areas turned out to be very important:
**Persistence**
***************
*** 81,93 ****
Still, in a musician's practice some kind of persistence turns out to be an
! important feature, that many Pd beginners do miss. So there are several
! approaches to add it. Max/MSP has the ``preset``-object, Pd has the
! ``state``-object which saves the current state of (some) GUI objects inside
! a patch. Both also support changing between several different states.
! Both have at least two problems: They save only the state of GUI objects,
! which might not be all that a user wants to save. And they don't handle
! abstractions very well, which are crucial when creating modularized
! patches.
Another approach is to (ab)use some of the Pd objects that can persist
--- 90,108 ----
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.
! There are several approaches to add persistence. Max/MSP has the
! ``preset``-object, Pd provides the similar ``state``-object which saves the
! current state of (some) GUI objects inside a patch. Both objects also
! support changing between several different states.
!
! 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.
Another approach is to (ab)use some of the Pd objects that can persist
***************
*** 95,116 ****
works better, but isn't standardized.
! A rather new candidate for state saving is Thomas Grill's ``pool``
! external. Basically it offers something, that is standard in many
! programming languages: a data structure that stores key-value-pairs. This
! also is known as hash, dictonary or map. With ``pool`` 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 ``pool MYPOOL`` in one patch will
! contain the same data as a ``pool MYPOOL`` in another patch. Changes to one
! pool will change the data in the other as well.
A ``pool`` 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 haw this is done late.
Communication
.............
! Besides persistance 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
--- 110,133 ----
works better, but isn't standardized.
! A rather new candidate for state saving is Thomas Grill's ``pool`` 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 ``pool`` 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 ``pool MYPOOL`` in one patch will contain
! the same data as a ``pool MYPOOL`` in another patch. Changes to one pool
! will change the data in the other as well. This allows us to use ``pool
! MYPOOL``\s inside of abstractions, and still access the pool from modules
! outside the abstractions, for example for saving the ``pool`` to disk.
A ``pool`` 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.
Communication
.............
! 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
***************
*** 119,137 ****
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, but
! this gets harder, if he uses prefabricated modules, which might use their
! own senders.
! So it is crucial, that senders in RRADical abstractions use local senders
! only with as few exceptions as possible. This is achieved by prepending the
! RRADical senders with the string "$0-". So you'd not use ``send volume``,
! but instead use ``send $0-volume``. $0 makes those sends local inside their
! own patch borders. This might be a bit difficult to understand to the
! casual Pd user, but is a pretty standard idiom in the Pd world.
! Still we will want to control a lot of parameters and do so not only
! through the GUI Pd offers, but probably also through other ways, for
! example through Midi controllers, through some kind of score on disk,
! through satellite navigation receivers or whatever.
This creates a fundamental conflict:
--- 136,157 ----
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.
! 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 ``send
! volume``, instead one called ``send $0-volume`` 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.
! 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.
This creates a fundamental conflict:
***************
*** 144,154 ****
from the outside.
! The RRADical approach adheres to this in that it enforces a strict border
! but drills a single hole in it: the **OSC inlet**. This idea is the result
! of a discussion on the Pd mailing list and goes back to suggestions by
! `Eric Skogen`_ and `Ben Bogart`_. Every RRADical patch has (to have) a
! rightmost inlet that accepts messages formatted according to the OSC
! protocol. OSC stands for `Open Sound Control`_ and is a network transparent
! system to control audio applications remotely developed at CNMAT in Berkley.
.. _`Eric Skogen`: http://www.audionerd.com
--- 164,175 ----
from the outside.
! The RRADical approach solves both requirements in that it enforces a strict
! border around abstractions but drills a single hole in it: the **OSC
! inlet**. This idea is the result of a discussion on the Pd mailing list and
! goes back to suggestions by `Eric Skogen`_ and `Ben Bogart`_. Every RRADical
! patch has (to have) a rightmost inlet that accepts messages formatted
! according to the OSC protocol. OSC stands for `Open Sound Control`_ and is a
! network transparent system to control (audio) applications remotely and is
! developed at CNMAT in Berkley by Matt Wright mainly.
.. _`Eric Skogen`: http://www.audionerd.com
***************
*** 157,162 ****
The nice thing about OSC is that it can control many parameters over a
! single communication path. This is so, because OSC uses a URL-like scheme
! to address parameters. An example would be this message::
/synth/fm/volume 85
--- 178,184 ----
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::
/synth/fm/volume 85
***************
*** 175,179 ****
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 rightmost inlet.
--- 197,203 ----
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.
***************
*** 181,209 ****
-------------------------------------
! To realize the functionality requirements developed so far I resorted to a
! so called `Memento`. `"Memento"` is a very cool movie by director
! Christopher Nolan where - quoting IMDB:
A man, suffering from short-term memory loss, uses notes and tattoos to
hunt down his wife's killer.
- If you haven't already done so: Watch this movie! It's much better than
- Matrix 2 and 3 and also stars Carrie-Anne "Trinity" Moss.
-
Here's a scene from "Memento":
.. image:: memento.png
! We see the film's main character Leonard who 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 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.
In software development Mementos are quite common as well. The computer
! science literature describes them in great detail. To make the best use of
a Memento science recommends an approach where certain tasks are in the
responsibility of certain independent players.
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
--- 205,234 ----
-------------------------------------
! To realize the functionality requirements laid out so far I resorted to a so
! called `Memento`. `"Memento"` is a very cool movie by director Christopher
! Nolan where - quoting IMDB:
A man, suffering from short-term memory loss, uses notes and tattoos to
hunt down his wife's killer.
Here's a scene from "Memento":
.. image:: memento.png
! 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.
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" [Gamma95]_. To make the best use of
a Memento science recommends an approach where certain tasks are in the
responsibility of certain independent players.
+ .. [Gamma95] E. Gamma and R. Helm and R. Johnson and J. Vlissides: "Design
+ Patterns: Elements of Reusable Object-Oriented Software" Addison-Wesley 1995
+
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
***************
*** 219,223 ****
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 noone fiddles around with them. Btw: In the movie some
interesting problems with Caretakers, who don't always act responsible,
occur.
--- 244,248 ----
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.
***************
*** 253,257 ****
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 accesse it via OSC through the rightmost inlet of
``originator`` under the tree "/patch"
--- 278,282 ----
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
``originator`` under the tree "/patch"
***************
*** 287,291 ****
/mypatch 0 , /volume , 38
! Here a comma separates key and value pairs. "mypatch" is the toplevel
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
--- 312,316 ----
/mypatch 0 , /volume , 38
! 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
***************
*** 315,319 ****
values. Exchanging the ``substate`` message with a ``setsub`` message will
autoload the selected state and "set" the sliders to the stored values
! immediatly.
OSC in Memento
--- 340,344 ----
values. Exchanging the ``substate`` message with a ``setsub`` message will
autoload the selected state and "set" the sliders to the stored values
! immediately.
OSC in Memento
***************
*** 347,351 ****
**Rapidity**
! Ready-to-use highlevel 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.
--- 372,376 ----
**Rapidity**
! 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.
***************
*** 357,366 ****
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. The RRADical collection comes with a template file,
! called ``rrad.tpl`` that makes deploying new RRADical patches easier and
! lets developers concentrate on the algorighm instead of bookeeping. Some
! utils (footils?) help with creating the sometimes needed many
! ``commun``-objects. Several usecases show example applications of the
! provided abstractions.
--- 382,443 ----
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 pure-data.sourceforge.net_ in the directory
! "abstractions/rradical".
! The RRADical collection comes with a template file, called
! ``rrad.tpl.pd`` 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 ``commun``-objects.
! Several usecases show example applications of the provided abstractions.
!
! .. _pure-data.sourceforge.net: http://pure-data.sourceforge.net
!
! Much, but not all is well yet
! ------------------------------
!
! 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.
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
Index: rradicalpd.pdf
===================================================================
RCS file: /cvsroot/pure-data/abstractions/rradical/doc/rradicalpd.pdf,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -C2 -d -r1.1.1.1 -r1.2
Binary files /tmp/cvsj2h2Zk and /tmp/cvs0Wy9Fa differ
More information about the Pd-cvs
mailing list