Page 1 of 1

Metronome precount feature LIVES!

Posted: Fri Feb 23, 2018 12:42 am
by Tim E. Real
I have done what some said couldn't be done.
Precount was disabled for what, 10 years now?

It's back, better than ever. In git master now. Just a small triumph :wink:

See the ChangeLog and the new README.metronome for details
about how to use it and how it works.

I just realized last night that it shouldn't always work in play mode.
I'll need to add another metronome dialog option button for that.

And, I guess I will ask here since Robert will get this:

There are two existing option buttons so far: Prerecord and Preroll.
I researched Preroll in other apps and I think I get it. It's disabled while I try to implement it. Hang in there!
I believe that like other apps, you can already accomplish this manually using our punch-in and punch-out.

But what is Prerecord? So far I made it simply whether to turn on precount in Record mode.
But I'm certain that was not the intention of the option.
I'm guessing it is similar to preroll, except it turns on the recording immediately at the preroll location
rather than at the current play head location as preroll does?

I noticed some apps seem to make their concepts of precount and preroll mutually exclusive,
if they even supported both.

Any preferences out there regarding precount while I'm in the code? Wants? Needs?

Thanks.
Tim.

Re: Metronome precount feature LIVES!

Posted: Sun Apr 08, 2018 8:31 pm
by Tim E. Real
Tim E. Real wrote: I just realized last night that it shouldn't always work in play mode.
I'll need to add another metronome dialog option button for that.
Done! Sorry for the delay. In GIT master now.
Added precount 'Precount on play' and 'Mute metronome' features.
Precount on play allows precount during play mode. Mute metronome mutes
the metronome after precount, this is handy if only precount is desired.

Some major timing fixes and a few other things were done along the way. See the ChangeLog.

Floating point math has now been BANISHED from ALL timing functions, replaced with large-integer math.
Timing is... "as perfect as it can be" now.

Tim.

Re: Metronome precount feature LIVES!

Posted: Sun Apr 08, 2018 8:53 pm
by folderol
Tim E. Real wrote: Floating point math has now been BANISHED from ALL timing functions, replaced with large-integer math.
Timing is... "as perfect as it can be" now.

Tim.
Interesting. I've been thinking about that myself for some things. Not only from the precision viewpoint but also calculations should be faster.

Re: Metronome precount feature LIVES!

Posted: Sun Apr 08, 2018 10:18 pm
by Tim E. Real
folderol wrote:
Tim E. Real wrote: Floating point math has now been BANISHED from ALL timing functions, replaced with large-integer math.
Timing is... "as perfect as it can be" now.

Tim.
Interesting. I've been thinking about that myself for some things. Not only from the precision viewpoint but also calculations should be faster.
Isn't floating point generally faster I think because of the hardware math co-processor?
For integer math I found it depends on the platform and CPU. For example I read that the Intel I7 has an improved divider.
If on a gcc/clang 32-bit platform, there is no intrinsic 128-bit integer variable support. But there is on 64-bit platforms.
And Microsoft has a different take on 128-bit support.
So I was forced to use a large-integer math library, which has compatibility features.
Worst case (non gcc/clang or non-Microsoft platform) might actually be slower than floating point since the library
must synthesize the math by breaking it into pieces.
But then hey, there is no common 128-bit floating point support anyway, so 128-bit integers are a must then.
Disturbingly, I researched and read that Visual C/++ has never supported long double floating point,
thus never being able to take advantage of 80-bit floats which have been around a long time now. Very weird!
Anyway, I just got sick and tired of all the inaccuracies of floating point. The problems never stop with it.