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

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

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