great! I wanted to do something like this but couldn’t find the time to figure it out. thanks for doing this.

would probably have to be added at a lower level (in softcut module)

noting that it might be hard to discern in softcut with the crossfading

also @Justmat a suggestion if i may: might be good to export with post-roll, accomodating the fade-out time introduced by softcut’s looping algorithm. (write the interval [loop_start, loop_end + fade_time] and maybe an extra couple ms)


Thanks for the suggestion! Advice is always welcome :slight_smile:

Just pushed this change, as well as a small bug fix.


This is awesome. I’m new to Norns, but was already gearing myself up to do a bunch of recording and sampling in Ableton to then put onto Norns…until now!

1 Like

Im not sure if it was a bug but last night when using this to attempt to record some samples I was having an issue with the script not allowing me to record over 2 seconds. It would keep looping the 2 seconds

This is definitely a bug, when did you install? It should be fixed in the current version.

edit: looks like I neglected to update the thread when I fixed the bug. apologies!

edit the second: @Prnts, please let me know if the problem persists :slight_smile:

1 Like

Huh, had a couple long sample dump sessions this week, just went back through to rename things and SAM left long silent tails (like an extra 2 seconds) on many and also saved entire clips that I was chopping from instead of the trimmed bits. It didn’t happen on everything, but on quite a bit for sure. Since I’m just now noticing, I don’t have a great idea of what was happening in the box when these issues happened.

I did have to hard reset twice after chopping up longer bits, both Norns and maiden became unresponsive when I tried to load new tape files into the buffer to cut up. I’ll keep an eye out next session and try to grab maiden readouts if it happens again.

EDIT: My mistake, with the un-trimmed files, I was too tired and forgot that I switched back to sam to pull some unfiltered sounds from my modular. So the second issue was user error. The long tails are still not something I’ve figured out.

sorry for the trouble! I’ll give sam a look over. if you could grab some output from maiden next time, it would be super helpful! :slight_smile:

phyllis doesn’t record :slight_smile: unless you use TAPE

1 Like

i’d highly recommend running latest update if you haven’t yet, for any script that uses the softcut buffer-write features.

@zebra thank you for the reminder.

I am on a fates (pi3b+) running 200106

Sam is up to date according to the file manager

I’ve been chopping loaded tape files for a bit and Sam is starting to act up again. It was working just fine for a handful of samples but is now spitting out files with long silent tails. I was not monitoring in maiden, and now that I am I can’t get the error to repeat. I was thinking that it was an issue with very short sample lengths being saved, but it does just fine as long as the short sample is the first thing saved from a loaded tape.

Where I am running in to issues is trying to load a tape and then cut several short samples out of it. The first short sample will save properly. However, when I move the start and end point of a loop to later in the loaded file and attempt to make a short sample to export (0.50 seconds for example), Sam will save a longer file (2+ seconds in this case)

Maiden is not returning much, I don’t know if it is because I am connected via Cyberduck as well?

Here is what is coming back





script load: /home/we/dust/code/sam/sam.lua


script clear

pset >> write: /home/we/dust/data/system.pset

script run

Engine.register_commands; count: 0

___ engine commands ___

___ polls ___









script init

reading PMAP /home/we/dust/data/sam/sam.pmap

metro_stop(): pthread_cancel() failed; error: specified thread does not exist

metro_stop(): pthread_cancel() failed; error: specified thread does not exist

Thank you again for any help. Appears that this is only happening if the second (third, fourth …) sample I am trying to save is shorter than the first. I can seem to get around it by re-loading the longer tape file to save the second(+) sample.

Yeah, that read out doesn’t say much/anything of note :confused: This is probably a script problem, and I will have some proper time for it tomorrow.

edit: Ah! pretty sure I know what’s going on. I’ll try to get a fix out tomorrow, sorry for the troubles!

Thank you very much Mat! No real troubles at all, grateful for all your work on your scripts. Quite an inspiring suite of programs.

1 Like

Looking at this now. I see a few areas for improvement and will have an update ready this weekend. I may PM you for additional info, if that’s cool :slight_smile:

1 Like

oh ok, that will do it (re: changes in disk write implementation)

@Justmat i think you were following the PRs on the disk worker threads, but it was a pretty complex change so i’d certainly any feedback or reports of weirdness

reason i ask here is, Sam is just the kind of thing that would be affected / can push the envelope of the write-to-disk feature.

before changes, disk-write was executed immediately and would stall event handling in crone. it would also take super long to write (minutes, for the whole buffer) so the hang could be long and look like a crash.

after changes, you should be able to queue up a practically unbounded number of disk-write “jobs” that execute in the background, much more quickly. (~few seconds for whole buffer)

if we need to, we can pretty easily add a completion callback mechanism.


I pushed a small update. It removes a couple unneeded lines, and adds auto loop resizing when loading samples.


@Justmat, I’m getting an update fail attempting to update from the maiden file manager:

‘Updating project “sam” failed
update failed: worktree contains unstaged changes’

Should I attempt a de/re-install?

Same here.
But when I tried again, I had “already up to date”…
Edit: @Justmat, great tool!

1 Like

Should be ok to delete/re-install. I’ve gotten this before with maiden updates, but like @nitefish, the next attempt says it’s up to date :sweat_smile: not sure what’s going on there.

1 Like

Got the newest version and seem to be having an issue where the sample isn’t looping worked fine in the old version and latest firmware with fates. Also possible UI suggestion move the record to ALT + K2 it’s too easy to acidentaly clear your recording while messing around with the loop parameters.

1 Like