Two Strange & Inexplicable Bugs
Hi, so I have created a sampler module that uses groove~’s loop function for sample accurate retriggering. However, there are two exceedingly strange problems that I can’t seem to figure out. The first seems more straight forward than the second, so I’ll start with that:
1. In the patch I have provided, there is a high pitched buzzing that occurs between drum hits. After debugging I have found that this occurs from playing the sample with groove~ in reverse. It seems to be the value of the first sample in the .wav file used. For some strange reason, the way reverse is implemented in my patch seems to cause groove~ to stay stuck on this sample. This doesn’t happen when one normally plays a wav file in reverse with groove~ and I have no idea why it would happen in my use of groove~.
2. When adjusting the slider values of the various modules within this patch, something exceedingly bizarre sometimes occurs: the metros driving the sequencer modules stop sending out bangs. It’s as simple as that: the metros all simultaneously stop banging and I have no idea why. It doesn’t happen consistently, I haven’t found a way to guarantee that the metros will stop banging, but i promise you this has happened numerous times, much to my frustration. I will try to record this happening on video and post it later. It has happened to me with just this patch opened, so please tell me if this happens to you as well.
I am on a Macbook Pro, Intel processor, if that is useful information.
Thanks for any help. I really do hope this can be solved as I was very happy with my idea for this patch and would love to have it working properly and consistently.
Attached below is the module. Unzip the file – the main patch is called "GrooveRolls".
Much thanks. Your help is very much appreciated.
i just tried this: try turning reverse on for every step – it really illustrates my reverse problem.
figured out my reverse problem: i didn’t connect the incoming playback speed to my [< ~] object in my drumGroove module. Still don’t know what causes the metros to stop banging tho.
i spoke too soon – i still get the same problem with reverse. it seems groove~ gets stuck on the first sample value and thus keeps on outputting a high pitched buzzing.
lol, i’m pretty much having a conversation with myself here, but i fixed the bug by adding a [!=~] to groove’s sync phasor and connecting that to a [*~], with the other input being the groove’s output.
----------begin_max5_patcher---------- 1449.3ocyZsrjiZCEcs6uBBIqR7zgqj3gSkrH6yhTUVN0TSgskcSBF4Bjmzc lZ5u8HjvX5wPiPVno2Xa.Y3bO5beHc4y2sveM6QZku2u38duEK97cKVHOU8I Vzb7B+CoOtIOsRNL+B5+xV+29KUWhSejKO828aO6Eb9r6XE7pr+iVeEH39fl SeLku4grh8erjtgqdlHRn3xdD4n7v35Ogj6C79Py+o3zgrhbJW9vQct+EoGj 2e+euLKM2+xvYm3mGOzb1rsxQJv86PQmGpZb7mNRUPwuJaeg3N48g5q+k6tq 9ik2Fq7iOOcJIQREDrhQP2GN2LR3rvH6xYhG8zMerx9QgxuTeNr8CSz9Q8X+ jAsegMjx8W54uNsXuUEFha71CzpJS7YfHoOCV45DgrKC0iBAVMHCYURY2z4h PEUDD5JmEzHhEi3iMrCGnE7qHj+5Hkt0fHHR1.TQPHW6AcrjVIdbo7LVQW67 lzMA8PVsh6tOwtJ4.I3tBm1SRUUjdr5AF+YOvfjSpHQHkeV3rmaBRlCwk3wt lV9rwxHUXlvHskQGXaoCJqP2d.aHdLYENrUV0CtGJM2xKzbyHEWPJsuOvdJx e5FThQtpl..FTIlUvsZP+e0r5FUDRfqHDrKqZbeJm5gLlTTEPgSra7p9bDGt rfklVZvPoB+y7zmlNi7NTaffdVagqxCRBGIfUPunzhr2evXGMQOIwzpu47GY D9KzZDHmseeN0+U3DbGNA09oYbxngcHnQr7jKVdOfwdAuU2I+QW0ppdbT6mu 9ZRFeluM0vYksT8bZaFyS7O8MvRjnverfnqzxNBzN8QxqsBpdLw5Eb5wYdGq C6YfUt9DmKDfiYlPiEN25X7XkrgmlN170iWun6z8zqhPZbMHXnaMHQyYMHgV dY3i5JnlUBsru.dh9B0Iu7XE+La2NeKNimWea+ASJFWQK.n15RUBmYchG43I d0J+Rr77dvDm2qK4ac5l+wqRtMH2b80eJsrcB3DIINHHHjfuRWjdhyDbBuzf 8tTQVJGlvUu9pRlZgQjd1fkQp.eYak3MCSD7kyJoMTlfyjmVxp1xsphmVxyM pdylM1DTAVIqlcGKHx0QTIM6oRfUcs.xDcsjw9nEamiBnZlEisrIhMrBJodz SJHsnJujJpLaC0fjGpJKAHXfjGZU3kMz9iszBXUmMm8ZbNusBPfoiB8oW0Eo l9bLow8R8UDd9aPRfuSYEiUeM8LBTNmIyOy3nNGwYUOcXMK2bFoocivryHIt gQJE2dpm7Pi4jlx+QydKXimgMRr1zoay38U82WesoSMpFNBQw21BmugZ+hFI 7MpSSP.fLdWPpo558GZ4sv5CnFyJ1wd166C939RF6SlG3BAMYOw1s15jq42v weq.xyp3W5Zjl+vp755S61QKsAyBp5RVM+N6eKdcKTjSGdxjlvctuJMMBdj9 Aisvalh+3cr7VZ+zwzBZ9qUIOta0B.Jo8KarMg8scusA0VueCKmU1fCUfr3U QAwI0+h.heJ9EL.R5u0Jg3KAq6vVx6fvWt3qeO3jLR84eIEVwNUt47Dw4WoL uK.YqXM1YEsLx6u7VV4AsC5grsaoEcogCYaOxDwea.w.SnZioW7zF.RuD2yN jB0flp2veWhIcm4bGjvAZfIraYIhNzDxoB75IknwfDwozT8qI23zjSYIsDSH mxRDMhL4VONcBeG6TDEqAhRbJhRz.QqbJhzwYyw9+53rMwbtDhrKBMu4Wg3U cdOvZNJdkp5FR8.qO3VMCj8YVbfDcfZ4EMXUdjERCDOBVA2VSAf0f+.2V6EP zLO.xcPJ5MWpIL5sGjzIvK1sYmvgu8JpPmYNrim5zIN.wsXptgw1NEkKJQEb qBGheyov0BRtcYgfNhIvsPRGRxwqmOVSVxgqJTGD410W.5jmCbuXBzYWObX7 64tBEwAe4t+GvOu7+ -----------end_max5_patcher-----------
tho, i don’t think i should have to do this. if that bassdrum sample is played in reverse in the groove helpfile, there’s no buzzing the same way there is in my patch. but w/e, this method works too.
If it was looping the same first sample value every time (I haven’t tested the bug…) it would create either silence or a dc bias… just a straight line.
< ~ 0 , for your second inlet, will only always produce a 1 or 0, and is converted and issued as a re-trigger in the form of max message int to the groove object.
If you want a sample-accurate retrigger-er, I’ve made one, and it uses count~ and sah~, groove~ will create buzzing sounds from having it re-snapped to the beginning. I think I get what you’re going for but… groove~ needs a max message to re-trigger the wave, which means it could never exceed 50hz (1000/20ms).
Get in touch with me at email@example.com.