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