Here’s what’s printed in REPL when launching Otis:
REPL Output
# script load: /home/we/dust/code/otis/otis.lua
# cleanup
# script clear
ERROR (i2c/hp) failed to write
including /home/we/dust/code/otis/lib/tlps.lua
including /home/we/dust/code/otis/lib/hnds.lua
pset >> write: /home/we/dust/data/system.pset
# script run
loading engine: Decimator
>> reading PMAP /home/we/dust/data/otis/otis.pmap
m.read: /home/we/dust/data/otis/otis.pmap not read.
Engine.register_commands; count: 7
___ engine commands ___
crossover i
distAmount i
highbias f
hissAmount f
lowbias f
sdepth f
srate i
___ polls ___
amp_in_l
amp_in_r
amp_out_l
amp_out_r
cpu_avg
cpu_peak
pitch_in_l
pitch_in_r
# script init
ERROR (i2c/hp) failed to write
>>
So I think I just heard the effect happen in Cranes while recording something at 0.25x speed, though I haven’t been able to recreate it, whereas it persists in Otis after changing speed for the first time.
mmm, i’m hearing it now with other scripts that route softcut into itself, but it’s kinda hard to nail down – it can be triggered when rates aren’t the typical 2^x (where x is usually -3 to 2) style. so, anything like rate = 0.79 adds a bit crush effect i’ve only previously heard when the fade time and loop length were super tiny (0.001s).
weiiiird. i’ll try to hack at a clean repro script tomorrow, but if anybody has time tonight i figured the breadcrumb might be helpful.
this is anecdotally a familar sound for me coming out of softcut, pushing anachronism with weird settings sometimes gets these bits caught in buffers. it (anecdotally) sounds a bit like samples being written to every other frame rather than every frame.
i’m an antagonist though because i love the sound : )
I’ll look. These updates introduce no changes to softcut dsp; the only change to softcut client is to clamp some parameter ranges on the cpp (so you can’t e.g. blow up filters with negative RQ, etc.,even when bypassing lua API.) Wonder if debug build got added to the update or something like that.
Best debug information would be output of journalctl for the crone service. (sorry I’m on phone so can’t relate exact invocation.) this will include buffer underruns, etc
There are no inherent problems with fractional rates and have not been for a very long time.
I’m having a hard time updating Otis, if anyone could add any insight into this problem it would be greatly appreciated. I’m new around here as well. This is the error I’m getting in Maiden.
Updating project “otis” failed
update failed: open /home/we/dust/code/otis/.git/objects/pack/tmp_pack_332240568: permission denied
I’ve tried to manually delete the files as well from my computer and get a permissions error as well.
Thanks.
found the issue. the latest update erroneously clamps rec_offset to be non-negative - therefore zero in this case. (when the offset is zero, the read head and write head are inside each other’s resampling windows; badness ensues.)
@Justmat in the process i noticed that the rec_offset value in Otis is quite large. (0.06s, whereas you only need 5-6 exactly 8 samples worth.) generally there is no reason to set this parameter unless you are trying to do something confusing, and the large offset is probably creating extra clicks and pops around the loop points.
Not sure if this is a super necessary or additive comment but just want to say that the debugging and troubleshooting convos in script threads are such a cool feature of the community around norns. As someone unlikely to ever write or change a line of code I just want to say how much I value the intelligence and the dedication of the people who write, maintain and assist in making it possible to use these amazing instruments we have access to.
@zebra, thanks for checking this out! i’ll get the rec_offset amount fixed this morning. i’m not sure where 0.06 seconds came from… if 8 samples are all that’s needed, it should be something like 0.00016
edit: i just saw your recent changes to the record offset defaults. i’ll just remove the line setting the offset and rely instead on the default value.
Spent a few mins early after I did an update. All gooood!!! (Im assuming there was an update lol)
Quick question; In the param setting the “skip ???”… When I select that I don’t seem to be getting any noticeable effect. Also when “???” Is selected and I go to press skip I don’t see the icon that normally appears. What’s the intended behavior there?
intended behavior is the playhead jumping to a random position in the buffer/tape. it’s been awhile since i played around with it, so something definitely could have broke.
i did update otis and the classic offshoot, but i don’t think those changes will really be relevant until @zebra’s resent softcut fixes have been “released”.
Hi @Justmat I was wondering if you would consider adding clocking to Otis? I know it’s not necessarily in the spirit of coco but I can imagine this being really useful. I’m thinking midi clock in/out and link options as per Norns clock and adding clock divisions as an option for LFO frequency settings.
If this would be trivial I’m happy to do this if you could provide some brief guidance.
Btw Otis was my first love Norns script and I keep returning to it and loving it more and more. Thanks
a norns (shield) owner once again, and loving otis
can’t seem to figure out how to get a mono input to be center panned, atm it’s left panned. on the parameters page for input it seems my only options are stereo and mono(L)
Edit: found the problem: end of the loop is named tape_len although the softcut command is loop_end.
I’m new to the whole github thing, so I first need to figure out how to do a PR. But this can be easily fixed by everyone, by just changing the code in line 125
@Justmat
speaking of skip I’d love to see a mode where when skip is pressed it sets a point to jump back to the next time skip is pressed a little more like the coco. As far as I understand right now it either jumps back to the beginning of the loop or to a random place.
since buying a shield I’ve still only explored otis, reels and oooooo. I had a coco V2 that I really only patched one thing with and just left it. I just sold my coco because I love this version.
Like I said I really only kept one patch going on the coco most of the time a simple grey delay out from the opposite delay going into the speed input of the other delay.
So delay out R in speed input L and delay out L in speed input R.
Dialing this in subtly allows for some beautiful tape like warblyness
I not sure if this system would allow for audio to directly effect the speed of the delay.
However even an amplitude follower/pitch follower on the an input that could be patched in via the same method the LFOs are would be amazing. The pitch detection would bring some possibilities that even the coco lacks however an envelope follower would be more in line with the coco V2 V2.
just a couple ideas
again I think the fact that I sold my coco says everything about how I feel about this work.
Thank you!
