Starting points for learning to use image outputs

The version of the template available from here is a pretty old, and missed a lot of stuff for image ports and everything for OpenGL acceleration. I can polish off our internal template and let you run loose with that if you'd like :)

Maybe it'll get it up to release grade for all to benefit from.

As an aside, you might want to also link in the QuartzCore framework, but that won't help you here. The anon structs are output from the program we used to reverse engineer the QC interfaces, so it's not defined in any header.

Yes, I'd like that very much. I'm imagining that so would others, if they knew of the possibilities that this opens up. If examples / notes / tutorials on image outs could be a result of this, I think that we'd eventually see some interesting patches.

The reason why I'm doing this is that I have a QC VJing patch I use. I've already had to do a cocoa clip bank / controller app, am working on a dedicated DIY hardware interface (with the Arduino) and now I'm trying to expand into generative patches, not just Quicktime movies. I've looked at Processing, but it can't be integrated into QC, and the other way around you take a performance hit (as well as lose the Cocoa controller app that provides nice things like thumbnails of sources).

Through all this, I've managed to find the needed info in tutorials and documentation on Cocoa even though I'm not really a programmer. Something like your template would be very valuable in that approach.

In the end, I'd like to do some particles / boid type 3D stuff, maybe in raw OpenGL. I've even read that Cocoa can instantiate a Java Virtual Machine, so maybe something like an "Image With Processing Sketch" patch could be written by someone a little more clever than me.

Some other things I frequently find myself using is a "toggle on/off" patch, common boolean logic, and a subpatch that only sends out the last received of many outputs (a bit Max-like, I suppose). I've had to implement these in Javascript, but have always had the feeling that there would be a cleaner way of doing it. Now it should be possible!

Finally, I have a "Timecontroller" Javascript patch that could use a rewrite. It enables movie playback with play rate, freeze, jump to position and restart. If I could make this generic enough, I'm guessing it would be of value to others, as well.

Thank you for the offer and keep up the good work.

Hello again.

Sorry if I went on a bit of a rant there last time.

I've been working / exploring the last couple of days, to see if I can understand these things. The result is the Toggle patch that I've so often needed.

It can be found here for the time being. Source is included.

If anyone more experienced with this has a few minutes to look over the code or test the patch, I'd be very grateful. I've had to disable the compiling for i386 until I get that problem solved, so if you're on an Intel machine you'll have to go to Project>Edit Project Settings and add i386 to the architectures setting, and then rebuild.

If you notice any glaring errors or misunderstandings, I'd like to know, so I can read up on things.

I'm still looking forward to looking at the updated template. Plus, it'll be exciting to see what will happen once Leopard is out. I realize there are NDA's, but I've heard that exciting things are going to happen with Core Image / Quartz Composer.

Looks good from what I've seen :) Simple, yet very useful.

It tries to compile on my machine, but it looks like it deletes the icon.rsrc file when it finishes, so it doesn't build. I have no idea what would cause this. Copying the files to a new project would probably work (I'll give that a shot in the morning) [I have an Intel Mac, btw. Adding i386 doesn't seem to change the result]

QCLeopard, from what I hear/have gleaned, will be incredibly cool :) I can't wait :)

After downloading the lates SDKs, and the latest QC patch template kindly provided by cwright at this page (hope you don't mind the link), I've now succeeded in making the Toggle patch a Universal Binary.

Plugin and

Source

The above link doesn't work anymore.

thanks - that'll mean a lot less javascript from now.

boolean logic can be done with the mathematical expression node. its unbelievable its a hidden node, its both a swiss army knife and makes the patch readable by naming its inputs according to your expression. its got the ternary operator (ie x>y?yes:no). i totally rely on it to keep my patches sane (well, everything is relative).

Glad you like it - it was something that IMO was always missing, along with the ability to connect multiple outputs to one input, but then I came to QC straight from Max.

Just out of curiosity, are you on an Intel machine? I can't test the Intel part myself.

Regarding boolean logic, I overlooked that there's an official patch of that name that works pretty much as you'd expect. I will be sure to check out maht expression, that sounds great.

curiosity - yes, and yes it works

I've never used Max, and probably won't in the near future, but I am interested in hearing how the multiple output to one input thing worked? Did the receiver just treat all the inputs as a single larger set? (kind of like spreads in vvvv)?

franz and I have discussed this (the vvvv version, at least, which maybe doesn't apply here), and the possibility of duplicating this functionality in QC by making some custom ports. Hearing how other programs handle it could give some interesting ideas for our eventual implementation.

Hmm.. I'm not sure I understand vvvv's concept of spreads. And I was never that good at Max, but I'll try to do a short explanation from memory:

In Max, you basically have objects and messages. Objects are the functional patches that do something (and are written / compiled in C or C++), messages are what the user and objects themselves use to communicate along the patch cords. So a typical message could be something like "play a note". This is of course paraphrased.

Most of the simpler objects have their inlets (input ports) mapped directly, so that a comparison has two inlets that you can send numbers to (you can also write a number + operator and just use one inlet). For complex objects, like the ones having to do with Quicktime movies, this is simply not practical, as they have something like 50+ parameters, states and settings. So you just use the first inlet for most of them by sending messages like "playrate 0.2", "cache true", or somesuch.

The thing I missed when first working with QC was Max's ability to connect multiple cords to one input. So you might have a movie object that had both a "playrate 1.0" and a "playrate -1.0" message connected to the same inlet, and the user could then click these messages as part of the interface. The click sent the message, and the player object would use the setting until the other was clicked. IOW, it only uses the last message received, no need for complex logic and multiplexing etc. By contrast, QC seems to use whatever value is present at the input at the time of evaluation.

This is, I think, a fundamental difference, and the Max method is less intuitive but enables some neat tricks. Most objects are evaluated only when they receive a message (an empty message is referred to as a "bang"), so IIRC you had to connect a metronome object to the movie player to make the movie run. This method also brings some counter-intuitive complexities with it, in that the order of execution is important. Max executes the objects that are placed leftmost in the patching environment first, so sometimes a patch behaves radically different if you move a single object two pixels.

Whew, that ended up kind of long. Hope this is mostly correct, as it's been a while.

I'm thinking that maybe for my next project I should write a sort of auto-multiplexer patch that sends the input on that changed latest, as I always end up doing this in JS anyway.

This sounds like it's QC, but in reverse. In QC, things evaluate "backwards" from a renderer. If there's no renderer attached to a patch, it doesn't get called at all. So, data is 'pulled' from left to right. Max sounds like data originates at generators, and gets 'pushed' to renderers, if there are any, and if not it gets called anyway.

Not sure if QC's really designed for this kind of operation. Both approaches have their pros and cons (lazy evaluation for QC, intuitive operation for Max).

Also, QC stuff evaluates every frame, even if it hasn't changed. So it doesn't have a 'last message' kind of paradigm...

Cool explanation though, thanks! :)

Ah, that makes sense!

Explains why I had to connect to a billboard at alpha 0 when messing with the structure patch in order to use it "offline".

So, an auto-multiplexer would have to somehow let the inactive inputs know not to evaluate to get the best performance. Any idea if the official multiplexer does this?

Wait, that wouldn't work, as you then wouldn't know if the inputs had changed. Anyway, the JS patches I regularly use for this have to be less efficient and more of a hassle than an Obj-C implementation. This project is some way off, regardless.

(this discussion is getting rather narrow, graphically, and off-topic. Great talking to you though, I'm learning!)

Also, QC stuff evaluates every frame, even if it hasn't changed. So it doesn't have a 'last message' kind of paradigm...

does it? not sure about others, but the javascript patch will only run its code if an input changes. its pretty easy to test that, and coincidentally, is how you make the javascript version of the toggle node.

toby

HI, it's a great addition you've done, and it's working as expected, here, on a Mac-i. Thank you very much for this. However, for portability of patches using such an obvious function like this, i tend to prefer to use a: "Counter" patch + "Math" patch set to modulo 2, which acts like a, say.... toggle.

I don't know how you coded it internally (i'm a lazy boy who can't read the sources...), but it would be intersesting to know EXACTLY how much cpu power is consumes, and then compare it to the regular QCway of doing a toggle.

Any hint on a way the measure up each node's CPU comsumption ? (I am off topic here sorry...)

We could write a profile macro that would tell you how long the set of internal patches takes. This wouldn't be too difficult.

With a bit more study (i.e. figuring out any trickery involved in executeSubpatches), we could also get it to profile individual patches. Assuming this isn't in qcLeopard, it might be a handy addition to other patch developers as well.

First off, glad you find it useful. But yes, you are right, the count/modulo combo is a great solution that works in standard QC. I've never thought of that and have used JS in stead. Must be very inefficient in comparison.

The patch uses one internal variable, a boolean. I don't know how this compiles, but I'd think that it takes up one byte. Then there's two conditionals (if statements). I won't claim to be any sort of expert on programming, but my guess is that these operations are dwarfed by the overhead of instantiating this simple code as an object, and initialising, managing connections etc. But then you get double this overhead with two objects. That's my guess, but Pierre-Oliver Latour, the author of QC, is obviously very competent and might well have worked some voodoo on the official patches.

I second cwright, above, where he says a profiler could be interesting. We might have to do something like the old Mac benchmark "let 1000 windows bloom", that opens and closes 1000 windows. Something like generating a composition with 1000 toggles in series, connected to a billboard, and look at the frame rate / CPU load?