Effect chain iterations

itsthejayj's picture

Hi Guys could someone have a look at this composition as I'm sure i'm doing something wrong here! And would love to see how you guys would go about this one.

I'm in essence trying to make an dynamic effect chain. Say i have a bunch of image filters (i'm using the ones from the comp repository for this example) i would like to effect an image/movie dependent on the order of the effect comp and if the effect comp is enabled.

Dynamics is key as ever (however i can imagine the comp loader is a performance dog within an iterator)

Thanks as ever.

PreviewAttachmentSize
effect_chain.qtz745.17 KB

dust's picture
Re: Effect chain iterations

was actually thinking of this type of thing this morning. have been wanting to make a simple vj type of app that i can use my axiom to trigger clips and what not. if i get what you mean i 2 have been thinking of a way to dynamically add image filters and have the various input parameters generically map to my knobs all in QC.

im not really sure if it is possible to dynamically publish something from inside QC but i think the composition info patch in combination with the repository patch would be the first line of investigation.

like parsing the parameters structure to generically map to a param1, param2, param3 etc.. with the info patch you could actually test for type and then possibly sort. like param 1 and 2 could be set to be always offset x and y and param 3 is always amount etc.. the structure sort lets you sort by key so if you pass attributes to the repository or parse inputs by type i think it is defiantly possible.

i guess to try you would want to pass the location from repository to info get attributes from info and feed back into repository or just parse inputs to generic parameter controls. i will see what i can come up with as i was planing on doing something like this today, or well after i re calibrate the multi-touch table in the lab.

cybero's picture
Re: Effect chain iterations

Cheers for this, a real eye opener regarding the use of the Composition Repository Utility. Just beginning to get into the use of this particular patch.

usefuldesign.au's picture
Re: Effect chain iterations

I've only played with Composition Loaders out of curiosity. I've used Virtual Patches a lot more. Can anybody point out the advantages of the various Composition Loader options over Virtual Patches. What's the essential point-of-difference going down here.

I've always wondered if Virtual patches/ Loaders etc have memory or performance advantages over a Macro in your composition. I think an answer cwright provided me on Virtual patches said the performance characteristics are pretty similar to a Macro (I need to find a way to catalogue cwright's advices for future ref perhaps we can cover these things in a Kineme !FAQ — but very good to ask questions)

Do we at least get a speed up in the QC Editor itself when using a method that 'hides' the patches out of sight?

itsthejayj's picture
Re: Effect chain iterations

Sorry i was abit wage on this one, when i mentioned dynamics i meant inside the iterator, i'm using a few 'render in image' macro that should really be iterated i'm just not too sure on the javascript to use. I'm not bothered about dynamically publishing ports that done inside the application so to speak, can't imagine this ever being 'dynamically' possible in qc. The question was generally directed at how i was feeding back the image inside of the iterator to layer up the effects, it doesn't seem too efficient, things might be being iterated too many time etc. Plus i'm having to use that dummy billboard which just seems so wrong. Contextually i'm trying to mimic the audio device chains in Ableton live

itsthejayj's picture
Re: Effect chain iterations

Wasn't my intention by hey, i really like the protocol idea within QC, keeps things tidy. I'll dig up some composition that reply heavily on the repository and protocol to add to the kineme online repository soon.

itsthejayj's picture
Re: Effect chain iterations

Comp loader vs virtual patch, for me i use comp loader for recycling composition that conform to a certain protocols 'image filters' 'graphic animations' etc and shared within different applications, much like a virtual patch (update the root and all the branches update too) . I've found its a huge performance advantage for the QC editor. But the main advantages here should be dynamics... but the comp loader seem to be fooked in an iterator (apple please retrofitted with iterator state sanity stuff).

For my JAM project i'm going crazy trying to use comp loader everywhere to keep external compositions customizable for you guys but i keep getting weird green tearing, i must be running out of vram or something!?

usefuldesign.au's picture
Re: Effect chain iterations

Okay have to admit I haven't examined your comp yet. Need to follow this up as still can't see clear line of difference between loader and virtual (except for protocols conformance filtering as you mentioned).

gtoledo3's picture
Re: Effect chain iterations

Green tearing? Can you expound? That doesn't sound right.

gtoledo3's picture
Re: Effect chain iterations

I loader lets you load an arbitrary file path dynamically during runtime . A virtual patch is something that loads into your library at runtime when QC starts, because it's in a folder and qtz's are "QCPatches", so they get loaded. If you use a virtual patch in your qtz file, there is info about the hierarchy of the patch that gets loaded "into" the qtz plist. This doesn't happen with a composition loader. Everytime you trigger a composition loader to reload file path, it is the same as starting a comp from the beginning... this is revealed by some patches that don't work quite correctly, like Interaction in SL. Whereas, I can "move" something with interaction in SL, restart composition, and the moved objects restore where I left them. The comp loader doesn't do that, but acts as if I ran from the top.

There is no "dynamic" aspect with virtual patches. I can load a patch, run it, then open it up, edit it, save, reload, and changed are reflected with a composition loader. With a virtual patch, you need to restart QC.

Composition Loaders don't filter protocols. Again, to make it clear composition loaders don't filter protocols, they can just be configured to have the stock input and output ports of a given protocol... which can oftentimes be very useless as is. One can absolutely feed a non matching protocol composition to a composition loader, and it will produce a graph error at that point.

usefuldesign.au's picture
Re: Effect chain iterations

Okay comprehensive answer, thanks. This answer needs to go in the QC !FAQ Wiki.

itsthejayj's picture
Re: Effect chain iterations

Ok best i could do with this one, again if anyone has a better way to doing this please give me a shout.

Composition Loader is (as you would expect without Apple Magic) a no go inside an iterator ;(. So for the example i hardcoded a bunch of the image filters!

  • what shall i call this composition for the kineme repository?
PreviewAttachmentSize
effect_chain_dynamic_hardcoded.qtz934.99 KB

gtoledo3's picture
Re: Effect chain iterations

I think you could bug test this one for awhile before committing to the repository... aspect ratio problems on startup and offset change doesn't always respond; composition on screen won't change/listed name is different.

What is the point of the iterator? edit... oh, for dynamic layer count. Hmm.

PreviewAttachmentSize
composition repository.qtz8.36 KB

psonice's picture
Re: Effect chain iterations

No time to check the original comp to see what you're on about, so apologies if this is way off the mark, but this is how I did something that sounds like what you're after (no iterator, but it would work fine inside one).

Basically, I had a 'pipeline', with say 10 stages. Each stage can apply any one of a number of effects to the image, then pass it to the next stage.

All I do inside each pipeline stage is create a macro for each filter, and use a multiplexer/demultiplexer to push the image into the right filter and get the output back again. Simple and fairly efficient.

This way each stage has a single image input, and a single output to pass to the next stage. I set index 0 for the multiplex/demultiplex pair to be a straight passthrough for when there's no effect selected.

Parameters for the effects I handle by normalising to 0..1, and having a few generic inputs connected to all of the filters.

gtoledo3's picture
Re: Effect chain iterations

Along with normalization (happening inside of the comps you load), the point made somewhere up above about passing info to the params with just a published structure is a good one. So, you just publish a structure type, and connect a different structure index or key to each input port that needs to be controlled.

dust's picture
Re: Effect chain iterations

you can always use an interpolator for an iterator if you can not use iterator. like use one iterator looping for position and another set to not loop for indexing. that is just if you want to get through structures and what not, it won't let stack images by offset etc...

call it "effect chaining"