Hi Rick, another idea would be moving the image loader patch, which is inside the macro, to the root where your other macros are located which are depending on this image. You then feed the image to the macro rather than an URL (I assume).
best, Achim Breidenbach Boinx Software On 22.02.2011, at 00:27, Rick Mann wrote: > > On Feb 21, 2011, at 15:25:41, Charlie Francis wrote: > >> Is the layout dynamic? If not you can just hard code the widths. > > It's not dynamic during the normal operation, but the guy I did it > for...changes his mind a lot. So, the easier it is to re-arrange, the better. > >> I did something simliar where I put the a billboard inside of a render in >> image patch. You can then set an output of the total width, which I then fed >> back through to the same render in image patch. It screwed up a bit when >> changing size on the fly, but worked pretty well when the composition loaded. > > That's a good idea; I'll try that. Thanks! > > -- > Rick > >> >> Hopefully that might help. >> >> Regards, >> Charlie >> >> On 21 February 2011 22:17, Rick Mann <rm...@latencyzero.com> wrote: >> I understand the difficulty. I'm still facing many like it in my own plug-in >> app (which I think I've mentioned before). >> >> In this case, I'm building the clock display seen here: >> >> http://www.spacevidcast.com/live/ >> >> For the next couple of days, you'll see two clocks at the bottom. My .qtz >> (and a couple custom patches) render the black bar at the bottom, the >> gray/white bar with blue logo, the green/white bars with clocks, and a >> blue/white bar that will cover the right-borrom half of the screen when the >> count reaches T-1 minute (it shows six rapidly-changing ascent parameters). >> >> Each of those sections is a macro in my composition. I use the anchor and >> image dimensions patches to stack them left-to-right, anchored on the >> bottom-left corner. What makes it difficult is that each one needs the >> previous ones' widths, and that width is really only known within the macro >> (it loads the image). I wish there were a way to get that width out for use >> by the other macros, or the parent, in laying them out. >> >> Perhaps there's another way to accomplish this type of layout that I haven't >> thought of. >> >> -- >> Rick >> >> On Feb 21, 2011, at 08:59:11, Christopher Wright wrote: >> >>>> Wouldn't that just lead to that macro being one frame behind? >>> >>> It's undefined. It could be 1 frame behind (as in, a consumer won't >>> actually execute upstream consumers?), it could render out of order (as I >>> outlined previously), or it could even double-render (layer 1 executes, >>> layer 2 executes, which requires layer 1 to execute again? this case is >>> admittedly a bit contrived, but you can hopefully see how it could >>> plausibly happen). The current implementation does what I said (out of >>> order) iirc, but it's forbidden anyway so you can't actually see for sure >>> (This was possible in Tiger, but never since, so things may have changed >>> enough to change what it'd do if it were allowed). >>> >>> It's difficult to know which is "best" -- I'd favor macros not logically >>> changing the graph, but that has other pitfalls. Maybe just enforced layer >>> ordering would be possible (as in, upstream consumers _must_ have layer >>> orders lower than downstream consumers). This would give a weird interface >>> though (to a new user, it'd sometimes work and sometimes not, leading to >>> more discussions like this, which crop up from time to time anyway ;) >>> >>> -- >>> Christopher Wright >>> christopher_wri...@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/rmann%40latencyzero.com >>> >>> This email sent to rm...@latencyzero.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/charlief%40cellcastonline.com >> >> This email sent to charl...@cellcastonline.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/achim%40boinx.com > > This email sent to ac...@boinx.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
