Hi there, just can’t find the solution so i may ask you: I have set a loop region and hit play with loop enabled. The Loop plays from the first loop marker and loops as it is supposed to do. Problem is: i have a really long loop and cant find a way to start the loop right before it’s end to check the loop point without listening to my whole 20 minutes of looped material. What am i missing? Thank you in advance!
1 Like
This is Ardour’s current behavior and cannot be changed. Several people have complained about it, and there are reports in the bug tracker. Changing the behavior is non-trivial (in terms of programming).
1 Like
Thank you for this super fast reply! Sad news, but at least i now know it for certain. I often have to export looping content for theater productions and fixing this would be absolutely fantastic!
You may launch the loop the use the shuttle full speed to go faster towards the end of loop though the max full speed of the shuttle being 8 if your loop weighs 20 minutes you’re still stuck on the shuttle for almost 2minutes and half while listening mouse people voices 
(suggestion for devs, add a special *64 or *128 max speed factor to the shuttle, possibly armed with a specific switch/key/button?)
It’s not possible to stream from disk at 64x or 128x speeds for sessions of any significant size, which is why the maximum speed is limited to 8x.
1 Like
So while this is likely true at the moment for larger sessions (Read 64+ tracks etc. at 48k) that are all reading at the same time, I think even in those cases some of the fastest SSDs these days may be able to do this, and before to long even that may be more common place. This is also worst case scenario in that all 64+ tracks have regions being played at the same time, etc. when realistically for many people that wouldn’t be the case, and on top of this in many cases we are dealing with smaller sessions.
Given average SSD speeds of around 500MB/s these days, you can likely still get 24 tracks streamed from disk at 128x speed at 48k, etc. so it may make sense to allow this in the long run, especially given the same caveats about typical vs worst case scenario. The real question then becomes how to handle it when the disk can’t keep up with what is being asked for that from a UI perspective. My gut would say that it goes silent on a failure and stops trying to read, or that it falls back to a slower speed, but I can obviously see reasons either might not be a good answer.
End result is that I believe that rather than aiming for the worst case, it might in this case be better served to allow for more typical use cases. My own personal opinion though and I certainly may not pick this hill to die on in terms of 128x speed, but I can definitely see points in my workflow where larger than 8x speed probably would have made sense as I am searching through long timelines etc.
Seablade
@Paul
I understand your point and that’s why I penned “add a special x64 or 128 factor”, thinking that it’d be somewhat “virtual” read mode using buffering from shifted bits addresses but of course you’re right in that’d it’d be a hard work on RAM and disks for big sessions, either stuffing too much pre-read in mem or moving too much too fast the harddisk heads.
Maybe an idea for special needs on tiny to small sessions, that’s why I thought it should be a really specific and voluntary choice to “arm it” knowing it may or may not go well 
to chime in with idea coming from other daws:
when loop is enabled (since this is the topic)
- some daws continue to play from wherever the playhead is - and when playback reaches loop markers, it just loops
Bitwig example:
what about adding special marker for this situation?
add marker which will be the playhead start when loop is enabled? when marker is not in timeline, play loop as it is already?
We don’t need a special marker.
Ardour used to behave the way Bitwig does. It was changed somewhere between 6.0 and 7.0, I think based on some user input. The aftermath has shown it to be a mistake.
However, it is not trivial to reverse the design, which is why for now, it remains as it is.
2 Likes
thanks for explanation. It now makes sense - since it’s not trivial to change it
since i understood opposite of non-trivial - from your first reply:
1 Like
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.