autoclip

[felixroos]

this would prevent a good chunk of crashes / glitches

[yaxu]

Do the piano samples need to be that long? It might just be enough to trim all the 'default' samples..

[felixroos]

Do the piano samples need to be that long? It might just be enough to trim all the 'default' samples..

they could be trimmed i guess.. generally, most sample banks have very long tails, so this will be a problem for other samples too.
not clipping long samples makes it also very easy to stack many instances by accident, e.g. s("sax") . when the sample is very long, it can take a lot of time until the "stack of doom" has finished playing. imo having clip in by default for non percussive samples (>1s) would be a more sensible default.

[felixroos]

example usage:

autoclip(0) // automatically clips all samples to hap length
autoclip(1) // automatically clips all samples >=1 s to hap length
autoclip(Infinity) // samples are never clipped automatically

$: s("sax") 

[yaxu]

Looking at the piano samples some are over 24 seconds. That seems really long to me but I have not spent much time with pro sample packs..
I think it could be confusing to have samples clipped automatically by default, e.g. when working with drum loops or stems.
Could the default clip info go into the sample pack metadata?

[felixroos]

Looking at the piano samples some are over 24 seconds. That seems really long to me but I have not spent much time with pro sample packs.. I think it could be confusing to have samples clipped automatically by default, e.g. when working with drum loops or stems. Could the default clip info go into the sample pack metadata?

drum loops would work, as they are looped, and the hap length is equal to the sample length, or what do you have in mind?
the main goal of this behaviour would be to avoid performance issues, where people use any long sample and they stack up without having a lot of sonic use. so if you have a 24s piano sample, then s("piano") would fire each 2s at 0.5cps, so in 24s, you'd get 12 samples running in parallel.. i think this is one of the main causes of audio glitches in strudel rn.
or worse, if you do note("c a f e") you'd get x4, so there will be 48 buffer source nodes running in parallel (including all fx x48)

[felixroos]

what i mean with "sonic use", i mean the difference between:

note("c a f e").s("piano")
// and
note("c a f e").s("piano").clip(1).rel(4)

is marginal.. in the first case, you'd get 24s samples, in the second you'd get 5s samples. the idea is that if you want to have cpu costly behavior, you have to opt in instead of opt out, because people will either don't know about it or forget it

[felixroos]

one drawback is that things will sound a bit worse with the default settings, as you won't get the floatyness of layered samples by default. but that is already the case with synths anyway..