thanks for the report. if Tape is dropping audio frames, i doubt it has anything to do with the script. it would be bound by disk I/O and could (maybe) be addressed with double buffering.
Tape has a dedicated disk output thread. it is called on each audio block, and attempts to write all the frames in the audio buffer, before the next audio block arrives. adding an additional (larger) RAM buffer in between the audio process and the disk IO, could help by amortizing any disk output bottlenecks. but it could be fruitless if it this is simply about characteristics of the eemc.
if you want to open a github issue that would help me remember to revisit this when i rewrite Tape (which will be “pretty soon.”) any reproduceable details would help. (like, i wonder if some other system component is acccessing the disk when the dropouts occur.) if i were to try and reproduce this i would do so with sinewaves (making dropouts very obvious), split to a separate recording device… (to ensure that dropouts are not actually in the audio path before hitting the Tape.)
that is suggestive… is there some process writing to disk every 30s?
norns is just a linux computer. so, yes. but also, no, the norns software stack isn’t set up to understand multichannel hardware. you could use completely different software i guess.
IOW, i don’t think it makes a lot of sense to maintain the norns DSP layer to support arbitrary I/O channel counts, but you could ditch it all and just use it as a supercollider machine with a cute little video framebuffer. (i just use beefier machines for multichannel work, myself.)
i have a simple feature suggestion: a “save to disk” function that stops all record heads and writes each relevant regions of the softcut buffers. softcut API supports this, and it has a fresh new implementation which is real shiny and good, and i think it would be an easy win.
along those lines:
so that technique is working ok? i haven’t checked the cheatcodes codes. do you have to do weird tricks with metros or something?
assuming there could be issue with processing slew commands out of order, or dropping them or something, i did have an offer ready: i could easily implement a dedicated softcut command for, i dunno, play_env and rec_env, which just combines a slew and a level value and ensures they are executed in the correct sequence and in a timely manner with respect to each other. (really, very simple to do.)
not possible with norns hardware, the headphone output is just a gain stage.