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:
- include a single [originator Memento $0] object
- 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__