When you create a patch that runs at about 85% of the CPU speed, it can still sometimes stop unexpectedly after 20 minutes. I would like to see an improvement where a safety margin is introduced (green or red numbers), especially for live performances, to ensure that the patch doesn’t stop playing abruptly. Also I would like a settings for 44KHz.
+1 for 44 kHz. 32 kHz too? 24 kHz just removes too much top end.
Because of the way the internal peripherals work, 32kHz is a lot easier to implement, so I went ahead and added that to the next firmware version.
I also added 16 as a valid block size. Now, if latency is critical and CPU usage is low, you can get under 0.7ms latency (I just measured a patch on my oscilloscope: @96kHz, Map GateIn 1 → 4ms RCD Clk In, map any trigger output to a panel output = 675us latency)
That type of issue might be helped by increasing the block size. Try the next size up and see if it still happens. Large blocks “smooth out” peaks in CPU usage.
You mean display the load in red if it’s over, say, 80%?
One idea is to allow CPU > 99% but just accept a click or dropped samples. Of course if CPU usage goes too high then the patch will need to be stopped. But in a live setting, having a click might be better than sudden dead silence? Thoughts?
1 Like
honestly would love the option to have an allowance of >99%! 20+ years of dealing with windows laptops’ audio, dont mind dropped samples one bit. it a feature not a bug ;]
any chance in getting block sizes higher than 512? say 1024->8192. like vcv/daw’s offer. guessing maybe not as many spikes when plugging unplugging physical cables or turning knobs mapped to many things? on a laptop it sure adds a lot more flex with high cpu patches. sure it’ll add a lot of latency but for a lot of complex ambient drone patches, self running krell or textural type ones that just dont have any need to sync to anything ever, having a large latency is truly a non issue. and anyone wanting to work in those higher blocks would just already know/accept higher delays as a cost of doing business
Yes the block size helpt a lot, thanks…
What I mean is like a small stress test before playing the patch 
and MM will say “This patch is save”
There’s a hard limit due to the use of fast internal RAM for the buffer. It’s possible to use slower RAM, but performance drops a little bit. Might actually be a tradeoff point if it’s huge, 8192 or something where it’s not any slower.
I’ll play with it…
I am running Rings and change the Polyphony knob, and it’s funny because the higher block size is not better. The best setting I have now is with 128. and before it was like 256 and then the patch stoped playing…
32Khz is an amazing idea, the Korg 01/Ws samples were all 32Khz and had a deliciously dark sound - and 32Khz could get more polyphony for certain patches…
…talking of patches, I’m guessing it might be too much to ask for the sample rate to be saved on a per-patch basis? It would be useful to have 32Khz for crunchy digital Poly stuff and then 96Khz for the odd patch that needs it (anything with filter fm)
While we’re at it why not add 16Khz for super low fi and presumably lots of cpu?
1 Like
+1 for 16kHz. It could be very useful for complex CV processing/generative patches where audio quality isn’t important.
1 Like
definitely +1 for 16khz, even for some using mm as a voice cases, it would still be nice
2 Likes