Thanks Adrian, This is helpful, I have been saving in increments and reverting to previous saves quite a bit on this project. Thought it was just my confusion causing issues but I've felt some patches in particular can get into a bad way, and yes frequently using clipboard and duplicate on multiple patches including 3rd party ones (Kineme *Sp⧞ky* co-incidentally). Something to consider.
Thanks for the CC link didn't even see it till cwright underlined it. Boy I must be flakin' out. 2009/6/27 Adrian Ward <[email protected]> > > If you're seeing weirdness in one composition but not the same behaviour in > another that you freshly create then it sounds like a condition of the QTZ > being corrupt/saved in an inconsistent state. I've seen this happen > especially when the clipboard use/plugins are involved. > > This is far from helpful but I've had a massive, complex composition go bad > after making a slight change. The only way I found to fix it was to go back > to an earlier version from backups and recreate the changes from scratch. > Second time round no problems. > > Ps. Check out <http://creativecommons.org/license> > creativecommons.org/license > > > On 27 Jun 2009, at 08:00, Alastair Leith <[email protected]> wrote: > > Okay I'm going work on that and post it after this weekend. It isn't easy. > At one point I had a boolean splitter going straight to the enable of 4 > spheres and TRUE not enabling them. When I copy&pasted the 5 patches (which > had NO OTHER INPUTS) to a new blank comp, they worked A-OK. LOol! That's > the second head growing out of my shoulder in mad frustration btw. > I intend this series of Marcos to be open source and maybe the basis of a > plugin if someone with the chops cares to do so. Just wanted to keep my > powder dry and all until I had them up and running. Can anybody advise what > License or © text to use so people are free to use and modify but not > exploit in commercial ways (like sell without my consent)? > > One of many reason I use Macs is because I can get the gremlins running > (when I've used PCs in other peoples studios I've had their PCs give > kittens). I have been experiencing some weirdness in QC the last month or so > and am not sure it isn't my venerable Mac having a laugh on me. If in knew > more QC stuff I could say if it's abnormal or not. Massive slow-down on save > dialogue is one recent oddity. Reboot solved it. > > > 2009/6/27 Adrian Ward < <[email protected]> > [email protected]> > >> >> Hi Alastair, >> >> Can you reduce your composition to the simplest possible state where the >> problem is still observable? If so, post it to the list. I'd certainly be >> interested in seeing why you're getting a different output from an input and >> I'm sure you'll get some more help with an actual example out there. >> >> Sorry my suggestion wasn't much help - hope it's not driving you too nuts. >> >> Best, >> >> >> Ade. >> >> >> On 26 Jun 2009, at 09:50, Alastair Leith wrote: >> >> Thanks Adrian >> I've been re-patching the splitter when required (can be annoying can't >> it). I have used iterator patch (iterations=0) to keep the upstream patches >> "active" so I don't think it its the lazy evaluation unless it's lazy >> evaluation going screwy (to be quite technical!). Thanks though. >> >> 2009/6/26 Adrian Ward < <[email protected]> >> [email protected]> >> >>> >>> If you enable/disable consumer patches (purple ones) then this affects >>> all upstream patches. When disabled, anything before it that doesn't need to >>> be executed won't be, meaning it's output value can become stale. I suspect >>> you're seeing this when you spot a diference between the input and output >>> vales of a splitter. >>> >>> Another thing could be that when you change the type of a splitter, >>> connections to/from it can be removed. I'm not sure why this is - I'm >>> tempted to file a bug report because it's only a nuisance and not very >>> functional behaviour. Perhaps you've inadvertantly severed a connection >>> somewhere without realising it? >>> >>> >>> A. >>> >>> >>> On 26 Jun 2009, at 06:42, Alastair Leith < <[email protected]> >>> [email protected]> wrote: >>> >>> I've got issues with a patch where Boolean values can be processed thru a >>> chain of patches okay but when the value *type is changed to* *any other >>> type (say number) and then back to Boolean it will not work.* >>> >>> I have the strange result of a True value on one side of an Input >>> Splitter Patch and a False value on the output node. I've noticed this can >>> occur at various points down the line of patches where it is true in on a >>> splitter and false out. >>> >>> I'm working on a macro that can process any kind of value (virtual) like >>> image, number, QCstrucutre and so on. The values pass through the macro to >>> output un-changed but can be recorded sent or substituted in various ways. >>> All the values types work fine except Boolean. >>> >>> I remember cwright posting @Kineme there is an issue in QC with the way >>> Boolean are treated re: something else entirely, just wondering if there is >>> a know issue causing this mal-functioning and if there's a known ways around >>> it. >>> >>> <true in.jpg> >>> >>> <false out.jpg> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Quartzcomposer-dev mailing list (<[email protected]> >>> [email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> >>> <http://lists.apple.com/mailman/options/quartzcomposer-dev/adrian%40clayinteractive.co.uk> >>> http://lists.apple.com/mailman/options/quartzcomposer-dev/adrian%40clayinteractive.co.uk >>> >>> This email sent to >>> <[email protected]><[email protected]> >>> [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]
