Should play position jump when adjusting loop & start?

[keeko]

Granted, there are work arounds, though not particularly elegant ones - by scubbing I assume you're referring to clicking on the clips waveform or am I missing a trick here?

I hope this issue is addressed in a future release to the satisfaction of everyone...

[robbmasters]

Granted, there are work arounds, though not particularly elegant ones - by scubbing I assume you're referring to clicking on the clips waveform or am I missing a trick here?

No, I mean mapping a rotary encoder to the thingy between nudge forward and nudge back.

[zeropoint]

I'm possibly missing something here but I don't have any audible jumping. I have the loop brace mapped to a rotary encoder on one of my faderfoxes and use it sometimes to riff around on a playing track. Provided the global quantise is set to the same length as the loop I get no stuttering at all it performs with perfect legato every time. It also comes in dead handy when I'm warping tracks. If I wanted to cue up a loop down the line without it going out to the house I'd just copy the clip to another track find the loop and leave it ready for when i want to drop it.......

[djsynchro]

Keep it coming!!!

[robbmasters]

it performs with perfect legato every time.

But I I don't want perfect legato, I just want it to go to the loop start when it reaches the loop end AND NOTHING ELSE. Surely that's what you'd expecrt of any loop?

[scientist]

i've always assumed that this served some useful purpose for every live user but me, but obviously not. if no one can speak up with a story of how they use it and how it can't be done any other way, then it doesn't even deserve a preference option and should just be changed.

[Tone Deft]

Ok here's the deal:
When Live 5 was in beta, Ableton changed the behaviour that when you move the start marker or the loop of a clip, the play position jumps.

There were some people at the time who were making a lot of noise saying it could be used as an effect making the play position jump and stutter. Then there was talk of being able to choose between the old and the new behaviour, and then the old behaviour was reinstated - no choice.

At the time I didn't really follow the whole thing so I didn't really know what was going on, or I would have voted for the non-jumping behaviour. (Or the switch.)

This behaviour is driving me nuts!!! When trying to find good sections of audio for example in a vocal take every time I move the start or loop markers the audio jumps, and I don't want that.

It sounds really amateur for a DAW for audio to jump. Also for DJing and playing Live it would be much much better if the audio didn't jump this way.

What do you think?
Please vote!

my harsh $0.02...
Ridiculous request. Live does a good job of keeping the play position accurate in relation to the start marker, I appreciate that. Your request is just asking for train wrecks.

IMO it's 'bad form' to move the start marker around, use the loop markers.

bumping your own threads is pretty obnoxious, but whatever.

pardon the tone of my post, it's a bit harsh.

[scientist]

my harsh $0.02...
Ridiculous request. Live does a good job of keeping the play position accurate in relation to the start marker, I appreciate that. Your request is just asking for train wrecks.

IMO it's 'bad form' to move the start marker around, use the loop markers.

bumping your own threads is pretty obnoxious, but whatever.

pardon the tone of my post, it's a bit harsh.

i think you misunderstand...part of the problem is that moving the loop markers DOES move the play head. i agree (though the original poster might not) that if you move the start marker then the playhead should move too.

[Tone Deft]

I understand. Moving loop markers will move play position around if you move the window so that the play position is outside the loop marker, but Live is just keeping things in time. When I warp I use 1 warp window and drag it along with the play position until I hear a spot that needs to be tweaked, then I leave the window there and adjust the warp markers.

[scientist]

I understand. Moving loop markers will move play position around if you move the window so that the play position is outside the loop marker, but Live is just keeping things in time. When I warp I use 1 warp window and drag it along with the play position until I hear a spot that needs to be tweaked, then I leave the window there and adjust the warp markers.

in this situation though, "in time" is relative. so even if live is keeping things in time with where the loop originally started...if your reference of what is "in time" is the loop you're changing, then live is actually incorrect and working in a very un-live manner. i'm guessing that most live performers who run into this problem don't need live to remember when the clip was actually started, because if you're moving your loop's position then when it started playing is irrelevant.
you've definitely brought up a good argument against the change: that if you're working a clip into a predefined arrangement and it needs to match elements, then you need live to remember where the clip started.
it doesn't bother me enough to want them to change it, honestly...i'd much rather they fix the library problems!

[robbmasters]

Your request is just asking for train wrecks.

Personally, I think the current set-up is more likely to create train wrecks. Unless you've been counting bars, you can't tell where Live's play head will jump to when you move the loop markers. That unpredicatability causes train wrecks. The fact that it could jump from the middle of a verse to the middle of a chorus also causes train wrecks.

If the behaviour was changed, you'd always know where the play head was going to be next. So train wrecks could be avoided.

When I warp I use 1 warp window and drag it along with the play position until I hear a spot that needs to be tweaked, then I leave the window there and adjust the warp markers.

You could still do that, if this was changed as requested.

Live needs to be predictable - especially during Live performance. The current behaviour is too unpredictable .

[Tone Deft]

Robb- That's why I use 4 or 8 measure windows. Once I got going with warping I can warp on the fly without trainwrecking, that includes old soul/funk material.

Part of it is that the groove of 2 loops can be longer than 1 or 2 measures, even if you stay on the '1' it might not be the right '1'.

Interesting to see there's so many different ways people use this feature.

[orge]

I'd noticed this, but it was bought to my attention by a friend who was really pissed that they changed the original behaviour. I think there are several arguments for trashing this behaviour (or at least providing an option) and not many for keeping it:

1. There is currently no way to do a "needle drop" by changing the start position of a playing track and re-triggering at the right time. Yes, you could achieve something similar by duplicating a clip, changing the start position and then re-triggering. However, I think there are compelling creative arguments for making this sort of process as easy as possible.

2. Even if you're not interested in dropping tracks like this, the current behaviour means that there's basically no way to change a start marker whilst a track is audible - unless you're audience are into "glitchy" sounds. What if you decide,on listening to a new track, that the default start position should be in a different place? You would have to either duplicate the clip (just to save it off??) or make a mental note to make a change once the track has finished.

3. The loop situation is probably worse in terms of unpredictability, although in practice at least you can get around the behaviour. Again, changing the end brace position, whilst a track is playing, is possibly going to cause a jump (at least, if you don't deactivate the loop beforehand). Where the play head position is going to end up depends on the number of times the the play head has been through the loop and how much you adjust the brace by. Consequently, it could be very hard/impossible to know where the play head will end up.

The only "excuse" for these features, as someone posted above, is that Ableton is keeping track of where a track/loop kicked off and is "turning back time". i.e. It's trying to fix what it perceives to be a mistake. The problem is, that it is second guessing what you would like to achieve and is probably more likely to mess your performance up, or constrain how you perform, rather than "fix" it. If Ableton behaved differently, it would still be possible to fix an incorrectly timed clip/loop by nudging and I would strongly argue that this should be left to the end user.

Finally, I would also like to suggest that the loop braces should not interact with the start marker when moved behind (they don't interact with the end). This would probably be less problematic if it didn't mess with the playhead as well, but it's still counterintuitive.

Unfortunately, whilst I think this would make quite a difference to Live's usability, I doubt that it is particularly high on the priority list... After all, it's not exactly a headline grabbing feature. I'm not holding my breath, but it would be nice to see Ableton addressing the stacks of usability issues that are affecting many of their existing users, rather than adding "whizzy" features. I had a look thorugh v7, the other day, and I was amazed to find that the "reveal clip in browser" function was one of the most useful things they had added (if only there was a away to script/MIDI control it...)! In fairness, there were some other additions (slicer/drum racks could be useful), but I really would feel more compelled to upgrade if it fixed issues that affected my day to day usage - and these are more likely to be workflow/usability related. I seriously hope that they get the balance right with the next update, there are some very simple things that would take a single developer a few weeks to put right:

This
Coloured Warp Markers/Waveform Annotation
Multiple Cue Points (pref with MIDI assignment)
Metadata support (at least reading)

In no particular order. In my opinion, these are the changes that would secure upgrade revenue from myself. I'm know there are others out there who would like to see these things implemented. They're not a lot of work, considering the revenue they may generate.

J