command to "stop after next loop+fade"

[catfact]

... stop for short?

[schollz]

hi @catfact was revisiting your post spurring this feature.

I think this would be a really useful feature for me, simplifying a lot of my clock watching in oooooo and other scripts - i.e. having the ability to create a single cross-faded loop through softcut. is this still a useful api addon? if so I would be interested in taking it on.

and is this thinking of it accurate (using nomenclature from this post)?

1. input is recorded by subhead 1, starting at loop position A, fading in from A to A+f (f=fadetime)
2. (if stop enabled): when subhead 1 position reaches end of loop position B, it continues recording and fades out while traveling to position B+f. at the same time, when subhead 1 hits B, subhead 2 begins playing - but not recording - at loop position A, fading in to A+f. when subhead 1 hits position B+f it also disables its recording.
3. playing continues normally in this single cross-faded loop

maybe stop_rec is more accurate name here, as I specifically would like to have the loop continually play, and only need the recording to stop after the loop+fade for subhead 1.

[catfact]

yes that seems like a fine description.

let's elaborate a little more how the usage would work. here's my proposal:

• on receiving stop_rec command, a boolean flag is set by the voice, queuing the "record once" behavior

• the next time a position change is performed by the voice (either from a position change or a loop endpoint), the newly activated subhead will have its record flag enabled before processing that audio frame. (record and preserve levels not affected, those are still arbitrary.)

• when that subhead is next deactivated (again either explicitly or by looping) the record flag will be disabled again.

?

i had already thought that this structure of queuing things to happen to a subhead at next (de)activation point, could be useful in other ways too. particularly i thought it would be good to have an alternate command for changing the phasor rate that would act this way and allow for a closer approximation of granular synthesis.

[tehn]

i'm very much into this idea! i've implemented similar functionality from the lua side but an api implementation would be welcome and very interesting.