1.03 update issue resolved.

[mtingle]

I do not have any issues, either with the update crashing or smoothly moving regions with snap turned off.

I noticed on the video posted where smooth movement isn't working, that the time line is set to Min/sec. I wonder if this is an issue with projects saved with a Min/sec time line in previous versions of Auria? When I switch my test
project from beats to min/sec timeline in transport options I can still move regions smoothly with snap turned off, but the original project was saved with a beats time line when I upgraded from 1.02 to 1.03

Ipad 3, iOS 6, auria 1.03

pointyhat, so when you move a region in 1.03 it doesn't 'jump' initially like in this vid:

http://www.youtube.com/watch?v=UfCSbMFB ... e=youtu.be

If so that's very interesting. maybe it has to do with iOS 6 or ipad3 (or maybe I have a faulty finger).

[Rim]

How about where you're grabbing the region? I usually grab in the middle of the region, not towards the end.

Rim

[mtingle]

How about where you're grabbing the region? I usually grab in the middle of the region, not towards the end.

Rim

just tried a whole bunch of different places in the region at a variety of zoom levels. nada.

[Washboy]

Same here

So far we've only heard from a few users about this, but I get the feeling that it's nothing to do with iPad model (i.e. Rim and mtingle are using iPad2s, while pointyhat and I are using iPad3s). All four users are on Auria 1.03. However, both negatively affected users are still using IOS 5.1.1, while the other (unaffected) users are on IOS 6.

I may be wrong in thinking that Rim is using an iPad2 and IOS 6. Can you clarify please, Rim? Is it feasible that this could be a IOS-related issue?

@all-readers: can we hear from a few more users on their experience with precise region movement please, especially if you don't notice difficulty with it? Please quote your iPad model, Auria version and IOS version.

Many thanks.

[Trueyorky]

iPad 3, 32gb iOS 5 Auria 1.03 - no such issues.

I have studied all of the comments and videos and tried to recreate this. Rather than waiting a few seconds, my advice would be to start moving once you see the red outline because at this point you should have control. As long as you keep your finger pressed on the wave you can slide it around at will.

Looking at your video this is what I see...
1) press and hold wave until red outline
2) keep finger pressed but wait a few seconds
3) very slowly start to move your finger
4) wave catches up and snaps to where you are

This is what i do...
1) press and hold wave until red outline
2) as soon as wave shows red then start to move (quicker and more definite action)
3) no issue: wave moves freely to where my finger is

ps I upgraded to iPad 3 because of Auria. I found it worked on iPad 1 but it needed (and deserved) more power

[Washboy]

Thanks for the feedback Trueyorky, but I think you've misunderstood the problem we're having. The need is to be able to move a region, from its original position, but by only a very small amount. Moving quickly, as you suggest, results in a relatively large movement of the region - much larger than required. Hence the need to move slowly and with precise control.

I agree that, as soon as the region has turned red, it should be possible to begin sliding the region around. However, if you try moving your finger sideways, slowly, you may find that your finger moves but the region stays put until your finger has moved about 0.5cm. At that point, the region will 'snap' to your finger (jumping by 0.5cm in the process).

Although the region is now free-sliding, it's far away from where you want it to be and you have to slide it back to where you reckon it was originally and, only then, begin fine positioning the region. Of course, once you remove your finger, if you find you've misjudged, you have to start all over again because the 0.5cm 'jump' prevents simply 'nudging' the region a little further along.

I'd be interested to hear what you experience when you move your finger slowly, as described.

[robdean]

Exactly the same issue here. No snap is set, but it needs a big finger movement to get a clip moving along the timeline, even if I wait a few seconds before the movement. The natural response is to expect it to slide as soon as it turns red or a few moments thereafter. As it is, accurate free positioning is a real problem. My own personal style of working calls for virtually no snapping to timeline at all, and I do wish that 'off' resulted in fluid free movement of clips very quickly after the red highlight's appearance. This is the kind of issue which can make a huge difference to overall satisfaction with a user interface.
iOS 5.1.1 iPad v3

[Rim]

Keep in mind that the default snapping is a feature, not a bug. This is put in place to prevent the region from moving in case you decide to move it to another track. In this case, you usually want the snap. The problem is, it's difficult for a touchscreen DAW to know the difference between you moving to another track, and simply moving horizontally, especially if the movement is not perfectly horizontal.

The method I wrote works for me almost 100% of the time, but then again, I'm the developer I'll keep working on it to make sure it works for everyone.

Rim

[Washboy]

@Rim: Is it not fair to assume that an intentional vertical movement (I.e. to move a region between tracks) should begin with a faster, more positive gesture than in the case of a horizontal move? In other words, if a region has been touched long enough to consider it 'grabbed but locked horizontally', shouldn't the absence of a rapid vertical gesture, within a short time afterwards (half a second), warrant unsetting the horizontal 'lock'? But I guess that's roughly what you're doing already

I've been thinking though - I don't think I'd be bothered by the horizontal jump if there was clear feedback of the region's position, relative to its origin. Perhaps the 'LENGTH:' and 'OFFSET:' items in the Region Info panel could be replaced by relative position info, whenever the region is in 'Move' mode.

[Late edit] Perhaps it should be named "SHIFT:" and, like the other items, display using the currently selected time format. Crucially though, if the current time format is anything other than 'Min/Sec', the Min/Sec value should appear below it (in addition to it).

[robdean]

I understand the thinking behind this 'feature' but it's going to drive some users nuts in its current implementation. For example, I constantly import multiple tracks recorded outside of Auria (and have solid reasons for working this way). Not only do I want to sync them up precisely and easily, I often want to tweak them forward or back a few tens of milliseconds for artistic reasons. I sometimes re-order tracks to change which faders are next to each other, but virtually never move a clip from one track to another.

I appreciate that I have little clue as to the specific challenges of implementing such an ambitious app on this platform, but I can't help have the following questions occur to me:

1. Doesn't it make more sense to require an initial 'big pull' to move a clip to another track? It's going to snap to time anyway so an imprecise gesture is no big deal, wheras it is a big problem when adjusting timeline placement.

2. It's a shame if the only way to do this is for a clip to 'decide' where it is being taken in the first instant it is moved. I realise this may be due to some coding constraint, but surely the most logical and robust implementation is this:

Initially the clip sticks for just an instant as it goes red in case it is being highlighted but not moved (to safeguard against accidental movement).
Next, the clip makes a note of its original timeline position but allows itself to be moved freely.
If let go more than 50% of the way over a track boundary, the clip moves to that track, recalls its original timeline position and snaps to it.
If let go less than 50% over the track boundary of its original track, the clip just stays where it is let go on the timeline, with no snap in the time dimension.

In other words, is it impossible to have the app determine user intention when a clip is let go at the end of a move rather than try to do so in the first instant it is moved?

Rim, I feel for you given the hailstorm of stuff you are dealing with, but I guess it's better everyone pitch in whilst an issue is open rather than stay silent and then complain about your solution!

[mtingle]

A simple solution to this might be to use 2 fingers if you want to move a region vertically (and maintain it's horizontal position) - I find this a very useful and necessary function.
Then simply abandon the 'initial snap' thats programmed in altogether allowing for precise region control right from the start.

One should bare in mind that the whole point of the precision editing ability it to make very small smooth movements of the region allowing very fine control of its placement and as such no coarse movements can be used to active this function!

Both these functions of region movement are extremely useful and certainly add to the professionalism of editing in this app.

[Rim]

robdean, I've tried a similar approach before, but ran into issues when the user decided to drag the region quite a distance (while staying on the same track), then decide to move to another track. It's strange to have it snap back to the starting point in this case. Maybe I could revisit that method, and put a timer in place, or a window or movement, so if you exceed the window, it cancels the saved initial position.

mtingle, two fingers are always reserved for zooming, so there's no way to use that for anything else.

Rim

[mtingle]

robdean, I've tried a similar approach before, but ran into issues when the user decided to drag the region quite a distance (while staying on the same track), then decide to move to another track. It's strange to have it snap back to the starting point in this case. Maybe I could revisit that method, and put a timer in place, or a window or movement, so if you exceed the window, it cancels the saved initial position.

mtingle, two fingers are always reserved for zooming, so there's no way to use that for anything else.

Rim

how about 3 fingers?

or perhaps the other way round, once a region has turned red (therefore ruling out that you want to zoom) adding a 2nd finger indicates you want to move the region smoothly with no initial snap.

There has to be a way for this to be implemented in a way thats easy and works for everyone.

[Rim]

Adding a second or third finger after it turns red feels like a kludge. It should be more intuitive than that. I'll work on this some more and see if I can come up with a solution that makes sense.

Rim

[mtingle]

Adding a second or third finger after it turns red feels like a kludge. It should be more intuitive than that. I'll work on this some more and see if I can come up with a solution that makes sense.

Rim

In logic pro 8/9 to move a region vertically while maintaining it's horizontal position they use a modifier key (shift) and then move the region with the mouse.

So using a modifier to preserve a regions vertical movement has a precedent so I think using 3 fingers to hold horizontal movement wouldn't be a kludge but quite intuitive for a lot of users. Not sure what protool and cubase use for this function.