vvvvvvvvvvvvvvvvvvvvvvvvvv

cwright's picture

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 :)

PreviewAttachmentSize
vvvvvvvvvvvvvvvvvvvv.png
vvvvvvvvvvvvvvvvvvvv.png309.45 KB

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

danwinckler's picture
Re: vvvvvvvvvvvvvvvvvvvvvvvvvv

Interesting. Did you do it with an unofficial SDK hack or an Apple API?

cwright's picture
yes?

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.

gtoledo3's picture
Re: vvvvvvvvvvvvvvvvvvvvvvvvvv

Gnarly. Hmmm. Not sure what I think! Cool though.

Darn...this IS cool... how soon!??????

smokris's picture
Noodle mouse tracking

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.

gtoledo3's picture
Re: Noodle mouse tracking

Mmm, that is a genius observation, on highlight!

yanomano's picture
wow really interesting

i have already signaled problem with lot of connexions....and this should be faster to draw like this ;) Can we test ?

Michael Neely's picture
Re: vvvvvvvvvvvvvvvvvvvvvvvvvv

I have no idea what Noodle drawing is. Pardon my ignorance, but I am curious now.

gtoledo3's picture
Re: vvvvvvvvvvvvvvvvvvvvvvvvvv

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.

gtoledo3's picture
Re: Noodle mouse tracking

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.

dwskau's picture
Re: wow really interesting

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...

Michael Neely's picture
Re: vvvvvvvvvvvvvvvvvvvvvvvvvv

Thanks. I make noodle drawings all the time!

gtoledo3's picture
Re: vvvvvvvvvvvvvvvvvvvvvvvvvv

Lol....

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!).

jersmi's picture
Like the audio app Plogue Bidule...

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?

cwright's picture
Re: vvvvvvvvvvvvvvvvvvvvvvvvvv

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.

jersmi's picture
Re: vvvvvvvvvvvvvvvvvvvvvvvvvv

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.

cwright's picture
Re: vvvvvvvvvvvvvvvvvvvvvvvvvv

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.

gtoledo3's picture
Re: vvvvvvvvvvvvvvvvvvvvvvvvvv

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).

haha

dust's picture
Re: vvvvvvvvvvvvvvvvvvvvvvvvvv

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.

jersmi's picture
Re: vvvvvvvvvvvvvvvvvvvvvvvvvv

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.

toneburst's picture
Re: vvvvvvvvvvvvvvvvvvvvvvvvvv

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.

a|x http://machinesdontcare.wordpress.com

cwright's picture
Re: vvvvvvvvvvvvvvvvvvvvvvvvvv

"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.)

jersmi's picture
Re: vvvvvvvvvvvvvvvvvvvvvvvvvv

thanks so much for the detailed explanation. really helpful.