 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmail com> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13/04/2021 6:32 am, Dave Blandston wrote:
> 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
>
Looking good :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"m@b" <sai### [at] googlemailcom> wrote:
> 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.
Precision errors can be an issue in situations like this and they're more common
than some folks might realize. You would never know the difference if some
object is positioned at 43.9999999 instead of 44 POV units and the difference is
one billionth the width of a pixel and has zero effect on the final image
values, but you will certainly notice if FRAME #43 is displayed instead of FRAME
#44!
#local FrameNumber = int (EventClock * (NumberOfFrames - 1) + .1); //Correct for
precision errors
#local Padding = strlen (str (NumberOfFrames - 1, 0, 0));
#local SourceImageFileName = concat ("VideoFrame_", str (FrameNumber, -Padding,
0), ".png")
Just something to keep in mind...
Kind regards,
Dave Blandston
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
"Dave Blandston" <nomail@nomail> wrote:
> "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?
yes.
> 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!
no worries, the "white men can't jump" syndrome. :-)
<https://www.youtube.com/watch?v=-FvsgGp8rSE>
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> hi,
> no worries, the "white men can't jump" syndrome. :-)
>
> <https://www.youtube.com/watch?v=-FvsgGp8rSE>
>
>
> regards, jr.
Yep, that's me!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
(this has been nagging me since I posted, sorry)
"jr" <cre### [at] gmailcom> wrote:
> "Dave Blandston" <nomail@nomail> wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> > > 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?
>
> yes.
the presumption was/is that you are comfortable with the idea of "programming"
since you use (at least) the POV-Ray SDL. there's nothing special about the
language, almost any scripting/compiled language will do. I wrote the code to
illustrate that you can make a simple tool to take some of the drudge out of the
job and take (human) fallibility out of the equation, with little effort -- make
your computer earn its electricity. (besides, it also delivered a pleasure
"kick" similar to solving a good crossword. :-))
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> the presumption was/is that you are comfortable with the idea of "programming"
> since you use (at least) the POV-Ray SDL. there's nothing special about the
> language, almost any scripting/compiled language will do. I wrote the code to
> illustrate that you can make a simple tool to take some of the drudge out of the
> job and take (human) fallibility out of the equation, with little effort -- make
> your computer earn its electricity. (besides, it also delivered a pleasure
> "kick" similar to solving a good crossword. :-))
>
>
> regards, jr.
I have begun the arduous task of logging the beat marks by hand. I ended up
using a program called RX 8 by Izotope to display the "spectral" music view
since it shows a little more clarity than Audacity and it displays the exact
time where the cursor is so it's easy to get the info. In many instances there
are several beats per second, for example:
23.116
23.242
23.393
23.549
23.675
23.829
23.961
Also this particular song does not have a regular, constant beat - it changes
continually. It took well over an hour, probably closer to two hours just to get
to the 44 second mark but it is possible. I wish I could use your script but I
think it would be impossible to get accurate results, at least for this song. If
you haven't heard it check it out and you'll see what I mean...
https://www.youtube.com/watch?v=6rNELTZO0QQ
Plus listening to it will make your day better!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
