feature request: variable loop size.

[magnetophon]

The first loop should define the loop size, the loops that come after that should be variable in size: an integer multiple of loop 1.
For that, there need to be 2 rec modes:

• record multiple loops automatically (like we have now)
• record a loop and stop when the button is pushed again.

[bill-auger]

but when the button is pushed again it dis-arms the track

in order to make this work on-the-fly it would require either a third toggle state besides the red and yellow behavior or else a dedicated trigger button

it may be better to have this be a command-line switch or a selectable setting in a preferences panel - it is probably not likely anyone would want to switch between these behaviors on-the-fly

[magnetophon]

I most definitely would want to switch them on the fly, cause both are super useful.

[bill-auger]

by on-the-fly i really mean strictly hands-free - if you have even one hand free you could toggle the switch with mouse or some PC key without much hassle - yes?

i just want to avoid adding too many primary triggers and overloading the existing primary triggers

the number of primary triggers equates to the number of MIDI pedals required to use it hands-free - im hoping to keep this number at 2 or 3 at the most

the number of functions that each primary trigger performs equates to the complexity of the learning curve and general usage - in other words each button should do only one thing ideally and the main (spacebar) trigger is already overloaded now

[magnetophon]

If you make it controllable by a key/midi, that doesn't mean that you have to have that many midi pedals to use it hands free.
It just means that you can only use one mode while hands free if you have fewer pedals, and you can switch on the fly if you have enough pedals.
Or did I miss something?

[bill-auger]

but how could you change modes while both hands are busy? - you would need another pedal to do that

this really seems like it wants to be a very clearly separate mode tho - it sounds like it would necessarily replace an existing feature - either automatic recording would not be possible or the ability to stop recording would not be possible - maybe some user-stories would flesh this out

i have an issue already for a config panel that will probably be an epic #13 - all items in there would probably have keyboard shortcuts - or else maybe it is more of a HUD display item

[magnetophon]

Well, If you make mode-switching mouse or key controlled, you can't do it with both hands busy either, no matter how many pedals you have.
So as far as I can see you have 2 options:

• make it midi/key controllable, that way people with enough pedals can do it on the fly.
• make it a menu item or a startup flag: nobody can do it on the fly.

[bill-auger]

ideally i would like the control triggers for all feature to be user-definable - any feature could be set to any MIDI event mouse button or PC key - the primary triggers are special tho in that they intentionally have overloaded functions - those could be re-defined but i want to keep their functions as sets - i.e. you can set 'Trigger1' to any key or pedal but 'Trigger1' (whatever that is) always does the same things

so the actual button is not my concern - i just dont want to overload concerns or remove features - this feature seems like it necessarily replaces some existing feature and overloads one of the primary triggers - if that is true then i would rather give this feature it's own dedicated trigger in which case it could as well be always enabled

[magnetophon]

Agreed. Thanks.

A related issue:

When you implement this, please make it so that a start or stop 'click' within the first half of the sync-loop is interpreted as a start or stop in the past, so as if the user clicked exactly at the start of the current sync-loop.
Similarly a click in the second half of the sync-loop should be interpreted as a click at the end of the currently playing loop.

So IOW: always round the time of the click up or down to the nearest start of the sync loop.

If my testing is correct, you currently always start recording at the nearest start before the click.
This seems counter intuitive to me: if I hit start a millisecond before count 1, it actually starts at the previous count 1.

Does that make sense?

[bill-auger]

you are misunderstanding the controls - pressing the trigger does not start or stop recording - loopidity is ALWAYS recording - the trigger only decides if the current buffer will be saved or discarded when the end of the loop is reached - it is a bit non-intuitive at first as i do not know of any other looper that works this way but it is extremely convenient for hands-free use once you get used to it

i.e. except for the first loop - you can press the trigger as many times as you like before the end of the loop and it does nothing special - ONLY at the end of the loop is it important which color the frame is

i.e. the frame could be yellow for the entire loop and turned red only at the very last moment and the entire segment will be saved and the frame will advance to the next loop slot

i.e. the frame could be red for the entire loop and turned yellow only at the very last moment and the entire segment will be discarded and the frame will remain in its slot - the resulting state is equivalent to the frame being red at the loop end and then pressing the UNDO trigger (except that you would hear the first instants of the new loop playback before it was deleted)