Performance
Infriad
SwedenPosts: 3
Hi!
I recently switched my Octatrak to a Deluge and was blown away by this instrument! It really fitted perfectly in my current setup. Love the workflow.
However, yesterday when I worked on a song the deluge started to behave strangely. The UI got very laggy. For example when changing presets there were big delays when scrolling between them.
And when I recorded a sequence some notes froze and the sequence got all messed up.
I had like 8 tracks going so I thought that it must be a performance issue so I started to resample the tracks that had active effects. That helped a bit but then I noticed that all these tracks went out of sync eventually?
So after some investigation I found out there was one specific effect on a track that caused the performance-issues, the Custom 2. When I turned it down the lag went away. So now I wonder if there is a way to know what effect is bound to a Custom slot on a patch? I wanna know what it is so I can avoid it.
I must say that I was not expecting this. Haven’t heard anyone complain about the performance on the deluge. What is your experience? And do you have any tips on how to manage the resources?
Comments
usually custom 2 is set to decimation. navigate so that value is on the screen (shift + decimate shortcut), turn the custom 2 knob and see if the value on screen changes as you turn the gold knob. if so, then decimation must be causing it (which would be odd in my experience). otherwise, you'll have to try other parameters and see which one changes correspond to the gold knob.
alternatively, if you open the .XML file of the synth patch on your computer, scroll to the bottom, the very last "modKnob controlsParam" line correlates to custom2. decimation is noted as "sampleRateReduction". im curious what it could be!
Hi @reza, thanks for your reply!
I checked the xml and it seems like "env1Sustain" is bound to custom 2 and that does not feel like a CPU-heavy effect to me. I think this is a preset so anyone should be able to reproduce it. It's number 107.
ah, really interesting.
basically the polyphony, delay, the sustain being brought up, the slow delay rate (1 bar), and certain ASDR being set to random is bogging the CPU (or RAM?) of the deluge. those parameters are creating a LOT of polyphony if your sequence is even just a little complex since it's tracking each note for a long time and each note has different A, D, and R to track. i've actually never run into slowdown issue when building out songs w multiple clips. but this synth patch is a perfect storm.
things you can do to mitigate:
change delay from analog to digital. (didn't help that much but analog uses more processing)
lower or set delay amount to 0. (didn't help much either, points to delay not being the big issue)
switching synth mode from polyphony to mono. (helps a ton since voices cut each other off, the sonic difference may not be preferred, clearly the polyphony is hogging resources)
set sustain lower permanently, and remap custom 2 to something else. (the longer the sustain, the more of a slowdown was caused. if you don't see yourself using the effect, make it so you can't accidently have it turned up. i would personally maybe save over the original preset as slowdowns are no good)
another big culprit was that sustain and decay were patched to random. i bet that this makes polyphony even more process heavy since it's making unique ASDR values per note instance.
also, if you love the sound/preset in the context of the song you made, you could try setting the patch's priority from normal to low, which will allow other clips' voices to have priority rather than the crazy intensive ones patch 107 has, the effect may be slightly similar to switching from poly to mono.
Thanks for all the tips! I messed around with it all these settings and I got it to sound almost the same without being a resource hog. It’s good to hear that this is not usual. I guess I was a bit unlucky to pick that patch in one of my first jams with it 😊
And also, an update on the out of sync resampling that I mentioned. I saw a post about this on the Deluge group on facebook. It’s a confirmed bug that should be fixed in the next firmware update.