This is a hacked re-build of the PD patch that comes with the 5 Moons. My aspiration for this patch is to get more reliable looping and recording out of the 5 Moons, without diverging too much from the original way it works. It still records and reads to/from the sdcard, but it plays back with continuous looping and quantization, to make all the tracks line up more predictably, with some other nice features.
(still a work in progress)
Thank you for all the effort you’re putting in. I’ll try it out when I get chance. The quantization of all the tracks is definitely a game changer with 5moons.
Thanks! Please share back here when you have a chance to try it - I’m eager to know if it works as expected for people other than myself. 
I’ve had about 40 minutes playtime, and it’s definitely useable and the more time I have I’ll hopefully master it. Just one question for now 
Is it just mono or stereo?
Absolutely fantastic work you’ve put into this. Thank you!!
Excellent question haha I should have clarified that in my documentation. Yes it is stereo - it records stereo 16-bit 48kHz .wav files, and plays back in stereo. For example, if you want to import a ‘perfect’ loop into the 5 Moons as a track 1 to quantize against, it should be 16-bit, 48kHz, stereo.
*However there is something weird in the recording and can’t quite pin down where the stereo image shifts a bit. On the monitoring side it sounds as expected. I’m not sure if it’s my imagination or not. I think I’ve ruled out connection issues in the Pd patch.
Yeah theirs definitely some difference between the monitor and recording sound, that’s why I asked about if it was stereo but that’s not a issue with myself.
I had a good connection with a iPad not so good with the 201 pocket piano but I need explore a bit more my side. So I would say theirs no connection issue.
I probably miss the Input VU Meter, I can never judge the noise level.
I’ll hopefully get more time to explore the patch more over the weekend. You’ve left excellent instructions on how to use. I haven’t really used the 5moons in the last 6 month so it might take longer than the weekend to get my head around. 
You might find this hilarious, but I went to add the VU meter function back in tonight, and I discovered it was already there. So somehow when I was writing the documentation I forgot that VU was already functional. It should work the same as before, with the same button, so please try it & let me know if it works for you. I’ll update the readme next time I make further changes to the patch.
I think the next thing I would like to add is some experimental built-in compression, and more finesse for the “audio level” starting trigger.
Just need a click track. I have got a fender and boss headphone amp to get all the fx I ever need. Thank you all involved. You have beautiful souls
Fantastic work! Thank you so much for this patch! This is exactly what I’d hoped to be able to do one day with the 5 moons.
Exactly what 5 moons needed!
I just been playing around with the m4 hack and realize that the recorded sound plays louder in the left channel than in the right one. The monitoring is dead balanced in the middle but when it is recorded it slides to the left.
Is that so for all of you?
Yeah it’s not your imagination - I noticed the left-channel bug too. Really weird. I think I found a solution now - maybe the bug is caused by some kind of Pd symbol/signal glitch. I’m going to do a bit more testing and post an update if it’s fixed.
Been playing around with this hack for a few days and loving it so far!
I was also curious about the left channel behavior, after a little poking around I was able to get it to go away by replacing the s~ mainout/mainout-r objects with the standard pd wire connection. Maybe the send~ object introduces microtiming differences that mess with the stereo phase?
Thanks - glad you are enjoying it!
That’s kind of along the line of my solution. Except I kept the main in/out sends but renamed the signals maininleft, maininright, mainoutleft, mainoutright. Removing the ‘-’ from the name maybe helped, but that’s just a guess.
I’ve posted an updated version of the m5 hack patch on PatchStorage.
v 0.2 - should fix the weird stereo balance bug, and also should fix a timing issue that can occur sometimes.
important
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 before 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. )
Is the threshold recording functionality baked into the m5_writesf~ object? I was looking around in the patch to tinker with the threshold level/disable it but couldn’t find anything
Yes it is baked into the m5_writesf~ object. The ‘threshold’ recording mode is triggered in m5_writesf~ by sending it a start message with one float parameter, e.g. start 0.1. The float parameter specifies the recording level to wait for (absolute value). When m5_writesf~ detects the threshold, it starts writing samples to the file, and also outputs the exact start time to its leftmost outlet. The patch uses the output time event to trigger playback of the other tracks while recording.
There’s more details here: GitHub - samesimilar/m5_soundfile: Sample-accurate scheduled readsf~ and writesf~ externals for PureData
This is my my favorite patch for 5 moons and I’ve been really hoping to see more updates for it. It’s so close to an ideal little looper thing for me. I’ve been trying to puzzle out how the patch works trying to see if I can’t add some of the stuff I wish for myself. While I’ve learned a lot about pd and the nice little m5_soundfile lib, I’ve yet to actually accomplish any of my goals. Frustrating cause it feels like I’m so close to getting some of it working! Figured I post about it here and maybe get @samesimilar inspired or at least get some advice.
stop instead of trying to juggle silence at the end of the loop or accidentally another mostly silent bar. My attempts to pass a frame based on start_offset and main-looplength to stop just end up with the loop never closing - I’m not clever enough yet to debug if it’s putting things in an unexpected state, or if it’s some timing thing where it’s trying to read before the write is closed , or if it’s the wrong approach entirely. Maybe I just need to subtract a frame or two from the time I’m passing to stop so it’s not stopping and reading at the exact same time?armed for stop color. This means a new track status and may be related to why I haven’t gotten things working right in the first place …
- trying to get the “blink LED when the loop cycles” behavior back. it seems like the original bits to do that are still there but the messages it’s looking for aren’t being sent. I’m guessing it’s because we use stop never and m5_read_sf doesn’t have a specific outlet that bangs when the loop comes around once it’s playing. So probably needs to be something that does some math on the current frame vs the start_offset and main-looplength but so far I’m too dumb to come up with the design or figure out where to put it if I did.Anyway sorry for long post - if you have any pointers or ideas that might help me accomplish any of this, or if you’re inspired to drop a v0.3 about it, I’d be much obliged.
Hey thank you for posting, otherwise I wouldn’t even know if anyone was using this patch! I feel your pain and I think this should be doable. I wish I had more time to to keep evolving the m5 hack patch over the past year, but my day job has taken up my coding and emotional energy a bit too much ;|
I will try to give it some more attention soon in the coming weeks. If you are working on it, take a look at the m5_ftc_cycles objects since they can determine an appropriate stop time for loops. The ‘bounce’ behaviour works kind of like how I think you want individual loops to work. I had been thinking of this kind of looping but I wanted to also figure out a simple algorithm to suppress loop-point clicks, so that’s part of the reason I haven’t made progress on it.
Bless you for trying! These ideas are so awesome, I wish C&G made different firmwares for this, I love this thing so much and it still has room for more! Love these ideas!