Personal tools
You are here: Home community Projects RRADical Pd BrainStorming
Views

Edit history

Edit: -1 of 1
Time: 2006-12-20 12:40:27
Note: /pd/pd/portal_catalog/manage_catalogRebuild

changed:
-
BrainStorming

  Several problems and possible solutions were already mentioned:

Persistance (state saving). 

  Thomas Grill's "pool" external
has several advantages above all other methods of
persistence I tried so far and is now my "Memento" of choice. A new
release of angriff & co using that approach may be ready next week. 

Memento here refers to a software design pattern. Using pool it is
possible to abstract the persistance from the algorithm, that's needs
to persist a state somehow. The way I (intend to) use pool here is to
have a pool object somewhere in an abstraction that is used in e.g.
angriff and that gets a user defined name, so it can share it's
settings with all other pool objects. The actual saving is removed
from angriff and will be the responsibility of the patch author. But
with pool it's dead simple. It's a bit difficult to explain in words,
though, so I'll better attach an example: 

Available as "poolexample.tgz":http://www.pure-data.org/Members/fbar/patches/poolexample.tgz/view

tester.pd is the main patch, that uses the pool-abs abstraction two
times. Each pool-abs contains a named pool object, that gets its name
from the first argument ($0-storage in example). The second argument
is just a key that makes both abstractions use unique names, so that
you can store different settings in each.

tester.pd also has a named pool object, that bares the same name as
the other two pools. This creates a magic global and instantaneous
connection between all the pools (like the tunneling effect in quantum
physics)

So all saving of all used patches can be done in a central place. Dave
MacCallum had to overcome a lot of ugly obstacles to do largely the
same just with builtin objects in his reworked d-angriff patches and a
lot of other patches, but with pool it's so much more simple, that
it's worth the extra external. Dave, don't you agree after seeing the
attached example?

In the end angriff et al. will make use of pool hierarchies but that's
too much to explain here and now.


Communication (send messages in a unified way between patches):
OSC, send/receive,...

  ErikSkogen proposed using OSC. Here's part of his mail on that topic:

the problem has always been creating abstractions than can mingle. everyone 
has varying programming styles, and with a system as open as pd, having 
abstractions communicate in a common way can be difficult.

one thing i've found useful is routing abstractions using OSC. each 
abstraction is given a name as it's first argument, and it can 
automatically be referenced from that point on with:

/pd/synth/(name)

so the user just needs to know how to create the abstraction and give it 
a name, and then set a sequencer to send OSC commands to that synth 
using a standard interface. this way, i can have lots of different synth 
abstractions controlled the same way.

API

  any set of abstractions we work out should have AWESOME documentation or
nobody will use them. they should be rediculously easy to use. they
should allow states to be easily saved and recalled. they should allow
complex automation. they should have a consistant "API" for modularity.

An API will require discipline, though, that's why a certain kind of API
description will have to come rather early. Kind of **The RRADical Manifesto
x.x**

Powered by IEM Powered by Plone Section 508 WCAG Valid XHTML Valid CSS Usable in any browser