Memento 0.1 [was: Re: [PD] Announcing "RRADical Pd"]

[Frank Barknecht]

Hallo Ben,
B. Bogart hat gesagt: // B. Bogart wrote:

> I agree, what you did with using my OSC routes (in and out) is what I
> was hoping to be able to do. This could be a good way for approching
> the design for RRADical. I started making a new object for v_ that
> uses the internal OSC messages to control other GOPs. 

After thinking about this for quite some time I now ditched the OSC
solution again, but maybe only temporarily. I ditched it, because it
occured ot me, that even with OSC there still was a fundamental
problem: Too many global sends/receive pairs! Global sends are a major
obstacle in getting things reusable, IMO, and even with named sends
like in the OSC examples, the global namespace gets polluted. Okay,
with OSC it's not that bad, because it's sends inside OSC and not in
the regular send/receive, but still I wasn't too happy with it. 

Thinking even hard I now made a first try at a reference
implementation of my prior Memento idea. You can get and try it at 
http://www.pure-data.org/Members/fbar/patches/memento-0.1.tgz/view

It comes with an extensive README.txt, and still includes some
unfinished testing. The main patch to look at is called "mainpatch",
which in turn uses an example abstraction called "rradical". Here's an
shortened excerpt from the README: 

  This is a work-in-progress collection of a unified preset system for
  Pd patches. It tries to loosely follow the Memento [1] design
  pattern from the Gang of Four book.
  
  I propose that a Memento here is realised as a directory in a data
  pool inside a [pool] object. 
  
  The Memento is only changed or read through the [originator]
  abstraction. 
  
  It is not allowed to bypass [originator] to change the values inside
  the RRADICAL pool, with one exception: 
  
  The [caretaker] abstraction is responsible for saving and loading
  pool data from harddisk. 
  
  Communication between [originator] and anything that wants to save
  anything is done through the [commun] abstraction. 
  
  [commun] accepts anything and spits out anything if [originator]
  tells it too (with [originator]'s "set" message).
  
  _ Usage _ 
  
  Every abstraction, that wants to take part in saving its settings
  with Memento needs to:
  1) include a single [originator Memento $0] object
  2) wrap all variables with [commun id $0] objects
  
  A single [caretaker] then can save and reload settings. (In the
  parent patch.)

> > (Btw: could you give v_abstractions2 a name with a suffix like .tgz?
> > This will make it easier to find out what kind of file it is for
> > others.)
> 
> done. (I'm not sure why the mime-type is not enough.

The MIME type, at least on Windows and Linux, isn't known anymore
after the file was saved to harddisk. So unless you directly open it
from the browser (possible security risk) you have to find out the
filetype without knowing the extension, on Linux for example with
"file".

> > This are very cool patches and highly qualify to be called "RRADical" ;)
> 
> Thanks! It will be pretty cool to have an integrated suite of such things.

RRADical then now official is called "Reusable and Rapid APPLICATION
Development" ;)

> very nice. The reason why OSC was not an abstraction is that each
> GOP have a different number of controlls, so ideally an OSC abstraction
> would dynamically created the right number of inlets and outlets and
> know what to do with the data. (This is the only reason why OSC is not
> an abstraction in the first place!)

Yep, after looking at more of your patches, I've also seen that. It
made me abstract out this functionality into a [commun] abstraction
for Memento 0.1

ciao
-- 
 Frank Barknecht                               _ ______footils.org__