Yep. On posting I went "oh yeah, hang on" having been through a similar loop in QC's earlier days.
I still wonder whether there is a way though. Couldn't the send be a consumer, and if its object is called before it has evaluated in the graph, its previous state is passed? While I wouldn't want to condone anything that adds to the wierdness lazy evaluation can make, understanding lazy evaluation is part of the QC experience, and that behaviour would be consistent with it? To be honest, just a patch which allows a remote receive or comp-wide sync of a constant variable(s) would make my day, you could call it a 'preferences' patch. Toby (oops - originally sent with the wrong email account) On 29 Jul 2010, at 00:40, Christopher Wright wrote: >> Forgive the untechnical question (I'm no coder), but I always thought >> the reason why QC didn't support send and receive pairs was because >> there was some inherent performance problem when you break the >> hierarchy and allow data to be sent willy nilly? >> >> For the record, I would love such a thing. > > Since QC's pull-driven (consumers pull data through the graph), there's no > "sending" -- a broadcaster with no receiver does very little work (sets a > pointer somewhere that never gets read), which is as close to "free" as you > can get without actually being free :) > > The more fundamental problem is execution order -- if a broadcaster is layer > 2, and a consumer that uses it is layer 1, it will always operate on 1-frame > stale data (which could be wrong, and isn't entirely obvious). A variation > on it is types -- if you send a mesh, but the receiver expects a string, what > happens? normal noodle conversions can only do so much, and some things are > out-right forbidden; broadcasting pretty much prevents forbidden connections > from being prevented. Introspection can "protect" you from exploding, but > there's a small cost to doing that all the time. > > Lots of people want this, inside and outside :) > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/quartzcomposer-dev/lists%40tobyz.net > > This email sent to li...@tobyz.net _______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
