Clip jump behavior

serotoninsteve · Post by **serotoninsteve** » Tue Aug 10, 2004 11:37 am

Hello, I´ve noticed a strange behavior of the loop start and end points using the key commands or shortcuts for audio and happens for midi clips too!
And here we go:

I drag a whole track into session view, already warped.

Then I choose the loop bar with the mouse and hit ctrl+down arrow a few times and suddenly the end point comes out of sync like here 61.3.1 instead of 61.1.1.

Now I can jump back with ctrl+up arrow and it comes back in sync, and I go back to the loop end at 241.1.1, but when I hit the keys another time the end jumps to 243.4.2 and I cannot come back to my 241.1.1 until I zoom in and adjust the end to whole bar with the mouse.

This behavior is very anoying and makes the use of the keycommands useless when I want to set up a few short loops of my whole track while playing!

Another thing that is strange that when I´m in envelope mode and I´ve adjusted my grid to 1/1 bar and I hold ctrl+ click, the sample offset snaps to bar,
but in sample view it doesn`t snap to anything , then I´ve to zoom in and set up the offset manualy to bar wich is very anoying and not good for live performance.

Has somebody noticed the same?

Greetings!

serotoninsteve · Post by **serotoninsteve** » Thu Aug 12, 2004 1:58 pm

Hello to everybody who has long tracks for use in live to try out what I wrote in my previous post!
I think it is a very anoying bug!

Greetings!

Reiner · Post by **Reiner** » Thu Aug 12, 2004 3:57 pm

hi serotoninsteve,

it is not unlikely you found a bug, but I want to make it very clear. First of all,as you maby noticed: the Cmd+Arrow up/down halves/doubles the loop.

In the Middle:
The loop end, may be on any position. If you start with a legnth of 4.0.1 and press Cmd+Arrow Down you end up with an "odd" loop where the last "0" in 2.0.0 is read. This is not a bug. Does this explain the behaviour you found around 61.1.1.? If it is not, please give me a sequence:
- loop (start, end, length)
- key you pressed
- loop ...and so on...

At the end:
Obviously, if you double the loop, at the end, and there is not enough space for doubling, the loop is set to something odd, and you won't get rid of that any more. thats a bug. sorry for that. i will try to prepare a fix for the next update.

as long as you have to live with that bug, I just can recomend to use the up/down without Cmd, this makes the loop hop, and here it will stop, if there is not enough space at the end and you will not end with an odd loop that way.

Best regards, Reiner

serotoninsteve · Post by **serotoninsteve** » Thu Aug 12, 2004 10:29 pm

Reiner wrote:hi serotoninsteve,

it is not unlikely you found a bug, but I want to make it very clear. First of all,as you maby noticed: the Cmd+Arrow up/down halves/doubles the loop.

In the Middle:
The loop end, may be on any position. If you start with a legnth of 4.0.1 and press Cmd+Arrow Down you end up with an "odd" loop where the last "0" in 2.0.0 is read. This is not a bug. Does this explain the behaviour you found around 61.1.1.? If it is not, please give me a sequence:
- loop (start, end, length)
- key you pressed
- loop ...and so on...

At the end:
Obviously, if you double the loop, at the end, and there is not enough space for doubling, the loop is set to something odd, and you won't get rid of that any more. thats a bug. sorry for that. i will try to prepare a fix for the next update.

as long as you have to live with that bug, I just can recomend to use the up/down without Cmd, this makes the loop hop, and here it will stop, if there is not enough space at the end and you will not end with an odd loop that way.

Best regards, Reiner

Hello,

I start with dragging a whole track already properly warped with a startpoint 1.1.1
endpoint 241.1.1
lenght 240.0.0
offset 0.0.0
into session view
Then select the black loopbar with the mouse
Try to half the loop with ctrl+downarrow
1st : 121.1.1
2th : 61.1.1
3th : 31.1.1
4th : 16.1.1
5th : 8.3.1 must be 8.1.1
6th : 4.4.1 must be 4.1.1
7th : 2.4.3 must be 2.1.1

and I can go back properly through the same values and come back properly to my 241.1.1 and one more time it jumps to the total end of the sample at 243.4.2 and when i try to half the loop it´s out of sync.
That must be the bug you already wrote about, but the other misbehavior is anoying too!

I tried out when the sample is offline and it happens too so I´ve send you the .asd file only, the sample is to large ~70Mb
Hope you can fix this!

Greetings!

Steve

Reiner · Post by **Reiner** » Fri Aug 13, 2004 8:58 am

hi steve,

to your example. if you look at the loop lenght, you will find the answer: (I added it behind the "->" sign)

1st : 121.1.1 -> 120.0.0
2th : 61.1.1 -> 60.0.0
3th : 31.1.1 -> 30.0.0
4th : 16.1.1 -> 15.0.0 (it is not 16 bars long!)
5th : 8.3.1 -> 7.2.0 and thats correct.

thanks for your effort and the bugreport,

best regards, Reiner

serotoninsteve · Post by **serotoninsteve** » Fri Aug 13, 2004 12:02 pm

Ok, I understand now, and it´s logical too, but it´s bit uncomfortable.
Who wants that a well cut loop set to bar comes out of sync just wanting to shorten it as fast as possible!
Couldn´t you code this that even for lenghts like 15 bars or other values the end point jumps to bar, indeed this would be unlogical but more comfortable.
As ex. Half the 15 bar long loop would you give a 7 or 8 bar loop and not a 7,5 long.

Just an idea!

Greetings!

Steve