What is "faster" in terms of patch loads and runtime performance, using regular connections or sends?
I ask this as I have been developing objects with lots of sends inside of them and I'm wondering if this has any impact on patch performance ... even if I don't use more then half of them? It seems to me that a regular connection has the advantage of not requiring a lookup for the receive...
On Tue, 18 Dec 2007, Daniel Wilcox wrote:
What is "faster" in terms of patch loads and runtime performance, using regular connections or sends? I ask this as I have been developing objects with lots of sends inside of them and I'm wondering if this has any impact on patch performance ... even if I don't use more then half of them? It seems to me that a regular connection has the advantage of not requiring a lookup for the receive...
If you can't measure it, then it does not matter.
Even though in both theory and experience you can be sure that [r]/[s] is at least a bit slower... it's damn hard to tell the difference for your average real-life project (by opposition to artificial situations like benchmarks).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Dec 18, 2007 6:08 PM, Mathieu Bouchard matju@artengine.ca wrote:
On Tue, 18 Dec 2007, Daniel Wilcox wrote:
What is "faster" in terms of patch loads and runtime performance, using regular connections or sends? I ask this as I have been developing objects with lots of sends inside of them and I'm wondering if this has any impact on patch performance ... even if I don't use more then half of them? It seems to me that a regular connection has the advantage of not requiring a lookup for the receive...
If you can't measure it, then it does not matter.
Agreed. I'm not going to spend any time trying to needlessly optimize unless it makes some discernible difference.
Even though in both theory and experience you can be sure that [r]/[s] is at least a bit slower... it's damn hard to tell the difference for your average real-life project (by opposition to artificial situations like benchmarks).
Ok, thats what I thought ... I figured it wasnt a big impact. Just wondered if anyone else had wondered ...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Tue, 18 Dec 2007 18:12:27 -0500 "Daniel Wilcox" danomatika@gmail.com wrote:
On Dec 18, 2007 6:08 PM, Mathieu Bouchard matju@artengine.ca wrote:
On Tue, 18 Dec 2007, Daniel Wilcox wrote:
What is "faster" in terms of patch loads and runtime performance, using regular connections or sends? I ask this as I have been developing objects with lots of sends inside of them and I'm wondering if this has any impact on patch performance ... even if I don't use more then half of them? It seems to me that a regular connection has the advantage of not requiring a lookup for the receive...
If you can't measure it, then it does not matter.
Agreed. I'm not going to spend any time trying to needlessly optimize unless it makes some discernible difference.
The slight difference is for [s~][r~] vs signal connections the order of creation can change things. It's been discussed before in the context of delay/resonator string models.
Even though in both theory and experience you can be sure that [r]/[s] is at least a bit slower... it's damn hard to tell the difference for your average real-life project (by opposition to artificial situations like benchmarks).
Ok, thats what I thought ... I figured it wasnt a big impact. Just wondered if anyone else had wondered ...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
-- Dan Wilcox danomatika www.robotcowboy.com
On Wed, Dec 19, 2007 at 12:04:31AM +0000, Andy Farnell wrote:
The slight difference is for [s~][r~] vs signal connections the order of creation can change things. It's been discussed before in the context of delay/resonator string models.
what is the difference between r~/s~ and throw~/catch~ ?
-- Use the source
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 19 Dec 2007 08:04:52 +0000 errordeveloper@gmail.com wrote:
On Wed, Dec 19, 2007 at 12:04:31AM +0000, Andy Farnell wrote:
The slight difference is for [s~][r~] vs signal connections the order of creation can change things. It's been discussed before in the context of delay/resonator string models.
what is the difference between r~/s~ and throw~/catch~ ?
[r~][s~] are one to one, like two ends of a wire, [throw~][catch~] are many to one, for making busses or collecting polyphonic voices.
AFAIK there is no many to many (other than with cables), if not there probably should be.
-- Use the source
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
On Wed, 19 Dec 2007 08:04:52 +0000 errordeveloper@gmail.com wrote:
what is the difference between r~/s~ and throw~/catch~ ?
[r~][s~] are one to one
To be correct: It's one to many.
Ciao
Frank Barknecht _ ______footils.org__
On Wed, 19 Dec 2007 10:58:31 +0100 Frank Barknecht fbar@footils.org wrote:
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
On Wed, 19 Dec 2007 08:04:52 +0000 errordeveloper@gmail.com wrote:
what is the difference between r~/s~ and throw~/catch~ ?
[r~][s~] are one to one
Thankyou Frank. Remember we talked about problems that happen using more than one [r~]. Was that to do with creation order? Or is that something that only affects [throw~][catch~] pairs?
To be correct: It's one to many.
Ciao
Frank Barknecht _ ______footils.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 19 Dec 2007 10:41:07 +0000 Andy Farnell padawan12@obiwannabe.co.uk wrote:
On Wed, 19 Dec 2007 10:58:31 +0100 Frank Barknecht fbar@footils.org wrote:
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
On Wed, 19 Dec 2007 08:04:52 +0000 errordeveloper@gmail.com wrote:
what is the difference between r~/s~ and throw~/catch~ ?
[r~][s~] are one to one
Thankyou Frank. Remember we talked about problems that happen using more than one [r~]. Was that to do with creation order? Or is that something that only affects [throw~][catch~] pairs?
Maybe it was just me misusing [s~], if you create more than one [s~] with the same argument then only the last one created works.
To be correct: It's one to many.
Ciao
Frank Barknecht _ ______footils.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Use the source
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Quoting Andy Farnell padawan12@obiwannabe.co.uk:
Thankyou Frank. Remember we talked about problems that happen using more than one [r~]. Was that to do with creation order? Or is that something that only affects [throw~][catch~] pairs?
Maybe it was just me misusing [s~], if you create more than one [s~] with the same argument then only the last one created works.
that is what "one-to-many" means: exactly one(1) [send~] and
many(many) [receive~] objects.
mfg.asd IOhannes
This message was sent using IMP, the Internet Messaging Program.
On Wed, 19 Dec 2007 13:57:23 +0100 zmoelnig@iem.at wrote:
Quoting Andy Farnell padawan12@obiwannabe.co.uk:
Thankyou Frank. Remember we talked about problems that happen using more than one [r~]. Was that to do with creation order? Or is that something that only affects [throw~][catch~] pairs?
Maybe it was just me misusing [s~], if you create more than one [s~] with the same argument then only the last one created works.
Yes, I understand that Iohannes, the remark is about the behaviour you get if you don't understand and misuse [s~][r~]. It surprised me that it accepted the instance and replaced the old one.
cheers,
Andy
that is what "one-to-many" means: exactly one(1) [send~] and
many(many) [receive~] objects.mfg.asd IOhannes
This message was sent using IMP, the Internet Messaging Program.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Andy Farnell wrote:
Yes, I understand that Iohannes, the remark is about the behaviour you get if you don't understand and misuse [s~][r~]. It surprised
ah, ok sorry for the repetition...
me that it accepted the instance and replaced the old one.
indeed it is not what i would have expected either!
i guess this is what i would call "undefined behaviour" :-)
fmga.dsrt IOhannes
Quoting Andy Farnell padawan12@obiwannabe.co.uk:
On Wed, 19 Dec 2007 10:58:31 +0100 Frank Barknecht fbar@footils.org wrote:
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
On Wed, 19 Dec 2007 08:04:52 +0000 errordeveloper@gmail.com wrote:
what is the difference between r~/s~ and throw~/catch~ ?
[r~][s~] are one to one
Thankyou Frank. Remember we talked about problems that happen
i vaguely remember your post about this problem.... i also vaguely remember that i could not reproduce the problem.
using more than one [r~]. Was that to do with creation order?
one-to-many means that you can use more than one [r~]. i do this often.
it has nothing to do with creation order, the s~/r~ names are
evaluated when you turn on the audio-engine. not at creation time.
Or is that something that only affects [throw~][catch~] pairs?
neither. the throw~/catch~ names are evaluated when you turn on the
audio-engine. not at creation time.
the only time you can get into trouble is when you are doing dynamic
patching while the audio engine is on (then you can have
evaluation-time == creation-time and you will get a warning if there
is no [send~] or no [catch~] yet)
and if you want to do many-to-many, just use: | | | [throw~ bla] [throw~ bla] [throw~ bla]
[catch~ bla] | [send~ bla]
[r~ bla] [r~ bla] | |
mfg.ar IOhannes
This message was sent using IMP, the Internet Messaging Program.
I think connections are slightly faster, but that is negligible. the more important aspect is programming style/readability/layout/program flow, and in this respect connections are definitely preferable. with send/receive you end up with spaghetti code. Maybe when working with a lot of abstractions, it makes sense to use send/receive, just because drawing too many connections is a pain. but most of the time connections make your life easier. marius.
Daniel Wilcox wrote:
What is "faster" in terms of patch loads and runtime performance, using regular connections or sends?
I ask this as I have been developing objects with lots of sends inside of them and I'm wondering if this has any impact on patch performance ... even if I don't use more then half of them? It seems to me that a regular connection has the advantage of not requiring a lookup for the receive...
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Tue, 2007-12-18 at 19:31 -0500, marius schebella wrote:
I think connections are slightly faster, but that is negligible. the more important aspect is programming style/readability/layout/program flow, and in this respect connections are definitely preferable. with send/receive you end up with spaghetti code. Maybe when working with a lot of abstractions, it makes sense to use send/receive, just because drawing too many connections is a pain. but most of the time connections make your life easier. marius.
maybe when working with a lot of abstractions, it makes sense to use methods, that are all sent to the same inlet and inside the abstraction [route]d apart again. it makes it also easier to debug, because you need to create only one connection to one [print] in order to see, which message is sent in what orde to the abstraction.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Well, it all comes down to style now if we've determined theres no speed diff. Right now I've been building my objects with both traditional inlets/outlets as well as send/recieve mirrors named on the object name, first creation arg ala Chris McCormick's s-abstractions.
So [rc-arp arp1] has a midi note inlet as well as a matching [r arp1/notein] receive. It also has receives for each gui element. This is nice in that I can connect things in the traditional manner, but also quickly grab things in other parts of the patch.
It relatively easy to keep track of what's going on since the receives are based on the name and functionality, although at this point I find myself using connections much more. Another note is that I have recently upgraded to a newer used computer after I somehow connected 220VAC to the old laptop's Audio In which means I have a smaller resolution display. There's a big diff in patching practice between 1400x1050 and 1024x768.
Hmmm I have't tried this "global message bus" idea yet.
On Dec 18, 2007 7:49 PM, Roman Haefeli reduzierer@yahoo.de wrote:
On Tue, 2007-12-18 at 19:31 -0500, marius schebella wrote:
I think connections are slightly faster, but that is negligible. the more important aspect is programming style/readability/layout/program flow, and in this respect connections are definitely preferable. with send/receive you end up with spaghetti code. Maybe when working with a lot of abstractions, it makes sense to use send/receive, just because drawing too many connections is a pain. but most of the time connections make your life easier. marius.
maybe when working with a lot of abstractions, it makes sense to use methods, that are all sent to the same inlet and inside the abstraction [route]d apart again. it makes it also easier to debug, because you need to create only one connection to one [print] in order to see, which message is sent in what orde to the abstraction.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hallo, marius schebella hat gesagt: // marius schebella wrote:
I think connections are slightly faster, but that is negligible. the more important aspect is programming style/readability/layout/program flow, and in this respect connections are definitely preferable.
Not always. Well placed send/receives and careful abstraction planning can make things more readable.
Ciao
Frank Barknecht _ ______footils.org__
-
Andy Farnell -
Daniel Wilcox -
errordeveloper＠gmail.com -
Frank Barknecht -
IOhannes m zmoelnig -
marius schebella -
Mathieu Bouchard -
Roman Haefeli -
zmoelnig＠iem.at