Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
transport doesn't stop at the end of the session (resolved)
#1
First day with Mixbus v8 (8.1.378) on Windows and  transport doesn't stop at the end of the session when cue clip is used,
although tick marked in the preference->transport->general.

This also occurs in the test session
Reply
#2
That is correct if the Cue is set to loop it will loop forever. If you want everything to finish at a defined point you need to put a Stop cues marker on the Cue ruler. Or set the follow count of the last cue to a defined number of repeats.
Macmini 8,1 | OS X 13.6.3 | 3 GHz i5 32G | Scarlett 18i20 | Mixbus 10 | PT_2024.3.1 .....  Macmini 9,1 | OS X 14.4.1 | M1 2020 | Mixbus 10 | Resolve 18.6.5
Reply
#3
@durutti:

@Dingo is correct: if you have an 'clips' loaded on the cue page, then the option "stop the transport on Session End marker" can/must have no effect.

There are several inter-releated issues here:
The default Session End marker is around 5 minutes (going by memory, here)
If you import or record something, the End marker is automatically set at the end of the region, which could be very short.
If you are 'live' triggering the clips and cues, the transport would stop unexpectedly, which was perceived as a bug.
If you locate beyond the End marker, then you can't roll the transport at all, and therefore clips and cues would not fire, which was perceived as a bug.

After trying several alternatives, we decided that the best option is:
a) leave the option working as-is for those people who record linearly on the timeline. if you don't use the Cue page, it works exactly like the past
b) for those who use the Cue page, that option must be ignored

I think the best answer is to add some text to the option that says "(this has no effect on sessions that have any Clips on the Cue page)". It's hard to describe 'why' that is the case, but some clue would be better than none.

-Ben
Reply
#4
I already wrote to Nathan a few month ago about this issue (as I considered that as a bug as well). In my opinion, this decision was a bad one as you should never change an obvious functionality. ("End" marker is obvious I guess;-) and if you don't want the transport to stop at the session end, there IS already an option to prevent that.
So I either would like to have another option to recover the old behavior or the transport should stop if the "Stop cues" marker is added at the same position or somewhere before the "End" marker.
MB 32C 9.1.324 / Ubuntu 22.04 LTS - KDE / Kernel 5.14.0 / AMD Ryzen 7 3700X 8-Core / NVIDIA GP108 Driver 390.147 / Focusrite Scarlett 18i20
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)