With this beta, you can run Bounce on Wine under Linux. It has better accessibility for blind users (work in progress). And it now has sub millisecond timing available if you tweak it carefully. There are several other minor updates and minor new features.

April 14th: many minor edits, some new features and some bug fixes. This is a release candidate. I may release it very soon, possibly tomorrow. Details of the changes after the release.

You can download the beta here:
http://bouncemetronome.com/Setup_Bounce_Metronome_w-2013-04apr14-Beta.exe

Since it is a beta, it installs into a separate folder by default. It won't interfere with your existing Bounce Metronome installation and also has its own separate uninstaller.

This is quite a major update  with simultaneous fairly large scale changes in several parts of the program. That's why I decided to release it first as a public beta. This is just for a short time hopefully, while I write up the changes so far, wait for feedback from keen users who are beta testing the new features, and fix any remaining issues.

I expect to do the release proper in a few days time.

Basically, I have many pages of changes to write up and check. Also expect feedback from several groups of users of the software about the new features. So with the combination of those two, then it will just take a few days to go through what is left. So better to do a public beta first.

I might even make this a new version number say to Bounce 4.4.

Anyway here is a summary of what is new

April 5th

First public upload of this beta (April 2nd)

• Accessibility update. Details here may change depending on feedback from blind users of the software who try out the beta. This is one of the main reasons why I am releasing it as a beta first.
• Bounce can now run under Wine on Linux. You don't need to do anything special. Just install it and nearly everything works. There may be some timing issues, and animation glitches still to be worked out. Also you can't export the 3D Bounce videos to file when it runs under Wine. Don't know of any other major issues.
• Sub millisecond timing. To try this then go to the Tempo drop menu. Then try the Test Midi Note Timing. If you get occasional errors of more than 1 ms, then go to the Midi Timing Tweaks for Accuracy window (Ctrl + 261), The busy waits option there can make sub-millisecond timing possible, depending on your computer and your version of Windows and settings.
• Minor features include: in the 3D Bounce Visuals (Ctrl + 226) there is now an option Sort by Beats, to sort the parts by the number of beats, with the part with most beats in the front.
• Bug fixes include: if you set it to 1/4 with 4 subdivisions (say) it doesn't count subdivisions but instead counts the beats as 1 2 3 4 just as for 4/4 - fixed

There are many more minor features and bug fixes in this upload, but I need to go through and write them up and can't actually remember what they all were now :). Those are just a couple of the recent ones.

April 5th beta bug fix

Fixed a bug in the midi notes for the public beta - it was only sending note ons via midi out - though logging all the other events as if they were sent. It is easy to miss this when you play non melodic percussion as usually only the note ons matter. This was introduced in the 2nd April public beta upload. 

With non melodic percussion the main symptom you will notice is that the auto stereo pan doesn't seem to do anything. Of course the harmonic features didn't work at all with the 2nd April beta upload. All my attention was on the new exact timing features, tested for non melodic percussion which is why I didn't notice this in the first upload of this public beta.

All fixed now.

Help for the timing tweaks

How to test the accuracy of timing of notes in an objective way

As you can hear, then there is a major audio glitch in the second half of the recording. 

This recording was done with busy waits at the end of the sleep between the notes. So - in that delayed note then Bounce Metronome was looping around in a busy wait throughout those extra 8 or 9 ms, waiting for the Windows timers to say that the time was ready to play the note . It was all ready to play the note, but waited because the timers said that it was too early to play it yet. This is using high precision timers - they report the time to Bounce Metronome in microseconds and with well sub millisecond precision.

The reason it is played late is only because the Windows timers were running slow momentarily, and so reported the time at the sub millisecond level incorrectly to Bounce. This is a known issue in Windows, and the documentation makes no guarantees about accuracy of timing or frequency drift when making millisecond timing measurements on Windows.

The high resolution millisecond or sub millisecond timers in Windows are precise, high resolution, but with no guarantees of accuracy. The only guarantee they give is that many (not all) of the timers are  guaranteed to not go backwards in time.

The recording was made on a busy machine, with browser window open, and with the Turbo Boost monitor showing the speed varying frequently between various values in the range from 2.3 to 2.8 GHz. It is not as simple as that the time is just measured more slowly when the cpu speed is 2.3 GHz, it seems rather that with the speed varying so much, the time gets confused occasionally and runs a bit faster or slower than it should for a short while.

And this is what you get with the HPET hardware timer switched on, sub millisecond accuracy of the audio recording

 

HPET Specification

The HPET specification does have guarantees of accuracy and of timing drift, which are musically acceptable, e.g. frequency drift at most  0.05 % so for instance, you would expect errors of no more than a tenth of a millisecond due to frequency drift in a 200 ms note.

That's no surprise since the specification is the result of a joint initiative between Microsoft and Intel to create a timer that is suitable for multimedia timing.

Sadly, for some reason, Microsoft didn't make this timer the default setting for Windows. I've seen in the forums where (mainly games players) discuss it that some users find various issues when they enable the HPET timer, though others find it just improves performance all round (I am writing this on a laptop with it switched on). It's a guess but perhaps these rarely concerned issues might be the reason why it isn't switched on by default?

Wikipedia article: High_Precision_Event_Timer

Detailed HPET Specification from Intel.

Summary - see 2.2 Minimum Recommended Hardware Implementation

• Clock Frequency : Fmin = 10 MHz (means resolution better than a tenth of a microsecond)
• Clock Frequency Drift : +- .05 % (500 ppm ) - Over any interval >= 1 Millisecond 
  +- .2 % (2000 ppm) - Over any interval <= 100 Microseconds

1.  The timers are expected to be accurate over any 1 ms period to within 0.05% (500 ppm)of the time specified in the timer resolution fields. 
2. Within any 100-microsecond period, the timer is permitted to report a time that is up to 2 ticks too early or too late. Each tick must be less than or equal to 100 ns, so this represents an error of less than 
3.  The main counter must be an up-counter. Two consecutive reads to the main counter may return the same value if the access latency to the timer is less than the clock period that feeds it. For back-back reads, the 2nd read must never return a value that is less than the 1st read, unless the counter has rolled over and actually reached the same value. 

This only makes a difference to Midi timing and time stamps

Note - the HPET timer only makes a difference for timing that is done using midi and similar methods.

So - that includes programs that play notes in real time via midi - and it might also make a difference to time stamps when recording a performance to midi (e.g. from midi keyboard) in real time.

It doesn't make any difference to audio that is streamed directly, as that is done using a different method, by filling in buffers - and the application doesn't have to know the current time, it just keeps count of the number of samples so far sent to previously played sound buffers. Your soundcard has its own separate clock which it uses for streaming the sound buffers at a steady rate, and this is not normally accessible to applications.

So for instance, the Beeps metronome in Bounce Metronome shouldn't be affected by your choice of whether or not Windows is set to use the HPET timer.