Bounce Version 4.4 - Accessibility Updates for Blind Users, Wine Compatibility for Linux, & Sub Millisecond Precision Tweaking

Minor bug fix update 26th April 2013 - see bug fixes

Minor update 24th April 2013 - see Change log. - adds option to permanently hide the "Do you want to reset" message you normally get every time you change to a different metronome type in the drop list.

Bug fix update 20th April 2013 - see Change log.

With this new version 4.4.

  • you can run Bounce on Wine under Linux with close to 100% compatibility (only export of video directly to a file doesn't yet work on Wine of the features tested). See Wine compatibility report
  •  has better accessibility for blind users.
  • has sub millisecond timing available if you tweak it carefully.
  • Has several other new features and bug fixes since the most recent upload of the release on 18th February.

You can get the latest version from the download page.

Tips for Bounce under Wine on Linux : you may find it helps to install Qsynth (so you have a soundfont synth similar to the Microsoft GS wavetable synth). Also, it can help with any timing issues to use the low latency kernel for Linux. See Recomendations for Bounce on Wine under Linux

Here is a summary of what is new since the last update of the release

  • Accessibility update. Many improvements in the way the version for blind users works.
  • 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. Also it now has a preset button for Mac Santiago's Diminishing Click - see Tempo >> Automatic Tempo and Rhythm Changes - in the More version of that window.
  • 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

New minor features include

  • Sort by Beats, in the more version of 3D Bouncing Ball Visuals (Ctrl + 226) sorts with the part with most beats in the front. 
  • Customize the width of the time signatures in the 3D bounce window: In More version of  3D Bouncing Ball Visuals (Ctrl + 257) "Set 3D bounce TIME SIGS WIDTH". The default is to make them wide, so that you can enter the beats and subdivisions with many decimal places of precision if desired. Now you can set it as you like here.
  • Separate volume control for each part for the 3D bounce - lets you change the volume with simple left click,and change instrument for the part with right click. 
  • Set the size of the bouncing ball separately for each part. This is in the More (twice) version of Type of Ball etc (Ctrl + 221)
  • For the bounce inside ovals, or outside ovals, you can now set it so the bouncing balls continually bounce on the same spot, while the ovals (and the ticks on them) rotate. This option is in the More version of Bounce Patterns (Ctrl + 227)
  •  Now has a preset button for Mac Santiago's Diminishing Click - see more version of Tempo >> Automatic Tempo and Rhythm Changes 

Also, there are many  bug fixes in this upload,.

There are many other new features and bug fixes since the first upload of Bounce 4.3 in September 2012.

For details see the Change log, and the bug fixes.

Help for the timing tweaks

First you can run the note timing test in the Tempo drop menu and see what it reports.
If you get timing issues, or if you want to try for sub millisecond timing, switch on the busy wait and see if this fixes any timing issues.
Then you need to adjust the amount of the busy wait. Shorter is better. Try playing a rhythm and see how much of your busy wait gets used - you can see this information in the More version of the Timing Tweaks window. Default is 10 ms but you may need more than that or may not need all of it.
If you get apparently perfect timing, but the rhythm still doesn't sound exactly regular although the times in the diagnostics look perfect - then the high performance timers in Windows may be varying in their rate (what they call frequency drift). This makes it impossible for any program to know what the exact time is on the millisecond level at least using the standard timers. 
If this happens try switching on the HPET hardware timer for Windows using the instructions for the Midi Timing Tweaks for Accuracy window. This is a tweak that usually improves the performance of Windows but a minority of users find it impacts on performance of other programs. So it is something to experiment with for now. If it causes issues then follow the instructions to revert to the default way of timing notes in Windows.
I am looking into other options for the future. Particularly it might be possible to access the hardware HPET timer directly (even when Windows doesn't use it itself) via a driver under development by Jan Wassenberg, more about this later if it works out.

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

The best way to do this is to record the notes to audio as they are played.
Here is an example of a recording where the timers reported to Bounce that sub millisecond accuracy was achieved - but ears tell you otherwise. A recording to audio confirms that the ears are correct in their assessment and that the timing was not perfect. This was with Windows set to its default configuration, not using the HPET timer, and on a laptop with Turbo Boost. - for power saving.

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
Details for frequency drift: see 2.4.1 Timer Accuracy Rules in the specification
  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.