Bit OT, but if it's not already been mentioned, how about different-coloured patch leads/noodles for different port-types (and maybe a variation on each colour indicating some conversion is happening). And/or the ability to click on a noodle and set a colour. Very simple, but makes at-a-glance reading of a patch easier.
Actually, the patch ports themselves could be different colours. a|x --- On Thu, 29/7/10, toby @ tobyz <li...@tobyz.net> wrote: > 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 > _______________________________________________ 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
