Hi John,
On Tue, Jul 27, 2010 at 12:29:49PM -0700, saint wrote:
Okay Frank thanks for the tips.
I was thinking of wrapper abstractions but I think I'll just have to go the rjdj route. I've always been a bit perplexed by sssad, do you recommend examining the rjdj abstractions to learn?
Personally I think, they have a nice interface for remote and inlet control of abstraction parameters. But I have to say that, I patched it. :)
At the very base there are sssad (called u_sssad in rj) objects, but actually you never see them, because they are hidden in dispatcher [u_dispatch] objects. These dispatchers are used to translate messages to receivers.
An [u_dispatch $0 frequency] will translate a message like "frequency 440" to a "440" sent to a "$0-frequency" receiver by using:
[inlet] | [route $2] | | | [outlet] | [s $1-$2]
Non-matching messages are sent along. This way you can easily build your whole "method"-list for an abstraction as:
[inlet] | [u_dispatch $0 frequency] | [u_dispatch $0 volume] | [u_dispatch $0 timbre] ...
Usually the last inlet of an rj-abstraction is built up like that.
Now the smart part is this: I realised , that everything, that is controlled through this last dispatcher-inlet also is something, that will be useful to control remotely and to save to a file/messagebox/...
That's why I added a [u_sssad $2 $1] object to u_dispatch.pd as well. $2 would become "frequency" or "volume" so it's the name of the parameter, while $1 is the parent's $0, which by some more trickery is used to do local as well as global parameter control (this is made with [u_loader] and it is a bit more complicated to explain.)
Anyway in the end, to "sssadify" an abstraction in rj only requires these steps:
- add a dispatcher inlet
- add daisy-chained [u_dispatch $0 parameter] objects there for all your parameters
- add a single [u_loader <name_of_abstraction>-$1 $0] object to your abstraction
Then always use your abstraction with a unique first argument as a "tag". Remote control can be realised by sending messages like: "<name_of_abstraction>-MYTAG frequency 330" to a global sender called "RJ_SCENE_LOAD". saving is made by sending "save" to "RJ_SCENE_SAVE" which will make you receive messages on "RJ_SCENE" that later can be sent to RJ_SCENE_LOAD for restoring.
That's about it.
About the subpatches though, I was under the impression if a subpatch was closed then it won't take up the usual graphical change overhead that it would if it was open?
Actually GUI objects can take a lot of resources even when invisible, if you activate them too often. At RjDj we target low-performance CPUs, so we optimize patches a lot, and the first thing to do is to remove all debugging GUIs. (RjDj doesn't even show the Pd GUI.)
Ciao
Frank