Hallo Mike,
yeah, that's a fundamentally different approach: Basically in aspect, you create a lot of global senders and receivers, while in sssad there are only two of these. I think, limiting the amount of globals used in abstraction libraries is important to avoid pitfalls with nameclashes and to give the users of your libraries as much freedom in choosing names as possible. Globals in other programming languages often are avoided for similar reasons: They are too error prone.
Now if you really worry about the load of having a lot of [route]-misses when sending message, I'd recommend to use the "local" senders in sssad, that are used when adding a second argument to a [sssad] object: [sssad key $0] will use a bus called [r $0-SSSAD] and [r $0-SSSAD_ADMIN] instead of the global ones.
In RjDj's library we only use the local sssads. There is an additional object in each abstracition which connects the local busses to the global "SSSAD" and "SSSAD_ADMIN" bus: It's called [u_loader] in the RjDj library and has its own small number of global senders (RJ_SAVE, ...).
By using local sssads you can build a chain of such objects pretty nicely.
Ciao
Frank
Mike McGonagle hat gesagt: // Mike McGonagle wrote:
I was wondering about the scalability of SSSAD. While it is probably not an issue when only a small number of parameters are being used, what would happen when you are creating objects that, themselves, create many parameters?
I was noticing that any time I make a change to any of the parameters under SSSAD control, a message gets sent to EVERY OTHER parameter, whether or not it is of the same key. Many of those messages get sent only to be rejected.
I was wondering how it might effect things that instead of having the SSSAD bus at all, that a message point would be created for each parameter. We already know that a parameter has a specific unique key, so why not use that to send messages to to change the value of the parameter? It would reduce the number of messages being sent.
So, basically, the two things that have changed here is that the SSSAD bus get eliminated, and is replaced by sending a message directly to the parameters key, and in the "loading" process, instead of sending the messages to SSSAD, you would use the first parameter in the saved data stream as the place to send the parameter.
I tried to mock up what I am talking about, and have attached it to this email. As far as I can tell, this should be functional replacement for SSSAD, with the exception of having to send the message to the key, rather than SSSAD.
Mike
PS, if you find this useful, please don't start to use it, as I don't think we really need an alternative to SSSAD, I only make this proposal to see if it would be worthwhile to modify SSSAD.
--
Douglas Adams - "I love deadlines. I like the whooshing sound they make as they fly by."
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list