Confirmed... MAC Capitan. Strangely enough it did not happen every time. I had to play the file a few times before bouncing. This is worrying....

Edit: Bounce selection also makes the click jump to another place
When removing the first marker the bounce is correct and the location of the first marker determines the position of the bounced click (positions click varies depending on the distance first marker)

Robert Johnson III wroteConfirmed... MAC Capitan. Strangely enough it did not happen every time. I had to play the file a few times before bouncing. This is worrying....

It's all a bit unpredictable, yes. Also moving a bend marker itself back (ALT+drag) is altering the audio behind it at each move when there's no following bend marker.

I sure hope S1 dev’s are aware of this and a fix is coming soon… Thanks for the heads up! This could really mess up an arrangement when bouncing a tracks.

I've experienced this too unfortunately, and yes I agree it's a little worrying to have something like this happening on such a fundamental part of the program. It definitely needs to be sorted.

Niles
Thanks for reporting the issue but please put the issue in this format to make it easier to document the steps to replicate.


1. Program/feature area:
Audio Bend

2. Type of issue: (crash / freeze / wrong behaviour / annoying / gui issue etc.)
Wrong behavior

3. Issue description:
Rendering audio bend changes produces unexpected results

4. Steps to reproduce:
1) Render two bars of the click track.
2) open editor and click view Audio Bend markers
3) Add markers at the beginning of a click, before it, and after it.
4) Move the Click later in time.
5) Bounce the event to a new track <== click will no follow previously moved marker position
6) Un mute the original event and drag the first marker ahead in time.
7) Bounce the event and you will see another misplaced click.


5. Expected behavior or outcome:
Bounce to new track renders an event that is equal to the bend maker edited event timings.

Still standing in 3.5.2

Confirmed....

Can someone confirm that it worked as you expected in any earlier version? Which version?
Or is it the normal behavior with very short bend pieces in realationship with the elastique timestretch engine?

So the question is, is there something broken in an Studio One update?

Ari

Still present in 3.5.6.

It screwed up a good piece of my recording as I bounced every track and only later noticed it. It doesn't seem to happen on every track, though, since it did render some properly.

Does anyone know a workaround ?

mauricescholz wroteStill present in 3.5.6.

It screwed up a good piece of my recording as I bounced every track and only later noticed it. It doesn't seem to happen on every track, though, since it did render some properly.

Does anyone know a workaround ?

Wow a year old bug it appears?
Your OS is?

I have been testing this too and yes I see the same issues. But there is a workaround though and a simple one at that.

Open the audio bend panel and do an ANALYSE first. Fine tune the threshold settings so all the bend markers that are created are clean etc.. Even if they are not on the beat it does not matter.

Move the marker you want to change. Bounce to a new track you will see all the others have not moved, only the one you have moved.

I tend to this anyway. It is very safe. Obviously all the bend markers need to be in position in order to save them from being moved in any way.

If you all reported this to tech support rather than rely on somebody else then maybe a solution could manifest:
http://support.presonus.com/


Cheers.

Hi @Jemmusic By "all the others" do you mean the position of the other bend markers? Asking to be sure, because the timing of the audio file is (for me) the problem, not the position of the markers. Audio changes position when bouncing in place with bend markers. Still happening in the latest version.

Analysing makes no difference, just tested this to be sure, but maybe I’m missing something? Tested on Windows 10 latest and Mac High Sierra 10.13.5

Also quantizing the audio is a problem [Add an option for quantizing from beginning of transient rather than end - Questions & Answers | PreSonus](https://answers.presonus.com/9651/optio ... r-than-end)

No idea how many times this needs to be reported, but as far as I know Presonus is aware of this (and easily confirmed if you follow the screen capture).

Initial report is fixed in 4.1.4