Hi there:

...

Basically, add a [s $2-radiobutton-update] in the [originator] after the [OSCroute /preset]. And then add a [r $0-radiobutton-update] in the [pd save] or connect that straight to the radiobuttons. What do you think?

I don't like that in this case you would have to remember names of send/receive pairs. Paraphrasing something Miller said in Graz: This is too intelligent, we need a stupid solution.

I think, the solution should be to just route all substate changes to the OSC-outlet, then a user of originator can decide on his/her own, how to connect that information. I attached a very simple implementation of this: originator just got onee mor object: [/preset $1( connected to the final [OSCprepend $1], and rrad.tpl as an example then routes this info to set the radio button.

ummm, I was just looking a solution that can fix it with minimum modification:) Since [r $2-substate-r] is already set in the patch.

I have not tried the patches you attached yet, but I can understand your method and it makes sense. Its much more flexible for people who use it.

Would the new originator be up in the CVS soon?

In addition, I suggested that putting the drum abstractions I made in the rradical CVS. As I have not put anything up before, my apologies for not knowing any CVS conventions. Can people just put things up as they wish? Or are there any common consensus that needs to be reached first before one can put things up?

Many thanks

Yours

CHUN