Front Page Posts
Was poking around a bit with noodle drawing, and came up with this vvvv-esq noodle set:
Not sure if it's useful or anything, but kinda weird I guess :)
Interesting. Did you do it with an unofficial SDK hack or an Apple API?
yes? or neither, I suppose.
this could be accomplished with either. By preference, I used the unofficial SDK.
the official api is only for patch plugins -- a very very restricted set of functionality. the unofficial sdk is still just for patches, but with some extra runtime magic on top, we can modify anything within the QC app itself. the magic could go in either, it's not really tied to an api.
Gnarly. Hmmm. Not sure what I think! Cool though.
Darn...this IS cool... how soon!??????
Very cool. If this method draws significantly faster than the standard Bézier paths, it might be handy for editing those insane monster compositions.
Another thought: could we track the mouse, and use that to dynamically highlight noodles (make them glow with a white outline or something)? I know that QC natively does something kinda like this when you select patches, by greying out unrelated paths.. But doing it just on mouseover for a single noodle would be more useful in tracing routes, I think.
Mmm, that is a genius observation, on highlight!
i have already signaled problem with lot of connexions....and this should be faster to draw like this ;)
Can we test ?
I have no idea what Noodle drawing is. Pardon my ignorance, but I am curious now.
This just refers to the standard hoses/noodles/spaghetti looking things that connect input and output ports. It seems like the term noodle drawing is most frequently brought up in discussions of compositions with a million noodles in a macro, where people tend to question whether it bogs the system or not.
Again, that little highlight idea is a gem. I've had it on my mind since I read the comment. I would actually love if you could "highlight" with some kind of other key to "keep" the noodle highlighted, until you "un-highlited" it. This would really help when you are inspecting input/output pairs that are really far from one another, where you have to scroll and such to get from one point to the other. I usually end up just zooming out, but that's not always favorable.
Come to think of it, a zoom with more steps of resolution wouldn't be bad either. Sometimes the jump between zoom steps is egregious.
I second the test request. If that draws any faster, it would make my life so much better. That huge composition image I posted in the zooming/navigation post is an ongoing project and if I zoom to see the extents of the composition I get a 3 seconds per frame rate when dragging a noodle. I have a 1.5ghz G4 PowerBook...
Thanks. I make noodle drawings all the time!
btw, I am a requesting party that doesn't care a flip about if it's faster. I just think it looks better. The curve inherent in the noodle can obfuscate things, and this method is nice because a sharp angle is naturally easier for the eye to derive info from (I believe at least!).
This reminds me of my favorite audio app, Plogue Bidule. Their interface has options for changing the connector cables from bezier to straight lines like this. And I think their OpenGL interface is quite nice to look at. Although there is some conflict with Bidule and QC-- when QC is open and I switch back to Bidule, sometimes all Bidule's module names disappear!
Does this mean you could give us a template for making QC skins?
Holy crap, 10 seconds of goofing around, and all this discussion ensues :)
Q: Is it faster? not particularly. I haven't tried it on any monster compositions though, so maybe I'm mistaken. I'm also drawing about half as much (the built-in noodle drawer renders to bezier curves: one that's grey, and one that's colored on top. This one only draws a single line).
Q: Templates/Skins? Not really. There are a bunch of drawing things that we haven't touched yet, and they're all in-code (so templates/skins would require software, or perhaps a software layer could be written that uses resources or something -- not likely to happen before Snow Leopard arrives and changes everything again)
Q: Naturally Easier. I would have thought so too, but it's more difficult than I expected -- perhaps because my brain's used to tracking curved noodles.
For the future, perhaps I'll make some kinemeCore options for simple noodle drawing or something.
i know it's audio, but referring to Plogue Bidule might be worth your while based on some of the functionality of Bidule's cables:
-- can plug in more than one cable to an input (values from multiple cables attached to one input are added together). this is something i wish for a lot with QC.
-- can (drag a box or shift) select multiple cables (to delete).
-- holding shift while connecting an input connects all available inputs (even if the operation will crash Bidule-- the pros outweigh the cons, imo).
-- copy/paste applies to modules and selected cables, although i could see disasters waiting to happen applying this to QC. it does add speed to the workflow, however.
Multiple plugs to input doesn't make any sense in QC's context -- lazy evaluation makes this nonsensical.
selecting cables would be awesome. QC doesn't have any conventions for cable selection though, so that's very difficult to accomplish.
Crashing an app is never satisfactory, ever. Connections in QC are smart enough (generally) to not plug in where they'd cause explosions (though some tricks can work around this). Nor sure how often I'd use multiple plugging in QC.
I'm torn on the copy/paste connection thing -- on the one hand, it's a cool idea that would save lots of time in many instances. On the other, it's extremely difficult to implement (because copy/pasting already preserves some noodle state, we'd have to modify those without breaking anything, which is rather risky), and we'd have to duplicate what apple's already done, plus some minor additions. Tricky stuff.
cwright wrote: Connections in QC are smart enough (generally) to not plug in where they'd cause explosions (though some tricks can work around this).
i kind of like the bezier curve noodles of QC and plogue bidules, but if you are going VVVVV style, might as well do segmented patch cables while your at it, and go for that tidy circuit board look. im glad there are not any arrows would feel to UML ish.
multiple plugs to inputs i guess applies mostly in a simple way to math/numerical patches-- e.g., plug multiple triggers with different timings to a sample and hold, create intermodulation with lfos/interpolators, things like this. of course where there's a will there's a way. granted, half-baked here.
I vote for segmented noodles, vvvv-style too. How about the ability also to recolour the noodles too? Which would make tracing what goes to where much easier. Maybe mousing-over a noodle and right-clicking could bring up a contextual 'Noodle' menu, with colour options and maybe a list of possible connections, left-clicking it would select the noodle for deletion, and double-left-clicking would select the patches at either end of the noodle. Or something.
"triggering" is why it doesn't make sense in QC -- each patch will "execute" its inputs when it needs them (due to a frame being rendered), so having 2 would make one of them lose. Everything is tied to QC's bottom-up execution model, which is why I said it doesn't make any sense.
Take a simple example:
Input Splitters A, B, and C.
Math Expression Patch, with the Expression set to "X + Y", with both A and B going to X, and C going to Y.
Then, a Sprite with Width attached to the result of the math expression.
When this composition executes, it starts with the sprite. It notices that the sprite needs its width calculated, so it travels up the noodle, to the Math Expression patch, and tries to execute that. The math expression patch needs its X and Y inputs calculated, so it travels up the noodles, and executes the splitters, which provide value. Both A and B will be executed "at the same time" (relative to QCs frame time), so only one of them will ever take effect.
If it was top down (what you're probably think it is), splitters would shove out values all the time, or randomly, or based on some other criteria. The math expression would add whatever it was fed last, and output that to the sprite, which would render when it got input. This way, if A or B didn't provide anything, something cool could still happen.
The latter case also sucks incomprehensibly: let's say you have a core image filter chain that's 60 filters long, and extra extra slow. And then you disable the sprite that it's attached to. top down will execute those filters right up to the sprite, wasting all that processing time for nothing. (Developer's Note: CoreImage is actually lazy-eval too, so having a bunch of filters that never render wouldn't actually be that expensive.. there's some overhead from patch execution+bookkeeping, but that's about it). QC Doesn't work this way because it's not as efficient (though it's handy for some cases, especially audio where stuff flows in, and then has to be processed as it arrives.)
thanks so much for the detailed explanation. really helpful.