Unexpected clip transport and play mode behaviour for audio

[Dalvinio]

Today I updated from Avenue 4.2.0 rev5894 to Avenue 4.2.1 rev6015 for OS X. I'm running OS X 10.10.4 on a 2014 MacBook Pro Retina (no discrete graphics card).

The release notes for 4.2.1 mentioned the following fixed issue:

[FIXED] Retrigger and Continue modes are confused if clip start offset is set in preferences

This seems to respond to the issue mentioned in this thread (sorry - couldn't post URLs) which was determined to be related to the "Clip Start Offset" configuration setting having a value larger than 0. This was also mentioned in this thread (sorry - couldn't post URLs) along with the comment that clearing out the prefs got rid of the problem.

I was experiencing similar issues which is why I updated to 4.2.1. It looks like the issues are not entirely fixed, or I misinterpreted the other threads. I tried removing the preferences file and other configuration files (including those in the Library) but this didn't help. Setting the Clip Start Offset to anything but 0 makes the issues resurface.

Here are the relevant settings and deck configuration:

• Preferences > General > Clip Start Offset set to anything but 0.
• Start off with a new, empty composition.
• Assign an audio file on a clip. I used an uncompressed wave file (44.1kHz, stereo, 4:00 length) but the unexpected behaviours also occur with compressed audio files, like MP3s.

Please note that I haven't tried this with video+audio media, but I expect the same problem to occur, given the other threads. Here are the steps for reproducing the various unexpected effects:

TEST A: Unexpected single forward jump

1. Make sure the clip is in "Timeline" transport mode and the play mode is set to "Restart".
2. Connect the clip, i.e., make it start playing by clicking on the clip.
3. Audio playback will start from the beginning.
4. After letting it play for a few seconds re-connect the clip (click it again) without stopping playback.
5. Playback jumps forward and playback continues from there. If you repeat this test, you will notice that in most cases the postion the clip jumps to was the last known position before you would have disconnected the clip, i.e., by clicking on another (empty or not) clip on the same layer or the position it would have been in if playback had not been interrupted. And it looks like this is somehow kept even if you restart Avenue as long you don't start a new composition (even without saving your composition).

The expected behaviour for step 4 is for playback to restart from the beginning.

TEST B: Re-connecting the clip has no effect

1. From the context of TEST A, make sure the audio is playing.
2. Now change the play mode to "Continue" and then back to "Restart".
3. Try to reconnect the same clip without stopping playback.
4. The clip will continue to play uninteruptedly.

The expected behaviour for step 3 is for playback to restart from the beginning.

TEST C: Unexpected repeated jumps

1. From the context of TEST B, put the play mode to "Continue".
2. Re-connect the clip.
3. Playback will jump.
4. Repeat from step 2. Every time you do this, playback will jump.

The expected behaviour for step 2 is for playback to continue unterruptedly.

TEST D: Unexpected continued playback

1. From the context of TEST C, set the play mode to "BPM Sync".
2. Reconnect the clip.
3. Playback will continue uninterrupted.

The expected behaviour for step 2 is for playback to start from the beginning.

TEST E: Unexpected single forward jump playback

1. From the context of TEST D, set the play mode to "Timeline".
2. Confirm that the play mode is still set to "Continue".
3. Reconnect the clip the clip a couple of times to confirm playback is still jumping around.
4. Put the play mode to "Restart".
5. Reconnect the clip a couple of times to confirm that playback still jumps just once.
6. Put the transport mode to "BPM Sync".
7. Try reconnecting the clip multiple times.
8. Playback will continue uninterrupted.

The expected effect for step 7 is for playback to reset (on BPM Sync now).

If you run test A from step 4 in this context the you will notice that the unexpected effect of test A also occurs here. I hope this can get some responses with workarounds that do not involve setting the Clip Start Offset to 0 until an update resolves this issue.

[Joris]

Yes, apparently we fixed this for the cases where you would first connect to a different clip and then come back to the first. But not for repeatedly triggering the same clip.

You can imagine angry looks were cast around the office the day we found that out. Unfortunately, the only way to not have this behaviour is to wait for our fix on 4.2.2

Btw, thank you very very much for your clear and precise bug reports!

[Dalvinio]

Thanks for the quick response. Acknowledgement of the issues and confirmation that they will be fixed with 4.2.2 is good enough for me.

Adjusting the Clip Start Offset made my controller setup feel a bit more responsive. I just started playing around with a new controller and from the looks of it I can do without this setting for a while as I'm fiddling with a new setup. I'll have enough to do while waiting for 4.2.2 to be released. Good luck with the fix!

BTW: also glad to hear the report was useful to you. I run a small team of developers and I'm familiar with that particular feeling caused by vague bug report from users ...