Kineme Audio File Input patch

I have to congratulate Kineme on the speed of the Kineme Audio File Input patch it seems to flog the Apple patch in Toneburst's GL Look At Very Cool comp that I remixed.

Unfortunately whenever I adjust published values in the comp as it is running, I get beach-ball-o-death and a hang in the comp for 15-40 seconds. This doesn't happen with the slower Apple audio file patch

Steps to Reproduce:
Run the comp alter any top level published value

Expected Results:
No beach-ball-delay

Actual Results:

No tests for this as latest version is required for Quartz Crystal. Patch is new?

No work around known :( Switch between Apple and Kineme Patch at root level.

RandomWalkTest_01.5 (audio_remix)IIIii.qtz23.15 KB

Comment viewing options

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

cwright's picture
Re: Kineme Audio File Input patch

I've changed top-level values while running with both apple and kineme audio inputs, and have had no beachballs.

Can you reboot and confirm that this still happens? Can anyone else get this to happen? Can you remove unrelated plugins to help isolate the issue?

gtoledo3's picture
Re: Kineme Audio File Input patch

I'm seriously slamming all of the sliders back and forth while playing a file from my desktop, ramping up the iterations...

I got a little lag when the audio file stops playing, but that's being real nit picky. No beach balls.'s picture
Re: Kineme Audio File Input patch

Reboot doesn't change things. Same issue 3 days in a row.

Disabled all patches and plugins (all Kineme except for a couple of Vades). Got about 30 secs of no hassles then it began. Pauses were without beach balls for about 7 sec then beach ball for about 5 sec.

I noticed delays when spinning composition in view (there's a Trackball patch in that one). Removed trackball patch in vain hope of isolating problem. This broke the published link b/w GL patches and point struct from JS patch. Despite not getting the data to the GL patches the delays still occur when adjusting values.

Then noticed even when scrolling the screen in the Editor window I get pauses in the composition. Seems to be some kind of memory thing (excuse the technical jargon)?

The delays are less lengthy than with all the other plugins loaded and last night I had a bunch of other apps running too which seemed to slow it down more.

What can I test from here? Is it the JS patch playing up? To be honest it's a bit iffy anyhow as you have to ramp the iterations a few times to get the ball rolling if the sensitivity is set to get good audio reactions.'s picture
Re: Kineme Audio File Input patch

Should add I'm using an FX 5200 GPU card (Dual G5 Mac).

I know this is easy to overlook so apologies for saying this but you have both changed the file path to a valid audio file right? (I'm guess BBC Peel Sessions of the orb might not be in your current iTunes Library!)

EDIT sorry George re-reading you post you mentioned it played right through the audio track./EDIT

Actually as work through comp I'm think this has to be it.

Two things stand out: Inspecting the Kineme Volume peaks they are 1.0e32 to 1.0e38 order of magnitude compared with Apples peaks of 0.1 order of magnitude. Passing these values through the gain multiplication is generating a NaN on the Integrator Patch (hey, I didn't add that patch!). I was falsely assuming volume peaks of Kineme patch same as Apple Audio patch.

Second, that's not it because even though I have divided the value by 1e39 and getting nice small 0.1-0.7 range values integrator patch is NaN on output after random time interval after start. (approx. 4 seconds)

I don't use the Integrator patch and am unfamiliar with it's quirks. Any thoughts?

Also converting Kineme Audio peaks do I need a log conversion to get result more approximating a VU/Peak Meter (might need a Smooth patch too for Peak)?

cwright's picture
Re: Kineme Audio File Input patch

With a valid audio file, I'm able to play it without any beachballs. I get occasional stalls, not sure where those come from, but only on the order of 1-3 seconds. I noticed no correlation with modifying values (the pauses were at random, and irrespective of published input modifications)

performance inspector indicates a huge load in the audio input patch (even with FFT disabled), which might indicate a problem, but sharking it didn't reveal anything interesting. you can try it w/o JS (but then you're also disabling GL, which might play a subtle part in this).

Scrolling in the composition has always caused pausing in the composition -- they're run on the same thread. usually it's not too noticeable, but under some circumstances it can be rather jarring.

Audio Input's range isn't Apple's audio input range, but 1e32 sounds wrong. Have you tried the Kineme Audio input, or a different audio file, to see if this one is tripping up the audio decoder or something?

gtoledo3's picture
Re: Kineme Audio File Input patch

On that note, I also was multiplying the peaks by upwards of 10,000, to get some more action... you might try that as well, aside from any bug issues you are having.

" To be honest it's a bit iffy anyhow as you have to ramp the iterations a few times to get the ball rolling if the sensitivity is set to get good audio reactions."