 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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] netscape net> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
