At the risk of harming my reputation by releasing buggy stuff, I’ll share my ‘work in progress’ in implementing the ‘auto-stop recording’ feature here if you are brave enough to try .
The new feature is implemented as follows:
On a blank new ‘song’ record track 1 of any length, as before.
Then you can press button ‘H’ (originally ‘playback loop on/off’) to access the new function. Press the button to select the number of multiples of track 1’s length you want to record for the ‘follower’ loops. The track status lights will light up dark blue momentarily to show your selection. e.g. 1 light will mean when you record a follower loop it will start/stop automatically quantized to the length of track 1’s recording. 2 blue lights will mean it will start/stop automatically quantized to twice the length of track 1’s recording. 3 and 4 lights let you record loops pre-set to 3x and 4x.
If you select 5 lights with button ‘H’ then you get the original behaviour again (the default) where you have to stop the recording manually.
Note that if you selected multiples of 2, 3, or 4, the recording start-time will be a quantized multiple of 2/3/4 track 1 loop-lengths from when you started playing. i.e. It may take one or more full repeats of track 1 before it starts recording. This is to keep everything lined up.
The ‘threshold start’ works as usual if you arm a track when things are not playing, and the auto-stop feature will still work according to the setting.
Now when you start recording a loop on the follower track, it will automatically stop recording after the length of time set by button ‘h’.
Known bugs -
If you have ‘setting 5’ (i.e. unlimited length recording) it may start playing back mid-loop right after you stop recording, rather than starting from the beginning. If you stop then start playback of the song, then it should line up ok.
If you try recording on a follower track without recording something first on track 1, things will get messed up and there may be a loud sound or a glitch.
! Very Important ! Please read…
If you have been using a previous version of this “m5 hack” patch, installing this update by copying the pd folder in this project to the root of your SDCard at /pd will overwrite your existing recordings (since the m5 hack patch stores recordings at /pd/songs). Make sure to back up your recordings for installing the new version. (e.g. simply rename the existing /pd folder on the SD Card something else, e.g. /pd-previous before installing this update. )
Here is an improved version with some new functionality:
The light for Track 1 now flashes briefly each time it loops.
The Track Recording Length Select button (button H) behaves a bit differently now. When you first press it, the current selected setting will be shown by the illuminated track lights. Press it again while the lights are illuminated to cycle through settings 1-5. If you don’t press it again for about 1.5s then the selected setting will be activated.
Updated readme now describes the new functionality.
For the curious… Getting the Track 1 light to flash on loops was somewhat tricky to achieve given that “looping” (and associated timing of loops) on this patch is implemented entirely within the read buffer in my custom m5_readsf~ object, whereas on the original firmware it was accomplished by automated playback stop/start messages from/to readsf~. The “m5 hack” method enables perfect sample-accurate looping for greater synchronization and consistency, but for the LED flashes to tap into this timing, I created a new object - m5_float~ - that can output signal changes that are scheduled on the same clock.
Anyway, I’m going to keep testing and playing with this and I think likely unless any major issues are identified I’ll post future revisions to Patchstorage, once I clean up the code.
If you have been using a previous version of this “m5 hack” patch, installing this update by copying the pd folder in this project to the root of your SDCard at /pd will overwrite your existing recordings (since the m5 hack patch stores recordings at /pd/songs). Make sure to back up your recordings for installing the new version. (e.g. simply rename the existing /pdfolder on the SD Card something else, e.g. /pd-previous before installing this update. )
That looks cool, I look forward to trying it out. Interesting about the custom readsf~ object, the regular one was always a bit limiting in terms of building these kinds of things. Nice work!
Hey @oweno thank you for the encouragement! I’ve been having a lot of fun playing with these changes, building weirdo songs over drum loops, and other abstract things. I’ve started to imagine getting a 2nd 5 Moons to hook up in a DJ configuration with a xfader
I published the code for the custom readsf~ and writesf~ objects, and friends, separately here:
You can read all about their functionality. I’m sure they could be useful for other patches and things on other devices too.
thanks for advice, and sorry for long time to reply. i keep trying again instead of admitting i still cant even.
unfortunately bounce seems to behave same way as record - stops any writes immediately and sets a start time for sync start. which makes perfect sense there.
and while it feels like im so dang close, and even think i know what the problem is, i dont really know, and amn’t capable to debug.
i tried, im stuck. usually id be OK with consolation prize - i learned a lot!
but in this case, im jonesing for the result enough to see if i can throw money at it
303 USD to whoever does the needful. whether you like it or not
i havent actually tried it yet, so maybe ill get it later this afternoon, but im surprised and curious why you implemented bar length choices.
as long as “stop” means finish recording at the next multiple of first loop, it would naturally be what you expect. either fully synced, or synced with an offset.
The bar length option is there to allow longer passages to be recorded on top of the original loop. I find it fun to put a simple (perfectly timed) drum loop on track 1, then record different parts of different lengths over top of it. I’ve been thinking of adding a simple way to allow users to choose there own custom/creative loop-length options for recording, e.g. could be 0.3x, 2x, 5x, 22x instead of 1x, 2x, 3x, 4x. Maybe there could just be a simple text config file that could be edited on /sdcard.
But everything is supposed to automatically “line up” as you would expect, hopefully, yes.
OK sorry I’ve finally had a chance to test out the new version and make sure I’m not guessing or assuming based on descriptions. Thanks so much for this update, it certainly pushed it over the usability tipping point for me.
That said I have some questions and opinions hot takes (I have not looked at the Pd file yet to see how much I might be able to finagle on my own based on your change):
I’m so happy about the blinking light on T1 - would it be trivial or equally painful to have the other tracks blink on their multiple? mostly from curiosity at this point, but could see it being really nice to have if some of the “creative” ideas pan out, and maybe even potentially useful regarding the callout in README “it may be up to 3 full loops of Track 1 before recording starts, depending on the setting”
I had a little roller coaster of being sad about the “multiples” implementation, then realized maybe it was what I was thinking but even cooler than i imagined, and then tried things and “OK it’s what I thought at first (which is fine!)”.
Current impl of modes 1-4 is indeed a preselected recording length that automatically stops at one full loop. It works great, probably more useful to more people. But what I realized you might have done was just made that the quantization for the stop button - which never would have occured to me but i can’t stop thinking about now. so much potential there for relaxed timing from an extremely short initial loop…
… anyway, then i thought mode 5 might be all I was looking for, with the arbitrary manual stop at no fixed bar multiple. But sigh, it still cuts off audio at button press instead of at the loop boundary
so all that said and done, would love to get an idea about feasibility and philosophical opinions about:
could mode 5 behave like 1-4 and quantize audio stop point to the loop stop point? is there any use case for it not to?
could it make sense to get a settings file started to just choose loop closing behavior? (modes 1-4 record exactly 1 loop, auto-stop) or my dream behavior (all modes require manual stop, with increasingly relaxed timing), That feels like a Team choice - idk what team you’re going to pick, but pretty sure you’re not gonna be switching teams all the time
.