On Wed, Mar 17, 2010 at 5:31 PM, Peter Boocock <[email protected]>wrote:
> As far as I'm aware you've gotten right that Environments might have their > inputs published up and thus be available for setting as a virtual macro > patch. > Yes. > > The GLSL patch is of course a programming patch, to which the same rules > apply , it seems also to OpenCL and Core Image and JS patches , namely, one > can edit the .qtz that houses the virtual macro, but apart from publishing > up inputs and publishing up outputs, a macro patches environment settings > are provided by the virtual macro pretty much as a consumer patch, with the > patch designer deciding what should be made available from the inputs housed > within. > > We don't seem to have the facility to make the editable panes available > from within the virtual macro as presented upon the Editor stage. > If you edit a qtz so that the root isn't a QC Patch, but GLSL, then you will have settings that allow for editing vertex and fragment, it's just that it's still a consumer patch, not an environement. > > The distinct difference here is between dragging and dropping say a pretty > useful construct, design or utility composition onto the Editor stage, which > will provide environmental access and on the other hand, dragging a virtual > macro clip onto the stage and either you've got an input / output utility of > some type - image filter, string formatter, whatever, or else you'll be > getting a consumer patch that structurally contains all sorts of facilities > , either they run automatically, or else they have inputs and sometimes > outputs. > That's why I think it's a reasonable feature request. If I edit a qtz so that the top level is a GLSL (via plist editor), and it drags onto the composition as a GLSL patch (and environment), I feel that a virtual version of the same thing should also restore as an environment, not a consumer. > > I can't speak for the viability of unregistered patches, but point is the > more exotic, the less mainstream, the less likely it will work far outside > of its real brief and bailiwick :-) > I can see how my desire could be construed as exotic, but I can do this with providers (like CI), or as consumers... so it seems like the fact that environments aren't supported is a fail. The idea of saving time via having all of my go-to GLSL environments in my patch list would be great for working. > > It's a pretty audacious and useful feature requests, but changing the > scripting within such a macro, if it were made possible, could likely as not > change and possibly damage such an composition. > Hmm, I don't think it's audacious. Current implementation of virtual patches is already broken (try making ones that refer to each other). As long as that is the case, I think that support for environments is reasonable to make this a complete patch/concept. > > > Perhaps what is needed is for the object oriented patches to be capable of > cloning themselves to be embedded be-spoked within the clone of their > original and still intact virtual macro. > > What about placing that virtual macro GLSL patch within an Environment as > and when you want? > I don't think either suggestion applies to what I'm trying to achieve. Best, as always Peter! -George > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Quartzcomposer-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > > http://lists.apple.com/mailman/options/quartzcomposer-dev/gtoledo3%40gmail.com > > This email sent to [email protected] >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to [email protected]
