BPM values specified to three decimal places

VST Live
1

Hi all,

I’ve noticed anomalous behavior from the software if particular BPM values are used for the tempo entered either in the transport bar or in the tempo track.

The anomaly occurs using BPM values specified to three decimal places, such as with 136.232.

The entered bpm value is systematically adjusted to the third decimal place, when moving to another song and then returning to the previous one, or when the project is saved, closed and reopened.

As always, thanks for the support.

2

You appear to be correct, we will fix it, thanks for reporting!

1 Like
3

Hi @musicullum,

a kind reminder for my report especially for its importance.

Unfortunately I can’t accurately import my work done over the years with Cubase into VST Live due to the imprecision of the BPM in the scenario described and for this reason I eagerly await a fix to the issue. :blush:

Thanks as always for the support.

4

… we will push the problem to the top of the list. It would be very helpful if you could give us one of your project which you will import to VST Live. Then we can re-check out fix. We just need the Cubase project file, no media. You can send it me to m.spork (at) steinberg.de, if you like.

Michael.

5

Hi @Spork,

First of all, let me clarify that I am not using the VST Live> Project Export… function provided in Cubase for exporting projects to VST Live, but I am using audio and midi material contained in projects produced with Cubase after doing Export>Audio Mixdown in case of audio tracks and Export>Midi File… obviously in the case of midi tracks.

Having clarified this, however, I can confirm that the reproduction of the issue is extremely simple to put into practice.

It involves performing the following simple steps:

  1. Create a Tempo track in a Song of a new VST Live project
  2. Set Tempo (even on the default position) with a value like 136.232 or 112.455 or 104.993 or 93.675
  3. Note that the BPM value shown in the lower zone differs immediately from what was just set in step 2.
  4. Create a second Song and return to the first Song created by default
  5. Notice that the BPM value reported in the Tempo track is different from what you entered in step 2.

The issue just described obviously affects the lengths and positioning foreseen for the audio/midi events subsequently imported into VST Live in the timeline.

I remain available for any requests for clarification.

Thanks for all.

6

Hi @Spork and @musicullum ,

did you get to try the test case described in my previous post?

Do you have any news about this issue?

As always, thanks for your support and patience. :blush:

7

… sorry, it took longer. It’s fixed now. Next update.

/Michael.

1 Like
8

Hi @Spork,

with version 1.3.2 Pre-Release of the software, the issue actually seems to be fixed. :blush:

There remains a minor bug, perhaps connected in some way to the main issue: in the case of using BPM with decimal, sometimes the position of the End Marker, after reopening a previously saved project, is shown with an approximate value to the saved one.

For example, for a Song with BPM set to 125.050, I save the End Marker at the value 0171.1.1.000 and when I reopen the project I find the same End Marker set at the value 0170.4.4.119.

Thanks again for your support and patience.

9

… thank you for your patience. We’ll fix that!

/Michael.

1 Like
10

… fixed. Next Update,
Michael.

1 Like
11

Thank you, @Spork! :blush:

12

Hi @Spork,

unfortunately the minor bug related to the post seems to still be present in version 1.3.11 Pre-Release released on Friday. :frowning:

I provide you a simple project example that highlights the issue:

Test on End Marker.zip (9.1 KB)

13

Hi @Giuseppe_Loffredo,

Thank you, I can reproduce it now. We’ve fixed

  1. New project
  2. Change Tempo to 116
  3. Select TRACKS and change EndMarker to 121.1.3
  4. Add Song_2 and select Song_1 again

Your problem goes

  1. New project
  2. Select TRACKS and change EndMarker to 121.1.3
  3. Change Tempo to 116
  4. Add Song_2 and select Song_1 again

Now the display glitch is visible. As a workaround enter 121.1.3 again to the EndMarker and save the project.

We’ll fix it,
Michael.

1 Like
14

Hi @Spork.

I don’t know if the fix was applied with the new software version 1.13.12, but unfortunately the bug still occurs.

Without applying any particular workaround, but simply setting the correct position of the End Marker to 121.1.3, saving and reopening the project, I always find an unexpected End Marker value set to 0121.1.2.119. :frowning:

15

… we are always trying to get back to the report and inform if the fix has made it to the next Release. This one did not make it. Please be patient, we are trying our best.

/Michael.

2 Likes
16

Sorry, no problem, I was just in doubt that the fix had already been applied and unfortunately it hadn’t had the desired effect. :blush:

I’m waiting for a communication when it will actually be possible to apply the fix. :slight_smile:

I have no doubt you are trying your best and thank you for your patience! :+1:

1 Like
17

… it’s fixed now and added to the next update.

See you,
Michael.

2 Likes
18

Thanks @Spork ,

the fix contained in 1.3.13 Pre-Release seems to have definitively resolved the issue.

1 Like