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. Keith On Thu, Jul 29, 2010 at 9:27 AM, toby @ tobyz <li...@tobyz.net> wrote: > On 28 Jul 2010, at 19:03, vade wrote: > >> Make a few patches within a macro within a macro within a macro (ha), like >> iterator, render in image etc. Publish a few outputs to the parent patches >> and up through your macro 'graph' to the top most patch. Within one of the >> sub macros other than parent, decide you want to encapsulate something into >> a new macro (say for organizational purposes), and all of a sudden your >> published ports are no longer published, forcing you to re-publish them >> tediously. > > On 28 Jul 2010, at 19:13, Memo Akten wrote: > >> and also maybe a similar solution to when you want to move all that you've >> done into another macro patch (such as render in image, trackball, lighting, >> fog etc). AFAIK with standard macro patches you can just select a bunch of >> patches and click on make macro, and it puts them in a macro. But with the >> above mentioned patches you can't do that, you have to cut and paste, which >> can be a major nuisance (if not for the very reason vade just mentioned). > > IMHO, the only sane answer to this whole arena of issues is a send and > receive pair. Then you can publish from whereever you are back to root, can > make your macro contents self-contained and so can move them around in any > order of environments, and QC gets the concept of global variables. > > It just makes so much sense to me. And yes, Kineme Spooky Send and Receive > are pretty much this. But built-in and safe is better. > > Having said that, I haven't filed a radar. Is there known a reason the QC > team was against this / is there one already I can piggy back to? > > Toby _______________________________________________ > 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/songcarver%40gmail.com > > This email sent to songcar...@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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
