- April 2015 (1)
- March 2015 (1)
- December 2014 (2)
- August 2014 (1)
- July 2014 (2)
- June 2014 (4)
- May 2014 (8)
- April 2014 (1)
- February 2014 (1)
- January 2014 (1)
- December 2013 (1)
- June 2013 (3)
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
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
- 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.
- 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
- 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.