"Dave Blandston" <nomail@nomail> wrote:
>
> Hey this is super interesting! We are doing some very similar things - I am also
> using local "Event clocks" that go from 0 to 1 at pre-determined intervals, and
> look how similar our "smoothing" functions are:
>
> #local ClockFactor = (sin (radians (EventClock [I] * 180 - 90)) + 1) / 2; //0 ..
> 1
> #local ClockFactor = pow (ClockFactor, 1); //Adjust for a faster or slower start
>

Just a suggestion:
Although clock, clock_delta and Final_Clock are great tools for creating
animations, and for causing 'events' to happen at certain times, I use
frame_number (or some fraction thereof) more often now. It's probably a personal
choice, of course; but frame_number seems more intuitive to me-- and I don't
have to think in 'clock division' terms for the timing of animation events.

I'm currently reworking an old and complex animation scene, which has various
#include files, where I used clock etc. exclusively throughout the scene. It
worked beautifully at the time-- but I'm thinking now of extending the length of
the entire animation with some new action at the end, maybe by 25%, but
without messing up all of the clock-specified events and timings that are
already there. I *could* simply change Final_clock to be 1.25, but I'm not yet
sure what that will do to some of the events which actually depend on the
(previous) clock-end of 1.0.  As a simple example,

#if(clock <= 0.3) --do this-- #else -- do that-- #end

.....but now I don't want the #else action to extend past a clock of,say, 1.15. I
could easily change the #if clause of course, but changing all such constructs
to use frame_number instead tells me exactly and visually when to expect the
action, or to easily change it.

I also like frame-number because, after a test animation, I can immediately see
where any animation glitches need correcting-- at which frame, in other words,
without having to make a clock-division computation to figure it out.

However, I haven't yet worked out how to 'start and end events slowly like an
S-curve' as was mentioned previously, when using frame_number instead of clock.
I'll have to explore that!

But your music video project uses a song length that is 'set in stone', so using
clock is a perfectly natural way to achieve the results.

----
[Btw, I just discovered that the Audacity app can show 'spectral timings' for a
song too, like the image you posted; I had never used that feature before.
Thanks for the suggestion!]

Post a reply to this message