diff options
| author | Frank Barknecht <fbar@users.sourceforge.net> | 2004-06-26 12:19:45 +0000 |
|---|---|---|
| committer | Frank Barknecht <fbar@users.sourceforge.net> | 2004-06-26 12:19:45 +0000 |
| commit | 8e4970cdc578e6d9d07c1f4ada1a919f11df6f2a (patch) | |
| tree | 95901c6d1dace22cc52eea02aaed2b483ae7142f | |
| parent | ac0b773e0ff9c40f2ed04926c9479689c490c13c (diff) | |
New version.
svn path=/trunk/abstractions/rradical/; revision=1833
| -rw-r--r-- | doc/rradicalpd.html | 257 | ||||
| -rw-r--r-- | doc/rradicalpd.pdf | bin | 273129 -> 277587 bytes | |||
| -rw-r--r-- | doc/rradicalpd.rst | 271 | ||||
| -rw-r--r-- | doc/rradicalpd.tex | 288 |
4 files changed, 515 insertions, 301 deletions
diff --git a/doc/rradicalpd.html b/doc/rradicalpd.html index 04d6a42..ade3e7e 100644 --- a/doc/rradicalpd.html +++ b/doc/rradicalpd.html @@ -21,45 +21,51 @@ </table> <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> +<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. ;)</p> +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 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> +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 building above system several problems are to be solved. Two key areas -already targetted are:</p> +<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 @@ -87,52 +93,62 @@ 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. 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> +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 -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 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 haw this is done late.</p> +come back to how this is done below.</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 +<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, 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> +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> @@ -142,16 +158,18 @@ other.</dd> <dd>We want to have a way to reach their many internals and control them 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 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. This is so, because OSC uses a URL-like scheme -to address parameters. An example would be this message:</p> +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> @@ -167,30 +185,39 @@ 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 rightmost inlet.</p> +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 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> +<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>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. +<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. To make the best use of +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, @@ -203,7 +230,7 @@ Leonard gives his photos. In the movie Leonard also makes "hard saves" 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 noone fiddles around with them. Btw: In the movie some +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"> @@ -231,7 +258,7 @@ 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 accesse it via OSC through the rightmost inlet of +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 @@ -260,7 +287,7 @@ 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 toplevel +<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> @@ -284,7 +311,7 @@ move the sliders again as seen in the next picture:</p> <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 -immediatly.</p> +immediately.</p> </div> <div class="section" id="osc-in-memento"> <h2><a name="osc-in-memento">OSC in Memento</a></h2> @@ -314,7 +341,7 @@ 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 highlevel abstraction can save a lot of time when building +<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> @@ -323,12 +350,58 @@ 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. 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> +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> diff --git a/doc/rradicalpd.pdf b/doc/rradicalpd.pdf Binary files differindex 9820474..c80d144 100644 --- a/doc/rradicalpd.pdf +++ b/doc/rradicalpd.pdf diff --git a/doc/rradicalpd.rst b/doc/rradicalpd.rst index 9d77090..7240498 100644 --- a/doc/rradicalpd.rst +++ b/doc/rradicalpd.rst @@ -5,49 +5,58 @@ RRADical Pd :Authors: Frank Barknecht <fbar@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. ;) + 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 ------------------------------ 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. ;) +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 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. +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 building above system several problems are to be solved. Two key areas -already targetted are: +To build above, highly modularized system several problems have to be +solved. Two key areas turned out to be very important: **Persistence** How to save the current state of a patch? How to save more than one @@ -80,59 +89,70 @@ Pd author Miller S. Puckette writes about this in the Pd manual in section its right inlet here.) 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. +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 itself to a file, especially ``textfile``, ``qlist`` and ``table``, which 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 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 haw this is done late. +come back to how this is done below. Communication ............. -Besides persistance it also is important to create a common path through +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, 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. +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: @@ -143,21 +163,23 @@ This creates a fundamental conflict: We want to have a way to reach their many internals and control them 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. +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 .. _`Ben Bogart`: http://www.ekran.org/ben/ .. _`Open Sound Control`: http://www.cnmat.berkeley.edu/OpenSoundControl/ 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:: +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 @@ -174,37 +196,40 @@ send a chord progression to be played by both -- indicated by the wildcard 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. +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. 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: +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. -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. +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. To make the best use of +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 state and managing changes in it. In the movie, Leonard is the Originator, @@ -218,7 +243,7 @@ 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 noone fiddles around with them. Btw: In the movie some +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. @@ -252,7 +277,7 @@ arguments: The first on is the name under which this patch is to be stored inside the ``pool`` data. Each ``originator SomeName secondarg`` 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 accesse it via OSC through the rightmost inlet of +slash like "/patch" , you can also access it via OSC through the rightmost inlet of ``originator`` under the tree "/patch" The second argument practically always will be $0. It is used to talk to @@ -286,7 +311,7 @@ result in something like this:: /mypatch 0 , /volume , 38 -Here a comma separates key and value pairs. "mypatch" is the toplevel +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: @@ -314,7 +339,7 @@ Now careGUI prints:: You see, the substate 0 is unaffected, the new state can have different values. Exchanging the ``substate`` message with a ``setsub`` message will autoload the selected state and "set" the sliders to the stored values -immediatly. +immediately. OSC in Memento ............... @@ -346,7 +371,7 @@ set, it is possible to build real patches with it that have two main characteristics: **Rapidity** - Ready-to-use highlevel abstraction can save a lot of time when building + 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. @@ -356,11 +381,63 @@ characteristics: 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. +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. diff --git a/doc/rradicalpd.tex b/doc/rradicalpd.tex index 157aace..9997ecc 100644 --- a/doc/rradicalpd.tex +++ b/doc/rradicalpd.tex @@ -60,12 +60,14 @@ pdfauthor={Frank Barknecht {$<$}fbar@footils.org{$>$}} \end{center} \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. ;) +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. @@ -77,46 +79,36 @@ is spelled RRAD, but pronounced Rradical. ;) 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. ;) +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 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. +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. %___________________________________________________________________________ @@ -125,8 +117,8 @@ can spare lot of tedious, repeating patching work. \section*{Problems and Solutions} \pdfbookmark[0]{Problems and Solutions}{problems-and-solutions} -To building above system several problems are to be solved. Two key areas -already targetted are: +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] \item[\textbf{Persistence}] @@ -177,33 +169,41 @@ patch and will be forgotten when the patch is reloaded. its right inlet here.) 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. +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 itself to a file, especially \texttt{textfile}, \texttt{qlist} and \texttt{table}, which 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 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 haw this is done late. +come back to how this is done below. %___________________________________________________________________________ @@ -212,28 +212,31 @@ come back to haw this is done late. \subsection*{Communication} \pdfbookmark[1]{Communication}{communication} -Besides persistance it also is important to create a common path through +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, 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. +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: \begin{description} @@ -257,17 +260,19 @@ from the outside. %[depart_definition_list_item] \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 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. This is so, because OSC uses a URL-like scheme -to address parameters. An example would be this message: +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} \end{flushleft}\end{ttfamily} @@ -286,7 +291,9 @@ send a chord progression to be played by both -- indicated by the wildcard 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. +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. %___________________________________________________________________________ @@ -295,32 +302,34 @@ outside can be controlled by OSC messages to the rightmost inlet. \section*{Trying to remember it all: Memento} \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: +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} A man, suffering from short-term memory loss, uses notes and tattoos to hunt down his wife's killer. \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. +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. To make the best use of +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 record. A module called the ``Originator'' is responsible for creating this @@ -335,7 +344,7 @@ 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 noone fiddles around with them. Btw: In the movie some +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. @@ -373,7 +382,7 @@ arguments: The first on is the name under which this patch is to be stored inside the \texttt{pool} data. Each \texttt{originator SomeName secondarg} 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 accesse it via OSC through the rightmost inlet of +slash like ``/patch'' , you can also access it via OSC through the rightmost inlet of \texttt{originator} under the tree ``/patch'' The second argument practically always will be {\$}0. It is used to talk to @@ -408,7 +417,7 @@ result in something like this: \mbox{/mypatch~0~,~/volume~,~38} \end{flushleft}\end{ttfamily} -Here a comma separates key and value pairs. ``mypatch'' is the toplevel +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: @@ -438,7 +447,7 @@ Now careGUI prints: You see, the substate 0 is unaffected, the new state can have different 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. +immediately. %___________________________________________________________________________ @@ -482,7 +491,7 @@ characteristics: \item[\textbf{Rapidity}] %[visit_definition] -Ready-to-use highlevel abstraction can save a lot of time when building +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. @@ -501,11 +510,66 @@ for more than one piece by just exchanging the Caretaker-file used. 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. +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} |