Sample startpoint bug

Bugs
#1

IMPORTANT - PLEASE WATCH THE VIDEOS ON YOUTUBE, ITS VERY HARD TO SEE IN HIGHLY DOWNGRADED SNAPSHOT WE SEE HERE DIRECTLY.

Hey :slight_smile:

There seem to be an issue with sample startpoints, when using Vital in a DAW. I am using Logic in this example, I don’t know if this is the case in other DAWs to, but I think it needs to be reported since it looks like a bug to me.

The sample startpoints has the tendency to move when I copy/paste presets using Logic own preset system. I tried to give 2 examples below, that demonstrates it.

First example:

  1. I start from an init patch.
  2. Then load a sample.
  3. Use the copy/paste function of Logic to copy/paste the sound.
  4. See the sample move/change.

This example is subtle, it’s the first time I tried to recreate it on purpose, but you can see it changes the start of the sample.

Second example:

In some cases it’s much worse, than what I showed in the above video. I found out that if you save a preset within the DAW, in this case Logic, using Logic’s own presets and then copy/paste, it will move the sample, every time you paste the preset. A tiny bit. In this video below:

  1. Save the preset in Logic’s own format.
  2. Copy/paste the preset in Logics own format and then save it again.
  3. Do step 2 over again, always copying from the last saved preset.
  4. See the start point move more and more to the right, for every time you copy/paste/save/load a new preset.

In this video I already saved 8 presets, following the above steps which I then change from the the first saved preset and move on to the 8th saved preset. You can see the start point move from the first preset to the last 8th preset, there is a bit of a difference.

Anyway, just thought I’d mention it, as it looks like a bug.

1 Like
#2

Interesting find.

Could you try muting the oscillator and exporting/bouncing the sample played by vital to audio?
If it is moving each print should change as well, even just a slight phase offset - this will hopefully confirm it’s not a visual or UI bug and actually effecting the sound

#3

It is audible.

I used that click to add click for kicks and the reason I noticed was because all my kicks suddenly sounded different. So I checked what it could be and noticed the sample had moved to the right… Only way to get back to the original position/sound, is to reload the sample every time you load a preset/Logic project… Which is not ideal to do.

#4

Synths may act differently when rendering though, unless it’s a realtime render or recording.

1 Like
#5

I think I encountered the same issue in a similar scenario in Vital 1.5.5 macOS arm64. Here’s a video of me loading a sample that has only 193 samples (0.4% of a second). I save the preset and load it again, in a loop several times. Since the sample is so short, you can see it shift to the right each time.

I was messing around with the (outdated?) C++ of Vital and wanted to confirm that if I loaded a JSON file and exported it, that the result was the same as the input. I noticed that in the JSON, the “samples” value (a long string of base64 encoded text) was changing. It was staying the same length, but more "A"s were being written in the first couple of values (A represents zero). I think I found the bug in the code (major shoutout to Claude :sweat_smile:). It turns out there needs to be an Sample::kBufferSamples offset inside the function Sample::stateToJson. Here’s the corrected code:

  json Sample::stateToJson() {
    json data;
    data["name"] = name_;
    data["length"] = data_->length;
    data["sample_rate"] = data_->sample_rate;
    std::unique_ptr<int16_t[]> pcm_data = std::make_unique<int16_t[]>(data_->length);
    utils::floatToPcmData(pcm_data.get(),
                          data_->left_buffers[kUpsampleTimes].get() + Sample::kBufferSamples,  // Add offset
                          data_->length);
    String encoded = Base64::toBase64(pcm_data.get(), sizeof(int16_t) * data_->length);
    data["samples"] = encoded.toStdString();
    if (data_->stereo) {
      utils::floatToPcmData(pcm_data.get(),
                            data_->right_buffers[kUpsampleTimes].get() + Sample::kBufferSamples,  // Add offset
                            data_->length);
      String encoded_stereo = Base64::toBase64(pcm_data.get(), sizeof(int16_t) * data_->length);
      data["samples_stereo"] = encoded_stereo.toStdString();
    }
    return data;
  }

Now I get the JSON invariance that I wanted. However, I didn’t yet test this in a complete build with a GUI (the code is outdated from 1.5.5 anyway).

1 Like
#6

Awesome :slight_smile:

It looks pretty much like the same issue that I have or atleast related to it.

I am not the familiar with JSon, so would never had found that this could cause it.

So I guess we just need the developer to take a look at it, for a future update.