Just realised it sent this to Frank, but not to list.

Also realized in light of discussion on automation that my last paragraph is somewhat obsolete.

Chris.

----- Forwarded message from Chris McCormick chris@mccormick.cx -----

From: Chris McCormick chris@mccormick.cx To: Frank Barknecht fbar@footils.org Subject: Re: [PD] Announcing "RRADical Pd" X-Uptime: 10:37:26 up 32 days, 13:27, 1 user, load average: 0.00, 0.00, 0.00

On Sat, Nov 29, 2003 at 01:41:17PM +0100, Frank Barknecht wrote:

Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:

...

• All sliders/controls have a standard range (i.e. 0 to 1 or 1 to 0) -

the patches will internally scale the value to what they need. (eg. x20000 for filter cutoff)

Actually I probably would prefer them to stay at 0-127 because of midi comatibility, but maybe this even wouldn't be necessary to unify...

Sounds good to me. I'll update my patches.

There might very well be values that are useful to send but that are not needed to be contained in a GUI object. For example in your s-distortion the filename of the shaper array could come from outside.

I would prefer to keep things localized through $0-arguments as much as possible. What are the areas, where global access is needed? I could think of the following ones:

• Persistance. Saving probably should be centralized as much as possible.

• External control: After seeing some OSC patches, I'm very fond of the idea to use OSC for all communication outside the abstractions. Inside of them I think, normal send/receives would be enough, but OTOH once you start to do OSC, there might not be much need for it.

• More?

I could figure an approach where you have one highly reused abstraction that would be used to wrap above points:

[r $0-somevalue-read] | [persistance_and_control_wrapper $1] <= use $1 for all global actions | [s $0-somevalue-write]

Beautiful. I'll start doing this, and also add OSC routing to my patches.

I think as you standardise the Rradical framework you'll get a bunch of common patches like [communicate $1] which everyone will want in common. Perhaps we should start a CVS repository for these? (and other rradical patches?)

Also, I was thinking about persistance not just of settings, but persistance across time (e.g. the settings of your mixer at time=0 are different from those 5 seconds into yr piece). It might be nice to come up with a standard framework to build patches around with this kind of persistance in mind. It seems from your posts taht you're already devising an implementation of this. I guess we could have a standard send variable for number of ticks or something like that. Then when we build GOP sequencers they will use this standard.

Chris.

chris@mccormick.cx http://www.mccormick.cx http://www.hypercube.com.au http://www.sciencegirlrecords.com

----- End forwarded message -----