Bugs preparing comp for Quartz Crystal using Value Historian patch

usefuldesign.au's picture

I've read all the QuartzCrystal and Value Historian threads for advice about audio reactive data inside QuartzCrystal. Seems like Value Historian is recommended and I would like to record other tweaks so I am to learning to use this patch.

I am getting much weirdness in totally unrelated parts of the composition. I had the black portion of my background go white on one attempt to use it. Reverting to save, on another the whole comp rendering width got stretched. I'm persevering but frequently get errors too. Quit Quartz and Relaunched and it made no difference but Log-out & In seemed to get the file back to a useable state.

Problems occur when I stop comp in the the viewer window. Change to Playback and restart. Usually I get a Error Log with Quit and Continue buttons. I think once or twice last night I got some kind of play back.



This is correct looking composition.

This is stretch only in X Axis

And this is stretched in both Axis but still much more X Axis

Actual I think I've now sorted this but already had the post ready to go. Now its just a bug report. I didn't have the audio patched through soundflower tonight. Not sure what was up last night as it was reacting to sound but still playing up in random ways.

TAKEHOME MESSAGE: Never have a zero or NaN value on an input of VH patch and then send it into Playback weird stuff happens. I think this qualifies as a bug cwright ;) guess you're partially aware of it already.

*The comp is essentially Toneburst's GL Look At Very Cool comp with value historian bridging some of the published ports and the audio player. (Also problems with Kineme Audio File Input patch hanging the comp for 5-10 secs every time a value is changed 'live'. Will post in separate thread.

Comment viewing options

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

cwright's picture
Re: Bugs preparing comp for Quartz Crystal using Value ...

usefuldesign.au wrote:
TAKEHOME MESSAGE: Never have a zero or NaN value on an input of VH patch and then send it into Playback weird stuff happens. I think this qualifies as a bug cwright ;) guess you're partially aware of it already.

hmm.. zero is totally ok with VH, and NaN can only come from javascript (QC's number ports discard NaN's most of the time.)

From the looks of it, a GL patch generated a NaN and passed it along, which will upset GL (there would be a message in the console noting an "invalid enumerant" or something to that effect) -- this will trash QC until you restart it (QC, not necessarily the computer).