[PD] Good programming practice

[Peter Todd]

This is more in response to Frank than any new contribution to the 
discussion - feel free to ignore it, I doubt there is much new to learn.

> Hallo,
>
> This is not too different from the way, rradical does it, except this:
> rradical does keep all things local, while still allowing access
> through $1-named addresses. I intentionally did not use send/receive
> pairs for this. Although clashes are unlikely with consistently named
> sends, they still are possible and require a user to take care of
> this. Also sends require a user to remember all these names and write
> a lot of [s something] objects. This is fine, if you're the only user,
> but as soon as others try to use an abstraction library, things get
> too complicated IMO.

That sounds reasonable.  Nonetheless, the only time a user is required to 
write the [s something]s, is when they explicitly want to control things in 
a different way (and they can 'send' with messages, rather than [s]) - 
again, not so different from rradical?  I still prefer your method, though, 
I think (and it's better that there is a consensus / standard, so people 
don't keep reinventing the wheel).

>
> Instead all this is solved in rradical through the OSC x-let, which
> actually currently doesn't need to use OSC, plain [route] would work
> as well, but OSC made it much easier and has several other advantages
> (foremost that's pattern matching)

I've been anticipating taking advantage of some OSC features.

>
> In rradical, no send names have to be remembered at all, because there
> are none! This is important. Everything is done through the OSC
> inlets, which basically are connected to [OSCroute $1]. This could be
> [route $1] as well. Then every parameter, that should be controlled,
> has another [OSCroute /paramname] which could be [route paramname] as
> well, if you want to avoid OSC.

By this, I presume you mean that there is an OSCroute created outside each 
actual rradical abstraction subsequently connected to the OSC inlet?  That 
seems to make most sense.

>
> Now if every OSC inlet is fed by [r OSC] receivers, a user of rradical
> has remote control of all parameters through one single global sender,
> if (s)he likes to do so, just by sending correctly formatted messages
> to it: "; OSC /synth/paramname 20" (OSC) or "; OSC synth paramname 20"
> (route, not implemented in rradical). No global sends at all, except
> one not named by me, but by the user.
>
> I called this the "strict borders, single crossing" principle in
> RRADical.
>

Of course being greeted with lots of 'couldn't create' errors had 
discouraged me up until this point from actually studying how rradical is 
working (I don't know why I didn't ask for help in finding OSC sooner, for 
that and other reasons).  You've laid out many things very clearly and I 
find nothing to disagree with.  I still need to read the documentation and 
experiment with this, but it seems that most things are under control.

Regards,

Peter


> Ciao
> -- 
> Frank Barknecht                               _ ______footils.org__
>