i’ll give otis a run tonight and see what shakes out!

its pretty much to be expected that clearing a buffer while recording to the buffer will produce discontinuities in the buffered signal. (translation: clear when not recording to avoid clicks.)

softcut buffers should be cleared between script loads, but i’ll check it. maybe we stopped doing that for some reason (would have been long ago,) but also there could be a race condition or delayy especially if previous script is really heavy. (buffer operations are asynchronous with the audio thread.)

these are softcut issues, not otis issues, and none of that behavior has changed at all recently.


maybe i should change the buffer clearing behavior in otis? something like “set recording level to zero, then clear, then reset the record level”?


I reinstalled otis 1.3, and it was even more noisy and glitchy. So, at least on my system something happened when I went from norns 2.2 to 2.7 today. I’ll go back to 2.2, see what happens.

Did you get a chance by the way? Would love an A/B between the two, a blind test to see whether we prefer Otis or the Coco :slight_smile:

that would be a way to avoid clicks i suppose. or you can (i would) leave it to the user.

the issue i’d have with what you propose is that it attempts to account for delay produced by an indeterminately long “backend” process (waiting for buf worker thread to finish clearing the buffer) by introducing a fixed delay into your UX. in my experience that’s a bad pattern for a couple reasons. first is that “backend” behavior may change, you have no control over it. second is that delays in UX are just annoying. but yeah, it can work here (remember to factor in recpre_slew time, and - obvs - only engage that behavior if you’re actually currently recording that voice.)

we can provide more tools to deterministically manage UX and backend state synchronization. in this case we could add a callback for buf worker job completion. (i proposed this a while ago but it didn’t seem like anyone wanted it so i didn’t bother, but it’s straightforward. i’m actively working on v3 right now and it will provide much more direct interface between lua and softcut state, so will be sure to kkeep this case in mind.)

you flashed the new image and are getting audio glitches? this is an issue to share on the image release thread. it is a big change and a huge amount of kernel update work. instead of 1 image, we now have 5 images (factory, plus 4 flavors of shield/rpi version combo.)

since our test surface has increased 5x its very helpful to get feedback. be sure to say what hardware you are using (and ensure you flashed the right image to it). of course any and all REPL/systemd output is helpful.

and finally note that the new version includes an audio load and xrun indicator on the home screen. that is very useful to know if a glitch you’re experiencing is due to CPU load or something else.


Here you go:

First 30ish seconds are Otis. The next are Coco. Both with the same sample playing from the OP1. In both cases I pitched the right side down an octave. I noticed back in Aug '21 you did some A/Bing. Those settings you posted were a little more aggressive in the bit reduction and sample rate than I used. Nevertheless, I hope that helps.


Thank you so much for that. Yeah they’re quite different obviously, I always have the issue with Otis that when I add the noise, it immediatelly becomes too loud with no way to adjust it well. And that digital harshness…hmmm I might look into Coco anyways

well… one of these things is software that is easy to modify

for example one might replace this line

[ otis/Engine_Decimator.sc at master · justmat/otis · GitHub ]

saturator.set(\hissAmount, msg[1]);

with these lines

var amp = msg[1]*0.1;
if(amp>0.001, {amp = amp.linexp(0.001, 1, 0.001, 0.25)});
saturator.set(\hissAmount, amp);

for something more like an audio taper with a (to me) more reasonable maximum.

you may also like to experiment with other flavors of noise…

(i am not “taking sides” of course)

playing with otis, one thing that happens is that the immediate switch to the engine->softcut routing can cause decaying sounds from previous supercollider processes to be recorded. (glitchily, because then the engine gets swapped.) i dont mind it.


i like this, thanks for sharing! tbh, i never really think about “usability” in regard to param ranges/response curves. many, if not all of my scripts could likely benefit from some parameter tuning. :cowboy_hat_face:


Welp, placed an order for Cocoquantus 2, so will have both :slight_smile:


the plan is to finish the documentation tomorrow, and then release the update. :cowboy_hat_face:

otis v2.1


  • speed scales - easily expandable! add your own! (PRs welcome :slight_smile: )
  • grid playing of said speed scales
  • audio routing options (thanks to @jaseknighter and his wonderful splnkr script :smiley: )

hype videos/stuff and things

speed scale stuff

audio routing stuff


oh wow, super duper extra amazing videos! i can’t wait to dig into the new features! :hearts:


Excellent @Justmat ! I always come back to Otis. This is just in time for my planned weekend session


v2.1 docs are up at norns.community!

and the code is on github. update away :smiley:


FIRST hahah. THANK YOU for making my fav script ever even better.

1 Like

oh yeah, nice one :balloon::balloon::balloon:thanks mat!

1 Like

Ohh speed is not controllable over MIDI notes yet :frowning: But man what an upgrade! Just in time for me to finish the last two tracks for my first solo ambient album!


i’ll look into speed via midi :cowboy_hat_face:

with the audio routing stuff sorted, it’s much easier to get into that coco-crunch territory!


Yeah, I just compared to some coco recordings I made not too long ago…crazy :slight_smile: Also, is it just me or have you adjusted how the LFO’s behave? They seem less erratic and more natural and…useful?

1 Like