Greg NiemanJust hit this and am curious if anyone sees the same thing?
I often open up a groove, modify a piece of it, and work out from there. Very often the suggested tempo isn’t exactly what I had in mind, maybe faster, maybe slower but I never paid much attention to any of that. Prior to SD3 I always just worked in the Cubase Drum Editor, but I decided to try to make use of SD3’s editor this go around since it’s got a lot of specific features.
Opened SD3 in standalone mode. Reggae kit. I opened up a 100 BPM groove, made a few changes and saved it off in SD format. In the process of playing around, I wound up setting the tempo to 160. Because I was still experimenting I put it in loop mode so it would keep cycling.
And here’s the weird thing: it cycled fine the first few passes, and after that at the end of each loop it paused. A noticeable hesitation before proceeding. I made numerous attempts to get rid of this(settings changes, modified selection length, exported to MIDI and re-imported). No luck.
At that point I opened Reaper for a quick test. Added a MIDI track with the exported block from above and put it in loop mode there at 160. No issues, looped like a champ. But then I created another VSTi track with SD3 and imported the MIDI directly in SD3. Turned on the loop with Follow Host enabled and hit play in Reaper. And what happened there was you saw the pause for the first couple of runs, and then it started looping normally. At that point I was really scratching my head.
Until by accident I was back in standalone resetting the tempo and didn’t get it quite right. 159 instead of 160. And then lo and behold, it cycled without a hitch. So then I set it to 161, and the same thing, looped fine. Set it back to 160, and the stutter returned. Set it up to 175, no issues. Back down to 120 and even 130, no problem. Back to 160, stutter came back.
I mean, I do have a workaround, given I can always go up or down a beat and it shouldn’t mess with the performance too badly. But it does kind of weird me out just a little. Being a developer by trade it feels like maybe there’s some kind of math/rounding error in there somewhere, but then it ain’t my code. But it does seem like this is something where there should at least be some kind of root cause/explanation. Haven’t replicated this with other patterns yet, but I’m attaching the one I used. Again, it’s just an edit of an existing Reggae Beat groove.
Thanks in advance for any input. Attaching the MIDI file I used.
Windows 10 Pro
Version 1903
Processor i7-6700K@ 4.00GHz, 32G RAM
Bear-Faced CowBeen playing the MIDI file in a loop for the last five minutes (it’s now like the Japanese water torture)… unable to recreate the issue here.
jord
Greg NiemanNot sure what to say then. It does it on my self assembled workstation in my studio and on my new Dell XPS. Curious on your setup though, since it’s not specified and makes me wonder if it’s hardware or OS related. Thanks for checking that, BTW.
Bear-Faced CowAlthough, I’m running on a Mac with Mojave 10.14.6 (tested both in standalone and in Logic), I find it difficult to believe it has any relativity. Could be something something stealing your CPU resources at a more “coincidental” moment.
jord
Greg NiemanOn 2 different classes of machines that both exhibit exactly the same behavior? And I mean, not much extra is running at the time. Not even the DAW initially since it showed up in SD3 standalone.I guess anything’s possible but from the perspective of someone who troubleshoots a lot of software issues on a daily basis coincidences like that are few and far between. If switching activation status per machine and the associated limits weren’t kind of a PITA I’d do an installation on my Macbook Pro to see if it was consistent.
Bear-Faced CowDifference in class could have little to do with this. It could all depend on what was installed on both machines. There could very well be something under the hood stealing resources. I’ve seen enough of that in my years both as a software developer and as someone who’s set up plenty of audio production systems. Audio is especially taxing on computer resources, and can get knocked off kilter by certain processes. I’ve killed a lot of daemons to keep my audio Mac running smoothly.
jord
Greg NiemanTwo completely different installations with very, very different software setups. And if you’re hypothesis is correct and it’s resource contention, then why doesn’t it continue when you move up to 161? And goes away after knocking off only 1 BPM?
Again, I debug issues a developer customer base, and this has a very math-y, somebody got too clever for their own good kind of smell to it. Again, not my code, I can’t see it, but when something just occurs at a specific value across two heterogeneous setups my spidey sense just tingles.
So while I appreciate the input, I don’t think think that assertion passes the test for me. Not really expecting much here anyway. Just assuming I’m going to need to run a funny looking tempo while I’m building in SD3 and go back to 160 when I move it back over to the DAW. Or maybe I’ll just stay there and edit in Cubase. There’s a few upsides to staying in SD3 but it’s not like I’m doing anything that complex.
Bear-Faced CowAnd I code at a more systems and automations level. What’s your point? This could be something as elusive as a race condition competing for resources at just the right time. Hence the 160bpm, considering my “theory” was based on recent observations on an automated testing framework that I was troubleshooting recently.
If by your theory that something is “math-y” with the software alone, then why wouldn’t it be universal considering that this particular part of the code base would be common considering that we’re both Intel processors? Not to mention that it would be easier to exacerbate on the Mac due to how CoreAudio operates. Sorry, but there’s not enough there to scream bug without doing a further deep dive to prove it in this case.
jord
Bear-Faced CowJust for shitz an gigglez, I decided to try to bog down the resources to make things tougher on CoreAudio on my dev MacBook Pro, including a couple of active JVM processes (they have proven in the past to be the worst enemy to CoreAudio). Your MIDI file is running like a clock at 160BPM without issue. I could take it further by clearing the Spotlight cache, triggering a swarm of mdworker daemons if we want.
However, there’s nothing proving to be “math-y” within SD3 with this. It’s holding its own.
jord
Greg NiemanLook, I’d argue here that you didn’t prove anything other than what I just said. But… You were nice enough to reply and you did make an investigative effort and in appreciation I think I’d just like to let it drop and just move to the 161 tempo till I bring the MIDI back into the DAW. It ain’t 100% optimal but I can live with it in the long run, so WTH.
Again, thanks for checking, much appreciated. But let’s just put this one to rest for now.
No products in the cart.