This brings up a topic I've been thinking about lately--I often wish I could make connections that had a bit more metadata to them. For example, knowing that a particular input expects figures between -100 and +100 would be handy to me in composition sense.
A friend who *can* code explained enumerators to me the other day (which I don't believe QC supports?) which seems to make a lot of sense to me, and seems related to my above request. Forgive my ignorance, but does this concept have a general name in coding? That is, providing the 'expected input data range' as part of the input metadata available to the code/patch creator. Many thanks Keith On Thu, Sep 24, 2009 at 2:52 AM, Christopher Wright <[email protected]> wrote: >> Thks Cwright, >> That sounds neat, I'll be giving that a shot next time for sure. I >> couldn't enjoy QC without KinemeCore! You'd think kind of think divide by >> zero or unreasonable iteration requests (based on memory) would be detected >> and handled by QC given how excellent XCode environment is supposed to be. >> Perhaps it's better in QC4. Javascript crashes are my fav of course. > > > I personally haven't had any problems with divide by zero (now, atan2 in > Leopard, on the other hand... that's a crash) -- can you describe that some? > > The problem with "unreasonable" iteration requests is, what exactly is > unreasonable? is 10000? is 50? what about 3000001? I will say that I > wish iterators were smart enough to notice if they had no subpatches, and > thus skip everything (once I made a mod to the iterator to do that, but then > realized that it's 99% useless since no one's going to have an empty > iterator sitting around doing a bunch of idle iterations), but even then > it's doing extra checks for a case that isn't normal (empty iterators serve > no purpose). > > If you're doing non-realtime rendering with QC, you won't care if it takes a > hour per frame (well, you could care, but it won't kill you). > > Randomly halting iterations at some arbitrary limit would be annoying, > especially if you're near the edge (sometimes it's fast enough to work, > sometimes not). > > The "correct" solution (wow, I sound like a comp. sci. professor) is to have > all rendering/graph evaluation take place on a thread that doesn't also > handle UI events -- then it can take all the time it wants, and the UI will > still respond. Then you just have to deal with syncing with the render > thread whenever the graph is changed (and you could flag the renderer thread > as "stale" so it'll stop doing stuff -- this won't save you from infinite > javascript loops, since webkit's javascript evaluation stopper isn't public, > but from other stalls it can help you out). > > I _think_ the initial Snow Leopard seed in 2008 actually had that set up (a > bazillion iterations wouldn't freeze the UI), but it's not like that now in > Snow Leopard -- either I'm mis-remembering, or it got reverted, or there > were some other side effects that made it less than "correct". > > -- > [ christopher wright ] > [email protected] > http://kineme.net/ > > > _______________________________________________ > 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/songcarver%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]
