[Fluxus] time while rendering

Rob Couto dbtx11 at gmail.com
Sat Jun 2 20:48:34 PDT 2012


Hi again Kas and all...

Here's a patch for master, which also applies to redacted in case that
helps. I found out that you don't need parantheses when defining
aliases to other functions, as in boot.scm there is the reason for
that other oddity: (define time flxtime). I changed the docs to
reflect that, you can (define time process-time) and (define flxtime
process-time) or only the one you used, if one... I always used
(time). I tested this with a script that draws *many* cubes in
immediate mode with the number being based on several harmonic values,
and it sometimes takes a second to unfreeze because there is so much
overdraw and I'm using (blend-mode 'one 'one). It's pretty smooth...
and to get mplayer to work, I just had to use tif and then convert all
to tga which didn't cause it to complain about invalid colorspace like
png did. So that's cool.

There seems to be little or no use for m_BufferTime in AudioCollector,
and it is the only obvious thing depending on m_Samplerate. However,
over in the big mess, I also had to use m_Samplerate for the bandwidth
calculations to build the frequency scaling matrix, (in case that
sounds smart, I only translated it from matlab code which would have
taken me months to write) so it made sense to change m_Samplerate to
the sample rate of the wav being worked on. Then I had to change it
back to JackClient's sample rate when the wav finished, so that's why
there are some includes moved around and a persistently visible Jack
pointer. It's not exactly necessary in master but I wanted to avoid
possible weirdness if it had a purpose I missed.

This provides 4 new functions and changes one. (process) now takes 2
arguments, the string location of the wav and a number for the
framerate, which can be inexact. (process-time) returns the inexact
number of seconds into the wav being processed, and (process-delta)
returns a constant: 1/framerate. (stop-process) closes the wav and
returns to normal early if you need to. (processing) returns true if a
wav is open and in use.

You can set any buffer size you like when calling (start-audio), and
it will only affect the FFT precision and size of (ga)-- nothing needs
to be done to make the wav run through correctly.

If I goofed, it's because after it worked I had to make it work again
by pasting into an editor that didn't fix a bunch of whitespace and
enlarge the commit, so good luck with that, and thanks for the
feedback.

-- 
Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: processing_modifications.patch
Type: text/x-patch
Size: 14229 bytes
Desc: not available
URL: <http://lists.pawfal.org/pipermail/fluxus-pawfal.org/attachments/20120602/da7b4969/attachment-0003.bin>


More information about the Fluxus mailing list