"m@b" <sai### [at] googlemailcom> wrote:
> I don't find it takes too much time, admittedly I chose shorter and much
>   slower songs than you are planning.
>
> If there is a constant beat throughout the song you can set up a
> variable direct from clock which can be used to animate all sorts of things.
>
> See:
> <https://www.tiktok.com/@matthew.bradwell/video/6944909548163484930>
> and
> <https://www.youtube.com/watch?v=djJGXZB6yRE>
>
> Best,
> m@
>
> p.s. I just watched the song - there is a lot going on there!

I'm curious about a couple things, since you have already solved some problems
that I'm currently working on. Did you create one giant POV-Ray file for the
entire animation, or did you split it up into multiple files? If you split it
up, did you need to devise a method of passing information from one file to the
next? If so I'm very interested to hear the basic details of how you did this,
especially since you had to plan much farther ahead by positioning the camera
correctly. I will have to split my project into multiple files for sure and so
far I've written a macro that automatically keeps track of the current number of
frames/time elapsed but ideally it would be nice to be able to pass information
about changing textures as well. I don't think this is possible, but maybe
there's a way...

Also my original belief that it would be possible to visually examine the
waveform with a music editor and identify beats and other musical events has
turned out to be totally false. Drum beats can be identified easily enough but
bass notes are not as obvious especially when there is singing and/or other
guitar stuff going on simultaneously.

It has been brought to my attention that the mathematical method of detecting
beats/changes is by the use of Fourier transforms. So my current options are to
try to locate and adapt some Fourier transform code to POV-Ray SDL and use it to
generate a list of acoustic event times (probably beyond my ability), or find
another alternative. One option that I'll explore next is the "spectral" view.
In the past I used Magix Audio Cleaning Lab to remove tape hiss and unwanted
sounds from commercial recordings and one of the features was "spectral
cleaning" which displayed the music in a unique visual manner, which may help.
Re-installing that program and checking that option out will be my next project.

I made a five-second test animation by guessing the approximate times of the
first few bass notes and it's definitely not good enough. I posted it anyway for
an example of what not to do:

https://www.youtube.com/watch?v=Rv8kGq9PUkM

This also includes a test of using video frames in one of the characters of the
logo. I picked a random five-second segment from a concert video and it didn't
work out at all, at least not with the big "A." I think that carefully selected
video segments have potential in the smaller characters though.

Cheers,
Dave Blandston

Post a reply to this message

On 12/04/2021 10:18 am, Dave Blandston wrote:
> "m@b" <sai### [at] googlemailcom> wrote:
>> I don't find it takes too much time, admittedly I chose shorter and much
>>    slower songs than you are planning.
>>
>> If there is a constant beat throughout the song you can set up a
>> variable direct from clock which can be used to animate all sorts of things.
>>
>> See:
>> <https://www.tiktok.com/@matthew.bradwell/video/6944909548163484930>
>> and
>> <https://www.youtube.com/watch?v=djJGXZB6yRE>
>>
>> Best,
>> m@
>>
>> p.s. I just watched the song - there is a lot going on there!
> 
> I'm curious about a couple things, since you have already solved some problems
> that I'm currently working on. Did you create one giant POV-Ray file for the
> entire animation, or did you split it up into multiple files? If you split it
> up, did you need to devise a method of passing information from one file to the
> next? If so I'm very interested to hear the basic details of how you did this,
> especially since you had to plan much farther ahead by positioning the camera
> correctly. I will have to split my project into multiple files for sure and so
> far I've written a macro that automatically keeps track of the current number of
> frames/time elapsed but ideally it would be nice to be able to pass information
> about changing textures as well. I don't think this is possible, but maybe
> there's a way...
> 
> Also my original belief that it would be possible to visually examine the
> waveform with a music editor and identify beats and other musical events has
> turned out to be totally false. Drum beats can be identified easily enough but
> bass notes are not as obvious especially when there is singing and/or other
> guitar stuff going on simultaneously.
> 
> It has been brought to my attention that the mathematical method of detecting
> beats/changes is by the use of Fourier transforms. So my current options are to
> try to locate and adapt some Fourier transform code to POV-Ray SDL and use it to
> generate a list of acoustic event times (probably beyond my ability), or find
> another alternative. One option that I'll explore next is the "spectral" view.
> In the past I used Magix Audio Cleaning Lab to remove tape hiss and unwanted
> sounds from commercial recordings and one of the features was "spectral
> cleaning" which displayed the music in a unique visual manner, which may help.
> Re-installing that program and checking that option out will be my next project.
> 
> I made a five-second test animation by guessing the approximate times of the
> first few bass notes and it's definitely not good enough. I posted it anyway for
> an example of what not to do:
> 
> https://www.youtube.com/watch?v=Rv8kGq9PUkM
> 
> This also includes a test of using video frames in one of the characters of the
> logo. I picked a random five-second segment from a concert video and it didn't
> work out at all, at least not with the big "A." I think that carefully selected
> video segments have potential in the smaller characters though.
> 
> Cheers,
> Dave Blandston
> 

I put the scene all in one file, the timings go in another (.inc) file, 
I find it convenient to switch between the two when working.

Here is the layout of the timing file:

SETUP TIMES FROM THE SPREADSHEET

#declare T000 = 0.0000;  // Start
#declare T001 = 0.0667;  // Weird                   Zoom to 1
#declare T002 = 0.0833;  // Dum dum                 Rotate Florets
#declare T003 = 0.1433;  // I'm a little weird      Zoom out 1
#declare T004 = 0.2083;  // I wear a little beard   To Ladybird
#declare T005 = 0.2483;  // Durul ural um dum       Ladybird

INITIALISE ELEMENTS THAT WILL BE ACTIVATED/CHANGED DURING RENDER

#declare FlowerHead  = 0;
#declare Stalk       = 0;
#declare Grass       = 0;
#declare GroundPlane = 1;
#declare Mushroom    = 0;

USE SWITCH TO RENDER SCENE BY SCENE
See screen shot

This macro sets up some local clocks. Start runs from 1 to 0, End runs 
from 0 to 1, they both start and end slowly like an S-curve, this avoids 
jerky camera movements at each scene change. Bumper runs 0-1-0.

#macro Cosify()
	#declare Start =  (cos(1*pi*Current_clock)+1)/2;
	#declare End = (1-(cos(1*pi*Current_clock)+1)/2);
	#declare Bumper = sin(pi*Current_clock); #end

PRINT OUT SOME STATS SO i CAN FOLLOW HOW THE ANIMATION IS PROGRESSING

#debug concat( Handle_1, "   Clock = ", str(clock,0,3), " 
Current_clock = ", str(Current_clock,0,4), "    Frame = ", 
str(frame_number,0,0),  "\n")
#debug concat("Look at = ", Vstr(Camera_look_at, 0, 0), "    Camera 
location = ", Vstr(Camera_shift, 0, 0),  "    Zoom = ", str(Zoom,2,2), 
"\n")

Post a reply to this message

Attachments:
Download 'povshot1.gif' (28 KB)

Preview of image 'povshot1.gif'

On 11/04/2021 9:59 pm, Kenneth wrote:
> "m@b" <sai### [at] googlemailcom> wrote:
> 
>> I use Audacity to find the start time of each phrase in the song, I then
>> put these times in a spreadsheet to get the clock values and frame
>> numbers for POV-Ray .
> 
> I use Audacity too, a great free app. And your spreadsheet for creating
> animation timings is a great idea. If I understand your spreadsheet-use
> correctly, how do you ultimately output the values there into a form that
> POV-ray can #read during its animation render? 

I just copy and paste manually. I am sure it would be possible to output 
the spreadsheet as a CSV file and have POV-Ray read it but I haven't yet.

>> If there is a constant beat throughout the song you can set up a
>> variable direct from clock which can be used to animate all sorts of things.
>>
> 
> The 'constant beat' is sometimes not so constant, ha. Especially during long
> songs. (Unless the beat is generated by a drum machine or click track, for
> example.) 

Good point

Post a reply to this message

"m@b" <sai### [at] googlemailcom> wrote:
> I put the scene all in one file, the timings go in another (.inc) file,
> I find it convenient to switch between the two when working.
>
> Here is the layout of the timing file:
>
> SETUP TIMES FROM THE SPREADSHEET
>
> #declare T000 = 0.0000;  // Start
> #declare T001 = 0.0667;  // Weird                   Zoom to 1
> #declare T002 = 0.0833;  // Dum dum                 Rotate Florets
> #declare T003 = 0.1433;  // I'm a little weird      Zoom out 1
> #declare T004 = 0.2083;  // I wear a little beard   To Ladybird
> #declare T005 = 0.2483;  // Durul ural um dum       Ladybird
>
> INITIALISE ELEMENTS THAT WILL BE ACTIVATED/CHANGED DURING RENDER
>
> #declare FlowerHead  = 0;
> #declare Stalk       = 0;
> #declare Grass       = 0;
> #declare GroundPlane = 1;
> #declare Mushroom    = 0;
>
> USE SWITCH TO RENDER SCENE BY SCENE
> See screen shot
>
> This macro sets up some local clocks. Start runs from 1 to 0, End runs
> from 0 to 1, they both start and end slowly like an S-curve, this avoids
> jerky camera movements at each scene change. Bumper runs 0-1-0.
>
> #macro Cosify()
>  #declare Start =  (cos(1*pi*Current_clock)+1)/2;
>  #declare End = (1-(cos(1*pi*Current_clock)+1)/2);
>  #declare Bumper = sin(pi*Current_clock); #end
>
> PRINT OUT SOME STATS SO i CAN FOLLOW HOW THE ANIMATION IS PROGRESSING
>
> #debug concat( Handle_1, "   Clock = ", str(clock,0,3), "
> Current_clock = ", str(Current_clock,0,4), "    Frame = ",
> str(frame_number,0,0),  "\n")
> #debug concat("Look at = ", Vstr(Camera_look_at, 0, 0), "    Camera
> location = ", Vstr(Camera_shift, 0, 0),  "    Zoom = ", str(Zoom,2,2),
> "\n")

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

I am in luck regarding my hope of being able to see changes in the music better
than just looking at the waveform. I got the spectral display up and running and
it makes it pretty easy to spot acoustic "events." The screen shot of the first
five seconds of music that I'm using clearly shows six quick bass notes then
three slower ones then five quick ones etc. The time display is in milliseconds
which is plenty accurate. Unfortunately there are many hundreds of musical
events that I will have to log by hand. But the final product should be nearly
perfect.

Thanks for sharing your technique!

Post a reply to this message

Attachments:
Download 'screen.jpg' (397 KB)

Preview of image 'screen.jpg'

"Dave Blandston" <nomail@nomail> wrote:

> I am in luck regarding my hope of being able to see changes in the music better
> than just looking at the waveform. I got the spectral display up and running and
> it makes it pretty easy to spot acoustic "events." The screen shot of the first
> five seconds of music that I'm using clearly shows six quick bass notes then
> three slower ones then five quick ones etc. The time display is in milliseconds
> which is plenty accurate. Unfortunately there are many hundreds of musical
> events that I will have to log by hand. But the final product should be nearly
> perfect.
>
> Thanks for sharing your technique!

Silly cro-magnon idea here -
what about using sheet music and a ruler?

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Silly cro-magnon idea here -
> what about using sheet music and a ruler?

Ha ha I wish!!!

Correction: 6 - 3 - 6 etc. bass notes...

Post a reply to this message

hi,

"Dave Blandston" <nomail@nomail> wrote:
> ... The time display is in milliseconds
> which is plenty accurate. Unfortunately there are many hundreds of musical
> events that I will have to log by hand.

don't you own a computer?  :-)

anyway, reading this I (may have) got carried away and wrote a few lines of
script[*] over lunch (can't tell what OS you're running from the screenshot,
however, if you haven't Tcl/Tk installed, it is freely available on all
platforms).  run it, right-click to start, left-click or 'b' key each beat, then
right-click again to stop; 'q' at any time to abandon.  the only thing left to
do, as exercise for the interested reader ;-), is subtracting the initial mark
from all subsequent ones, and writing them to file.  hope you'll enjoy it, I
certainly did.

[*] hack. :-)


regards, jr.

# ------------------------------------------------------------------------

#!/usr/bin/env wish

proc doStuff {} {
  global T
    set a [lsort -integer [array names T]]
    set from [lindex $a 0]
    set to [lindex $a end]
    set n [llength $a]
    set s [format {recorded %d beats, total ms: %d} $n [expr {$to - $from}]]
    tk_dialog .dlg foobar $s info 0 ok
  return
}

proc rightClick {} {
  global rt T
  if {!$rt(run)} {
    set rt(run) true
    set rt(begin) [clock milliseconds]
  } \
  else {
    unset rt(run)
    if {![array exists T]} {exit 99}
    doStuff
    destroy .
  }
  return
}

proc leftClick {} {
  global rt T
  if {$rt(run)} {
    set T([clock milliseconds]) {}
  }
  return
}

set rt(run) false

label .lbl -padx 2cm -pady 2cm

pack .lbl

bind . <KeyPress-q>  [list destroy .]
bind . <KeyPress-b> leftClick
bind . <ButtonRelease-1> leftClick
bind . <ButtonRelease-3> rightClick

# ------------------------------------------------------------------------

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

ouch, complete with bug even.  forgot to use 'rt(begin)' hence subtracting from
wrong value.  </hang-head-in-shame>


regards, jr.

Post a reply to this message

"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

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> run it, right-click to start, left-click or 'b' key each beat, then
> right-click again to stop; 'q' at any time to abandon.

This sounds intriguing - I've never heard of Tcl/Tk so I'm not sure what you
mean - should I run this script then play the song and press the "b" key every
time I hear a beat, and the script will record the timing of the keypresses? If
so then I must admit that I have no musical talent whatsoever of my own and my
ability to keep a beat is nearly non-existent. If you saw me TRY to dance you
would immediately agree that I would fail terribly at this!

Have a great day!

Kind regards,
Dave Blandston

Post a reply to this message