Hello all,
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.
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
On Sun, Mar 15, 2009 at 3:32 PM, Frank Barknecht fbar@footils.org wrote:
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.
The context that I was actually thinking was in trying to do "live coding". Of all the times that I have been using SSSAD, my biggest complaint about it is that I would always need to resave, close, and reopen the file. It always seemed that the one instance of an SSSAD reference that I was deleting was the FIRST ONE. Of course, doing that was sure to make that parameters NOT SAVE, unless I reopened.
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.
My whole point of bringing this up has more to do with how an "external" (yes, actual C code) might be able to implement the SSSAD protocol. I can think of MANY EXTERNALS that would benefit by doing this...
At the same time, that might make it appear that SSSAD is an accepted standard in Pd. And Miller, himself has written on this very topic... So, what is the means of storing data... is there one?
I'm curious, but how many "externals" do you have with RjDj? I can only assume that you can't do too much with it, other than the basic implementation of Pd.
Mike
Hallo, Mike McGonagle hat gesagt: // Mike McGonagle wrote:
On Sun, Mar 15, 2009 at 3:32 PM, Frank Barknecht fbar@footils.org wrote:
The context that I was actually thinking was in trying to do "live coding". Of all the times that I have been using SSSAD, my biggest complaint about it is that I would always need to resave, close, and reopen the file. It always seemed that the one instance of an SSSAD reference that I was deleting was the FIRST ONE. Of course, doing that was sure to make that parameters NOT SAVE, unless I reopened.
A closebang would solve this. It will probably happen less often with local sssads.
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.
My whole point of bringing this up has more to do with how an "external" (yes, actual C code) might be able to implement the SSSAD protocol. I can think of MANY EXTERNALS that would benefit by doing this...
At the same time, that might make it appear that SSSAD is an accepted standard in Pd. And Miller, himself has written on this very topic... So, what is the means of storing data... is there one?
Storing data is not in the realm of sssad - again this is by design and comes from my experience with RRADical/Memento where the storage was inside the saving system and tied to [pool].
SSSAD is intended to to just one thing but do that right: Its purpose is to eavesdrop on the messages that objects send to each other and distribute them to rsp. modify them from a central place. That's all. What comes after that central place is up to the end user. It would be easy to make an external that does the same. sssad is just a wrapper around [list], [route] [send] and [receive]. One "S" in its name stands for "simple". ;)
I'm curious, but how many "externals" do you have with RjDj? I can only assume that you can't do too much with it, other than the basic implementation of Pd.
Hm, I don't understand this question? RjDj is pretty much pure Pd and has almost no externals at all - which doesn't mean that you can't do much with it: For audio work Pd is very powerful and no externals are (strictly) necessary.
Ciao
Frank
-
Frank Barknecht -
Mike McGonagle