Sorry to have to make a new thread for the same issue, but it seems the only way to be able to attach another video in this forum.
i tried to make some sense with the automatable LV2 but i find it impossible to predict where the Start and End Loop locaters will end up :(
And i can't tell when the CC value is higher than 127 or lower than 0, there's no feedback. I think sometimes the locaters do not catch-up and stay glued where they are. They don't react anymore.
Have a look at the attached video:
- on the left in the Carla LV2 CC window you see the GEN1 Loop Start and GEN1 Loop End moving when the 2 notes are played. The start of the notes can be seen below in red (= 2 notes)
- in the CC lanes you see: 14 Start Loop and 15 End Loop (corresponding to the movements in the Carla automation window - this works)
- CC 14 and CC 15 are put before the note starts and do not change during the note
- audio responds well to the changed Loop settings
- the End Loop locater remains stuck
Perhaps you can think of a way to protect the locaters from hanging if they get a "weird" CC value? I need a better visual feedback of how the locaters correspond to my CC settings...
Attachment | Size |
---|---|
Automation7-2018-09-14_14.30.27.mp4_.zip | 597.41 KB |
re. no End II
sorry, can you retry with latest (todays) git head? (samplv1 0.9.2.32+)
now all offset and loop start/end points are relative to the whole sample length and not to each other anymore.
bad news are you loose resolution (MIDI 7bit, 0-127 range is way too coarse for longer samples but you know that already); good news are that now offset and loop positions remain in sync, as much of the time as possible--however, the so called catch-up standing still applies whenever the absolute positions (in frames) are changed eg. on the main GUI.
cheers
Tried it, works until it
Tried it, works until it sticks again and does not move afterwards and i don't know why or how to prevent it from sticking...
i just think - and of course, you can disagree - that the start locater and whatever locater should be represented by 128 slice points over the total sample. This is the only way to get a clear picture and in one glance looking at the 4 automation CCs in the sequencer what locater will be where for the next note. This is the place where you can see their relative position.
Locaters should be independent of each other
UNLESS
- start offset accidentally is moved by a value bigger than one of the other locaters; in that case, start offset=start loop if present
- end offset accidentally is moved by a smaller value smaller than one of the other locaters; in that case, end offset=end loop if present
- start loop must be bigger/equal to start offset but smaller/equal than end loop
- end loop must be smaller /equal to end offset but bigger/equal than start loop
- start loop must be smaller than end loop
haha, getting crazy here....but i hate it when locaters get stuck and lead their own life :)
The low resolution of 128 locater points in the total sample sucks, i know, and i am not too familiar with sending MSB/LSB pairs (that would allow for much greater values) i'm afraid.
re. Tried it, works until it
maybe it sticks because:
a. it goes beyond its limit eg. loop-start over loop-end;
b. the corresponding parameter absolute value is changed on the GUI;
on both cases you'll have to backtrack until the controller value catches-up the stuck value again.
and yes, since v0.9.2.32git..., all offset and loop points are relative to whole sample length, so that 0% means the beginning (first frame) and 100% the end (last frame); obviously 50% means the middle position; also, loop points do not go either before the offset-start nor after the offset-end points; offset- and loop-start cannot go greater than either offset and loop-end, respectively.
one last hint re. MIDI controllers, is that the term CC means continuous-controllers, so that abrupt or sudden jumps in value might still cause an out-of-the-hook situation and the sync moment gets lost--probably in need to go smoothly in to catch-up and hook on previously (stuck) value back again.
seeya
[UPDATE] ps. v0.9.2.33git head might improve on the "sticky" issue but remember that the general considerations above do still apply, nevertheless.
this is getting much better.
this is getting much better.
After tweaking for quite some time i finally managed to get some strange result - but i do think this is an improvement, the best one yet.
Because i cannot attach a video here, i have yet to make another thread No EndIII. And because the attached file can not be greater than 1 M, i had to act quickly while making it.
Please have a look at that posting.
Add new comment