POV-Ray : Newsgroups : povray.binaries.animations : Music Video Project Server Time
23 Jun 2021 13:25:30 EDT (-0400)
  Music Video Project (Message 11 to 20 of 36)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Bald Eagle
Subject: Re: Music Video Project
Date: 12 Apr 2021 07:00:00
Message: <web.6074272e432b07e11f9dae3025979125@news.povray.org>
"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

From: Dave Blandston
Subject: Re: Music Video Project
Date: 12 Apr 2021 08:30:01
Message: <web.60743c48432b07e179416a1f9334df62@news.povray.org>
"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

From: jr
Subject: Re: Music Video Project
Date: 12 Apr 2021 08:40:00
Message: <web.60743e37432b07e179819d986cde94f1@news.povray.org>
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

From: jr
Subject: Re: Music Video Project
Date: 12 Apr 2021 08:50:00
Message: <web.6074414a432b07e179819d986cde94f1@news.povray.org>
"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

From: Kenneth
Subject: Re: Music Video Project
Date: 12 Apr 2021 14:40:00
Message: <web.607492fb432b07e1d98418916e066e29@news.povray.org>
"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

From: Dave Blandston
Subject: Re: Music Video Project
Date: 12 Apr 2021 18:10:00
Message: <web.6074c48f432b07e179416a1f9334df62@news.povray.org>
"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

From: Dave Blandston
Subject: Re: Music Video Project
Date: 12 Apr 2021 18:25:00
Message: <web.6074c777432b07e179416a1f9334df62@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:
>
> 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.

That's interesting - I had forgotten that frame_number even existed because I
got used to using clock years ago, but I can see that frame_number would be more
appropriate under some circumstances, possibly including this one. I did in fact
have to include some code to convert number of frames generated to time elapsed
so using frame_number would be exact instead of within 1 / framerate / 2. The
beat markers will be in milliseconds which would have to be converted to
frame_numbers though so it's a trade-off either way. Thank you for the excellent
suggestion!

Have an awesome day Kenneth!

Kind regards,
Dave Blandston


Post a reply to this message

From: Dave Blandston
Subject: Re: Music Video Project
Date: 12 Apr 2021 18:35:00
Message: <web.6074ca63432b07e179416a1f9334df62@news.povray.org>
Here's a short test to show the use of the "spectral" display to locate beat
times. It appears to be right on. (Note that not all beats are used, but when a
visual transition does occur it coincides with a beat.) It's great that Audacity
includes this functionality!

https://www.youtube.com/watch?v=RifdL-c0QMM

Kind regards,
Dave Blandston


Post a reply to this message

From: Bald Eagle
Subject: Re: Music Video Project
Date: 12 Apr 2021 19:25:00
Message: <web.6074d6b8432b07e11f9dae3025979125@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:

> 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.

Those ought to stay exactly the same.
If you're just increasing the number of frames, then everything should stay the
same as well.

If you are _appending_ more things to the animation, then maybe just declare a
Clock2 variable that is
#declare Clock2 = max (1, 2-clock);
Then when the 0-1 clock "runs out", you get a second 0-1 clock variable to use.
You can also just search-replace all of your "clock" instances with "Clock"
#declare Clock = min (1, clock);
so that it stops at 1.


> 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!

"Smoothstep" in glsl, shadertoy, etc.
https://en.wikipedia.org/wiki/Smoothstep
https://www.youtube.com/watch?v=60VoL-F-jIQ
https://iquilezles.org/www/articles/ismoothstep/ismoothstep.htm
https://thebookofshaders.com/glossary/?search=smoothstep


Post a reply to this message

From: m@b
Subject: Re: Music Video Project
Date: 13 Apr 2021 02:41:34
Message: <60753d1e$1@news.povray.org>
On 13/04/2021 2:38 am, Kenneth wrote:
> "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.


Good points.
Further - frame numbers are better if you are including video frames in 
an animation. Using clock derived functions results in dropped or 
doubled frames from time to time.


> 
> 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!
> 

You can't do it with frame numbers directly as each frame has a fixed time.

Presumably you could use the formulas as mentioned above and just 
substitute Frame_A, Frame_B instead if Time_A, Time_B to make a local 
clock? the start and end points would still be tied to frame numbers.


> 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

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2021 Persistence of Vision Raytracer Pty. Ltd.