Quartz Composer Timelines Patch

This quartz file import a XML file from twitter timeline. Thanks Miyazawa kenji bot, which made by @hpa. Fortunately, I recorded BGM at Yuigahama, Kanagawa Japan.

[] Using Quartz Composer patches with VDMX5 We at Vidvox really like Quartz Composer: it's free, easy to pick up, and offers people with absolutely no programming experience a comfortable way to create stunning interactive pieces. As such, we do our best to support the aspects of it that we think are most advantageous- its ease of use and interactivity. There are several different ways to use Quartz Composer with VDMX: The quickest way to get your Quartz Composer patches doing something in VDMX is to simply drag them into a media bin, or choose 'Import Media' from the file menu. Your QC patch may then be triggered and played on a layer just like any other video file. Quartz Composer patches can also be made available as resources that VDMX5 can use to process (FX), control (plugins), and otherwise handle playback of other sources (text and image sources). Inspecting an Input Splitter in Quartz Composer Quartz Composer consists of objects which are connected together with patch cords. The 'Input Splitter' object lets you make inputs in patches; data may be passed to objects through these inputs.

If you make an input splitter in the top level of your patch and publish it, VDMX will attempt to make an interface item for your input; different types of inputs (numbers, toggles, colors, etc.) get different types of interface items. The page includes step-by-step instructions as well as a list of several special input types supported by VDMX. [] Using Quartz Composer documents as sources in VDMX Quartz Composer patches that are loaded into a media bin in VDMX can be triggered and played on a layer just like any other video file. Once triggered the patch will start playing back immediately on the specified layer.

Any published inputs (controls) for the patch can be accessed by using the. Patches can also be previewed by using the palette window. From here you can set the default settings for any of the input controls for the patch, as well as set a custom rendering resolution.

If no rendering resolution is set for a patch it will play at the current canvas size. When loading the patch VDMX will try to create a thumbnail to represent the clip. Because many patches that are generative can show up in media bins with non-descriptive thumbnails (usually just a completely black thumbnail), VDMX also will check to see if a is included with the patch.

[] Special Types of Quartz Composer patches for VDMX • QC patches as visual effects (qcFX) If you add an image input to your Quartz Composer patch (and name it appropriately), VDMX can use it as an effect: video will be passed to the image input, your patch will be rendered, and the final image will be sent to the next effect in the chain. • QC patches as blend modes and transitions for layers (qcCompModes) Patches that take two video inputs and mix them together in some way can be used as composition modes for layers in VDMX.

This allows for creating custom blend modes and transitions. • QC patches for text file playback (qcTextSources) If you add a string input to your Quartz Composer patch (and name it appropriately), VDMX can use it to trigger text files: text will be passed to your patch, rendered, and the final image will be send through your FX chain. • QC patches for image file playback (qcImageSources) In addition to using our built-in image player, images can be passed off to specially designed Quartz Composer patches. These patches can work with hi-resolution images to boil them down to a standard video resolution before processing with other FX. Examples of this are performing zooms without pixelation and smoother texture mapping onto 3d surfaces. • QC patches as VDMX plugins (qcPlugins) Patches loaded as plugins (such as the waveform) and used to generate control data (numbers, on/off states, and colors) and images that can be used to control sliders, buttons, color pickers, video taps and other receivers in VDMX.

To add a custom QC patch to the resources available to VDMX simply place them in the appropriate sub-folder located in /user/Library/Application Support/VDMX/ directory. Alternatively the patches can be places in the qcFX, qcTextSources, qcImageSources and plugins folders in the same folder as the VDMX application.

Also be sure to look at the example QC patches included in the VDMX folder which can be duplicated and used as starting points for new patches. [] Creating custom FX If you want to use a Quartz Composer patch as an effect in VDMX simply include an additional published input of type 'Image' with the key 'inputImage'. The image to be processed by your FX will be passed to the patch from this input splitter. Any additional image inputs will show up as video taps in the control panel for the FX when it is added to a layer. Quartz Composer patches made using the Image Filter template will also work as FX in VDMX. By default custom QC FX show up in the list of available filters in the FX Manager palette under the 'Quartz Composer' but a you can also to help organize your FX.

[] Creating custom composition modes and transitions Patches that take two inputs can be used to composite or transition two layers in VDMX. These patches must have two image inputs with the published keys 'foreground' and 'background' (for the top and bottom layers respectively) and an 'opacity' number input.

When the opacity value is 0 it is recommended that the 'foreground' layer be completely invisible and the 'background' layer should be unprocessed. As a note, unlike other the other special types of QC patches currently there is no way to access any other input controls for QC composition modes besides the opacity. [] Using Quartz Composer patches as VDMX plugins Any Quartz Composer patch placed in the plugins folder will show up as an available plugin in the VDMX Plugin Manager palette window and can be added to a preset like any other plugin (eg. Waveform or media bin). The QC patch will appear in its own window with controls for all of it's input parameters.

The plugin can also pass information back to VDMX. On load each of the published outputs of the patch will be made available to VDMX using the appropriate data-type: numbers, booleans, and colors are available as standard data-sources and any image outputs can be accessed by layers / preview windows / and FX by using video taps.

Just wondering what methods there are of getting quartz performance up. At times my demo seems to be CPU limited, so apart from the obvious optimising within the composition, what can be done to improve it? I've tried enabling multi-threaded opengl, that seems to improve performance but only slightly, and there is still one thread using 100% of one core.

Is there any sane way of enabling threading for the rest of quartz? Or any other way of increasing performance either within QC or from an application?

First, disable multithreaded opengl; it's not what you think, and never helps performance (and adversely harms performance in special cases like Render In Image, GLTools, and Kineme3D) The graph evaluation model used internally is very much single threaded; It would be possible to evaluate distinct graph pieces in parallel, but that's some tricky code, and I'm not surprised that Apple haven't done that yet; many patches simply aren't CPU-limited, but GPU limited (GLSL shaders and Core Image filters being notoriously expensive). I've done some experiments in threading parts of it via hacks (mostly for audio), and it always ends in disaster due to complexity (with the source code, it would be much easier, but from a plugin's point of view it's very difficult).

Disabling patches that aren't producing output can reduce the amount of work that QC needs to do each frame. Limiting the use of Iterators, the use of Javascript, and very deep macros will help a bit when possible (macros aren't very expensive at all; maybe 3 extra messages per frame, so removing that should be an absolute last step -- it's mostly an act of desperation as far as I'm concerned, but it's an optimization nonetheless). Disabling VBLSync seems to help performance on my machine, at the cost of shearing/tearing. Enabling hardware everything (software gl and software core image will destroy performance) helps, but that's the default configuration anyway.

If all else fails, plop down some feature requests for tuned plugins -- it's difficult to beat the performance of compiled code:). Nothing I've not already done then really (except the flattening macros thing, and I reckon 2,500 patches with no macros might be slightly annoying;) I'll disable multithreaded gl then. It was making marginal difference at best anyway. I think I'd used it where there was no render in image or similar, so perhaps it wasn't changing anything at all. Actually, I have noticed that there's a few common functions that take a few patches but would be easily done with one.

I think some would be very easy to do as plugins too. I'll add a few here, and if others think they would be useful (and i've not missed a better way of doing them with QC) I'll add them to the request list: • a 'looped timelines' patch. It's really handy to have looping animation, and it's necessary to have the timelines, patch time, and a range patch to do it. (Actually I do remember seeing a way to loop it, but I can't find it now, so maybe that was another app?) That would just be a standard timelines patch, but with a 'loop time' input of some sort.

• a 'pattern editor'. This would be similar to the timelines patch, but would be limited to a short sequence of 1s and 0s, which would run in a loop. That would be much more efficient than the timelines patch for enabling/disabling patches/effects I think. Although maybe the timelines patch is efficient enough? LFO could also work, although you'd have to check that it 'keeps time' well enough and starts at the right point.

I guess (without checking) that neither would be an issue. The reason I went with the range method though is that I'm using my own timers that match the music BPM rather than seconds, so to keep the loop in synch I use that as an external time source. Then it's just a choice between LFO and range, and I think range will be much more efficient.

I'll make a note here of any other little bits that would benefit from a single patch then:) I've almost cut javascript out, but I think there's probably a few macros I've used that are handy and could be made into patches. I'm going through the demo now and cleaning + documenting things, expect the first part pretty soon:). All those patches with hidden Patch Time inputs are cool.

Interpolators are especially good when driven by an LFO, or even a straight control splitter. I find them invaluable for modifying control curves. You can even use them to reverse the action of a particular control, so it goes from, say, 1 up to 0, or between 2 other arbitrary values, with different curves. They work really well for distributing values inside an Iterator too, with the Patch Time linked to the Iteration Index. Alx Quartz Composer Blog: Music Site.