[MSP Extern:] rez~ - a sample-accurate looper - (update for apple sili)

Hiello!

This is a sample-accurate looper i'm feeling a nice ease-and-flow in coding and using, that stems from a good amount of simplicity/minimalism in the design. So I think this might be good to eventually release to the wild as officially and functionally as possible(eventually submitted as a 'package' to the max ecosystem with nice helpfile/refpage/docs etc.). So I could use some beta-testing! And also help on bettering the helpfile/docs :)

Attached are the externals for Mac(.mxo), Win(.mxe64), along with helpfile. Source-code available here.

And here's a bit of a description to start with: 1) For playback, the signal-inlet controls are 'starting-phase', and 'speed': 'speed' of '0' turns the object off, any other speed turns it on(w/ de-click fade-ins/outs) 'starting-phase' is the position at which playback starts, and can be changed on the fly while playing with crossfade-declicking(not while in 'oneshot' mode, though)

2) For recording, the signal-inlets are for 'starting-phase', 'speed'(-1., 0., or 1.; reverse/stop/forward only), overdub, and recording-inputs for left and right

3) For outlets: there are playback outputs(left and right), a playback-phase outlet, and a recording-phase outlet

4) The only messages are "in", "aus"(for playback-loop 'in' and 'out' points), "rin"/"raus"(for recording-loop 'in' and 'out' points), and "set"(to change buffer~s referred to)

5) Just two attributes: "fade" is an attribute you can set for all fade-times (in samples; interesting effects can be achieved by changing this in real-time) "oneshot" is an attribute you can set (as a flag - 0/1) to put the object in one-shot mode where, only a speed-change from 0 to non-zero will set the object playing starting from the 'starting-phase' inlet's control, and ending at the furthest loop-boundary (if playing forward, it will play til the end(aus/raus) point, if playing backward, will play 'til the start(in/rin))

5) while playing, de-clicking is handled by crossfades (sine-based crossfade: fades out of the previous-position, in-tandem with a fade-in to the current/changed-position) for playback and recording (in recording, the crossfade accounts for overdub amount)

6) 'initialization-modes' allow you to setup the object more efficiently: the object takes 3 arguments -> buffer~ name(mandatory), channel-number(optional... although mandatory if you want to enter up to three arguments), and initialization-mode(optional) the initialization-modes allow you to access "play"-only functions, "rec"ording-only functions, or all functions at once, just give a 3rd argument of either nothing(for all functions available), "play", or "rec". accordingly, the object will initialize to cut-out any unnecessary inlets/outlets, and internal variables/functions, etc. to give you the most efficient possible object for whatever usage you choose (for example, creating an object like so: [rez~ bufname 1 play], gives you a 1-channel playback-only object, where only two signal-inlets are provided(the two for playback-control only), and 1 signal-outlet for single-channel output, plus 1 signal-outlet for playback-phase.. ..or creating an object like so: [rez~ bufname 1 rec], gives you a 1-channel recording-only object, where 4 signal-inlets are given(starting-phase, rec-speed(-1/0/1), overdub, rec-inputLeft), and 1 signal-outlet for recording-phase signal.. ..whereas, creating an object like so: [rez~ bufname], gives you all signal-inlets/signal-outlets/functions(and 2-channel by default)) Known issues: so far, i do run into clicks/pops here and there(mainly when using the object(in the default initialization with recording/playback all-in-one) to cause the playback and record heads to cross each other, but with very small loop-sizes or performing very fast cuts yet very close to each other continually... the first tab in the helpfile runs into this issue). also, i've not de-clicked transition from 'oneshot' mode to regular, so for now, that attribute is better changed whenever the object is not running. and also, in 'oneshot', sometimes the recording performs something inaccurate about the fade-outs near buffer~ boundaries. Basically, i need to look more closely at 'oneshot' in general, plus default initialization, and some recording-fade/declick details but no crashes so far! :D The de-clicking for recording-over-play crossover is probably as good as i can get it for now(i tried other sharper fade-curves and they don't necessarily work better at higher speeds, i've found this simple-cosine-based fader is the best trade-off for more widespread contexts). But feel free to report any bugs/issues you find, do try to focus more on those which you can reproduce to some extent: even 2-out-of-every-7 tries is a good reproducible frequency(if you get something even closely reproducible, list me the steps to repro and i'll do my best to fix).