Automating Loop points is broken

[unfa]

I've tried automating loop points in Ardour - however the control port ranges seem to be close to [0..1] - so using any automation will make the loop use only 1 sample of the loaded soundfile at best.

[rncbc]

loop points are not automatable.
also, they are exposed as lv2 patch/property parameters and not as input control ports;
it's kind of weird why ardour lets you automate that anyway...
cheers

[unfa]

Oh, that's a pity. Being able to automate the loop points would allow for some very cool effects.
I'm looking for an open-source sampler that could do that.
So far only LMMS' Audio File Processor seems to do that - but that an LMMS built-in so I can't use it in Ardour.

[brylie]

Yes, it would be really cool to automate loop points. There are some prominent IDM musicians who use sample looping to great effect, such as:

https://www.youtube.com/watch?v=10Jg_25ytU0

[rncbc]

please take the 'wontfix' label as a parody. of course, in the software world everything is possible, given enough hands on a keyboard ;)

[brylie]

Haha cool ☺

Hopefully we can find a way to chop up sound loops with automation.

[unfa]

Oh, thank you, rnbc! I thought you were dead serious with it. That's a relief now :D I know many psychedelic trance producers use automated loop points on a sampler to create unique "riser" sounds from that. I also think Noisia used that with intro vocals on their track "Tentacles". It's a very useful tool to have, and I don't know of any LV2 plugin that can do it currently.

The LSP developer reached out to me recently and maybe he'll do something with that concept aswell.

[rncbc]

latest d245671introduces the possibility while very experimentally...

enjoy

[unfa]

Thank you! I'm eager to try it!

[rncbc]

@unfa : what's stopping you (to try it now) ?

[unfa]

I'm getting married in 11 days, and don't really have the time to do it. 2018-08-13 23:03 GMT+02:00 Rui Nuno Capela <notifications@github.com>:

…

@unfa <https://github.com/unfa> : what's stopping you (to try it now) ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#20 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAeAuDKroEDF3NYrKOnAgU0RvqVeRX0Dks5uQemqgaJpZM4UbVwq> .

-- - Tobiasz 'unfa' Karoń www.youtube.com/unfa000

[rncbc]

@unfa : np. best wishes and congratulations and happiness together with your spouse-to-be.

cheers

[unfa]

Thank you! 2018-08-14 19:35 GMT+02:00 Rui Nuno Capela <notifications@github.com>:

…

@unfa <https://github.com/unfa> : np. best wishes and congratulations and happiness together with your spouse-to-be. cheers — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#20 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAeAuEU3CizK4X_5ex_a9cNcDq9gwmSXks5uQwpVgaJpZM4UbVwq> .

-- - Tobiasz 'unfa' Karoń www.youtube.com/unfa000

[tjingboem]

we (Harry and Menno) are not getting married and volunteer to take over the job of testing if you don't mind.
We found the commit to be non- existing anymore - is there something to test for us? Are the loop start and end points automatable and is perhaps even midifyable?

[rncbc]

hi Menno & Harry,

yes the offset and loop controls are MIDifiable but only on the LV2 plugin form and provided the host application support automation and/or MIDI map/learn/assignment (eg. qtractor; ardour; from the generic plugin editors).

cheers

[tjingboem]

We reinstalled after removing all old remnants and with Carla found the controllers for the offset and the loop start/end.
Sunday is the day that we will test :) but it sure looks promising!

[tjingboem]

here are the results from our first test:
We assume that CC values (0-127) represent the space between Start Offset and Start Loop.
The same goes for the space between the End Loop and End Offset. So there are 2 spaces for both offsets for the CC values to cover.

Problem is that the Start Offset and End Offset pushes the Loop Locators away. After this error in calculation, the Loop values are greyed but Loop switch/indicator is still on.

[rncbc]

please explain how, what and where exactly are you doing the testing?

take note that all values are relative: offset-start/end control values are relative to the entire sample-length in frames; loop-start/end points are relative to the absolute offset-start/end range, also in frames, so that loop point controls are subordinated to offset-start/end frame points -- thus, whenever you change sample offset-start/end points in any way (on the GUI, via MIDI controller or automation), the relative controls for loop-start/end points will change accordingly.

note that all these relative offset and loop-point controls do play catch-up, that meaning that they only actually change when they match or are in-the-zone of their respective parameter values in frames.

hth.
cheers

[tjingboem]

First of all, i'd like to make sure i understand what you mean by frame: it is a collection of samples (for example 64), is it not? In fact, this is the fastest time in which the automations can update, ie. once per 64 samples (=1 frame), so in our case 48000 samples per second/ frames is the resolution for automation. Is this correct?

You can see a video where i manually move CC61 from Carla. CC61 is connected to the End Offset of Samplv1. When i move the slider too far to the left, it moves the End Loop locater. I guess this is not expected behavior. Shouldn't just the space between the End Loop and the End Offset be scaled and divided in those 0-127 steps from the CC61? It has no right to move the End Loop locater- but perhaps i am misunderstanding...
loop automation-2.ogv.zip

Menno

[rncbc]

no, a frame is one sample on a mono (single-channel) audio file; a frame is two (2) samples on a stereo file (2-channels); etc.

then you're using Carla as host which gives you the convenience of assigning a MIDI CC to a plugin input control port--this is not quite automation but it's close related to MIDI control(ler) surface mapping ;)

MIDI CC 7bit values (0-127) are here linearly mapped into the target subject range, in the case of the offset and loop-start/end input control ports that range is the normalized 0.0-1.0 or 0-100%, if you prefer.

as it should be inferred from my earlier comments, when you change any of the offset start/end points, the subordinated loop start/end points are re-adjusted accordingly: from my POV. it cannot be any other way.

seeya

[tjingboem]

thanks for the info.
I'm processing the info atm, i am not that fast :) Have to think this over...

[rncbc]

thanks Menno.

today's fix 2587c59 might get things (a lot) better now ;)

cheers

[tjingboem]

This mapping of the space between Start Offset and Start Loop for the 0-127 values has its advantages indeed. Same thing goes for the End Loop locater and End Offset.
But i'm still not sure. Now everything is relative to each other, making it more complex in how to predict where the locater will be in a certain part of the song...when the length of the loop has changed at some point, suddenly the End Offset locater will have a different "play field" then before this loop change....

Also, i'm not sure yet what to do when a loop is set in the sample; only a few CC values (5-10) will be available to move before the loop will be almost zero in length. Such a small resolution might make it impossible to do sensible or musical things.(repetitions in the right tempo with the right increasing length in the produced looped sound).

MSB and LSB to get a higher resolution will be messy also as the one must be followed by the other or else this MSB/LSB system will break.

Tomorrow is the music day of Harry and me and we will talk this over.

(Of course, this is your program and you decide, but i'm still uncertain....)

[tjingboem]

Due to illness of my partner in music, i can express my opinion only atm. as he is not present today.
But:
The initial request from Unfa is to be able to automate the loop points. And i think this does make the most important musical sense; to move the loop locaters, while playing in a loop.

The Start and End Offset do not play an important role here - they should not move while the Start Loop and End Loop locaters move. They should be more or less independent from each other UNLESS the Start Loop and End Loop locaters are getting in front of the Start Offset locater and/or behind the End Offset locater. Then these Offset locaters should be moved to meet the values of the Loop locators. Loop locater system is boss.

So: Start Offset and End Offset are more or less static and mostly be set only once (but can be set by automation independent from Loop locater values) - unless they are overridden and moved by the Loop locaters.

What must happen to the Start and End Offset after they have been moved i don't know yet, but the idea is closer to the initial and musical request: Start and End Loop locaters are priority!

(haha, perhaps i will think about this differently in an hour :-)

[rncbc]

i think you're overthinking the whole issue...

although it is now possible to automate and/or midi-control the offset start/end points (in relative terms that is) you're not obliged to use it every time -- "just because you can doesn't mean you should"--yada yada :)

cheers

[tjingboem]

i wonder how automation in other samplers is setup. But i am already quite happy with Samplv1 as it is atm.!
I will stop thinking and start using....:)