George, It's the plain fact that although they are all programmable; though the GLSL patch certainly is capable of providing an environment, the JS patch isn't , the Core Image patch isn't and the OpenCL kernel patch isn't, but it's that programmability that they all share that provokes a difficulty to me, even though I like the idea a whole lot.
Wouldn't mean that , if I've understood correctly, that you would want the Vertex and Fragment shader panels available from a virtual macro within which the GLSL Shader would be at the top level. However that would then surely mean that rather instantiating something that is both virtual and usually chiseled in stone - fixed, albeit often configurable, that one would initially have the predefined coding within the GLSL shader potentially changed. Won't that directly or indirectly affect the original virtual macro, since that is the only level as of right now where I can change what's going on in that virtual macro. Yet it's ironic to note that dragging a .qtz to the stage represents us with an editable , embedded copy of that .qtz composition, so in a way, what is definitely true for what is bound within a consumer patch presently, could, I guess, if given a clear and separate means of representation, which allows for non-destructive to an originating .qtz macro, editing of that represented instantiation of that macro and placing within that programmable environment fresh objects for consequent rendering. An exception to the general rule regarding programmable patches and also environment patches in virtual macros. BTW does it break some unwritten rule to publish up a bog standard Core Image output to root from within an environment patch ? Some rule about protocol compliance affecting something that seemingly simple. I certainly can't get that done. As it happens, I wasn't specifically addressing the exotic objects observation at the question of the GLSL patch, but more about my experience to date with virtual macro success and failure and the use of unregistered patches and the more exotic patches - just seemed generally pertinent in regards of those often unwritten rules and limitations of what works with what and how in QC 4. For instance, the 'rule' that a GLSL patch can't be utilised as a container patch, albeit that one can as it were compress a specifically well thought out GLSL composition into a Consumer patch virtual macro and always have that available, of course it wouldn't be the same as being able to change the innards of the GLSL patch, as well as changing its textures and such. I'm not even sure if it is a rule but it surely feels like one . Cheers, Peter On 17 Mar 2010, at 22:00, George Toledo wrote: > > > 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]
