From: toby @ tobyz <li...@tobyz.net>
Subject: Re: Work flow annoyance with QC - suggestions/bug?
To: "quartzcomposer-dev list list" <Quartzcomposer-dev@lists.apple.com
>
Date: Thursday, 29 July, 2010, 1:28
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/the_voder%40yahoo.co.uk
This email sent to the_vo...@yahoo.co.uk
