I would like globals to be scoped and portable. One solution would be to only allow globals to propagate downstream in the macro tree. This doesn't help with UI elements such as buttons, but that can/should be solved by other means. One possible implementation is an invisible send or broadcast like metaphor. Another is an area on the workspace which contains global elements. Elements could be any node or set of nodes. .xX On Jul 29, 2010, at 6:02 PM, Alastair Leith wrote:
> I posted a mock-up yesterday (aust time) of different coloured noodles and > ports to the list. I sometimes wonder if my posts have been posted on list > because, it seems like, they don't get mailed out to the originating email > address. > > A problem with port colouring is that output ports often have several noodles > connected. I guess a multi-out-port splitter patch would get around that when > desired. Or show a row of coloured circles to the side of the port when the > noodles going to it are more than one and active. I think the multicolour > thing should be enabled only when patches are selected, like how noodles get > coloured when a patch or several are selected (in Leopard anyhow). You'd run > out of distinct colours pretty quickly. > > Alastair Leith > > > > The machine does not isolate man from the great problems of nature but > plunges him more deeply into them. > Antoine de Saint-Exupery > > On 30/07/2010, at 5:27 AM, Alex Drinkwater wrote: > >> 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/qc.student.au%40gmail.com >> >> This email sent to qc.student...@gmail.com > > _______________________________________________ > 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/asabatelli%40apple.com > > This email sent to asabate...@apple.com
_______________________________________________ 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
