Here’s the patch. Basically if I don’t input CV into changing algo, then it’s stable no matter what knobs I turn.
but as soon as I input CV into the CV ins 4,5,6 it overloads and kills the patch.
Is there a way to make it so the CPU doesn’t overload?
https://patchstorage.com/4ms-metamodule-grids-3-plaits-eqpan-chan-adj-accents/
FURTHER TEST: I ran it with 1 of the 4,5,6, cv inputs and it didn’t overload the CPU until a few minutes of use. I was also using CV inputs 1,2,3 at the same time. after a few minutes it crashed the patch even with just one CV input into 4,5, 0r 6 (while also taking inputs 1,2,3 cv in). Crashed twice took about 3-5 mins.
Actually… It just started crashing with JUST 1 in CV 4,5, or 6. nothing in 1,2,3.
FURTHER test 2: redirected all the CV ins to density/xy and after about 10-15 mins it crashed in the middle of twisting EQ high chan 1… which I think was just coincidental as I previously changed it multiple times at that point.
@danngreen here’s another patch where if you put CV in, it crashed the module every single time. What am I doing wrong? I know I’m loading until about 80% CPU roughly 80-85%, did I miss something where it said to not load beyond 70%?
https://patchstorage.com/alldrums-crashes-with-cv-ins/
thought i read someone mentioning at MW that any virtual cables spanning from the inputs on the metamodule (inside the patch)- those are disabled until we plug an actual cable into one of the jacks. could this be true?
then i could maybe see cpu jumps occurring in patches where we have a lot of virt cables running from the mm inputs in the patch into other modules (since ive noticed adding cables in vcv seems to add cpu)
curious if you’d be interested in testing this theory by removing all but one patch cables from those inputs and then try again on the mm to see if the crashes still occur? id test on my own mm’s but they are annoyingly still stuck with the postal carrier somewhere in california.
Often modules will do more processing if their jacks are patched. Or other times they won’t care if a jack is patched or not, but will run some extra processing if the CV value on the jack changes. This is how it works with many VCV Rack modules, and they run the same on MetaModule.
The way the Noise Plethora works is that it loads a new algorithm whenever you change the CV value into the “Prog A” or “Prog B” jacks. The processing time it takes to load causes the CPU to spike if you modulate them. “In 4” is stacked into 7 CV jacks, including both Prog A and Prog B. So removing those connections helps a lot, but it still has some spikes.
You can smooth out these spikes by increasing the block size. I loaded your patch, patched in 4 gate sequences and 4 CV sequences and patched the 3 output jacks to a mixer, and then saw it hit >99% and stop. Then I set the block size in Settings > Prefs to 512 and it’s been playing the whole time I’ve been typing this with no glitches. YMMV, it’s running at about 90% and the CPU varies by a few %age when I randomly turn knobs, so there might be some settings where it hits > 99%.
You could probably also use a smaller block size if you disconnect In 4 from the Prog A and Prog B jacks, too.
So it’s not a bug, it’s just how the Noise Plethora and other modules work. Solution is to increase block size to smooth out those spikes, or to not modulate some “heavy-hitters” CV jacks, or experiment with some lower-CPU modules
Update: I disconnected In 4 from the two Prog jacks and Cutoff B on the Noise Plethora, and am able to run it with a block size of 128 with no issues.
Update 2: Spoke too soon. Need to disconnect In 4 from a few more jacks to get it to run at 128.
1 Like
Thanks Dan. It’s disappointing because I have no idea if what I’m making is going to screw up the Meta. That’s my real frustration. I had to “test back and forth” this patch from computer to Meta like 20x and I took maybe 2 hours doing something that I patche dup initially in like 10 mins. The exclusive reason/problem is I have zero idea if what I’m doing is anywhere near the CPU cap, and then when I get CPU to 83% I think I’ve won a prize, and it’s not actually good enough cause once I put in cv, it craps out like a cheap toy. Of course, it’s not, which is the problem. So the solution, maybe you can’t do anything for these CPU spikes, but maybe you can do some kind of other program that can model the meta so we can just load it up in the PC? Maybe we can get a list made that you send out of the different modules and what CPU use they have and what spikes each jack can create. If I know that information then I can easily math out an acceptable set of connections in VCV.
but what I’m hearing is “make sync suck by going to 512” on drum modules, or basically understand that if you use it too much, move knobs too much, or send too much CV you’re going to crash a your patch, so stay under 60%, or 70% or whatever it is. which I would be guessing back and forth for hours and hours until I find the magic little vca module that isn’t as expensive on cpu as the other one, and finally cut the load by 5%, which is enough to input cv into jack 5 finally… I mean is that the workflow you imagined?
having ZERO vision on what CPU load any module is, and then even less than zero vision on what each input jack load would be is super super annoying and frustrating beyond measure. If I knew, I would keep the patches super brain dead simple, which at this time, is the only solution. It basically means “don’t press the gas, the car breaks down easy” - there’s got to be maybe some way to make modules less CPU intensive, or to calculate for max load with all cv’s jacked up?
1 Like
@danngreen Here’s another patch that’s about 50%-53% but when I add ONE CV in it’ll crash as soon as that CV gets near audio rate. Clearly not a problem when I have it in LFO mode. Audio rate kills it almost instantly.
you’re telling me that audio rate inputs take 47% of the CPU?
sounds like the solution to this is to use a rate limiter (or s&h).
for sure, this is something users could do. but I guess the issue here, is often users will not know which inputs are cpu intensive, its not always obvious.
perhaps a solution could be, within the MM ‘wrapper’ around the module code is to introduce a rate limiter on specific cv inputs - this is an approach that Ive used in the past, and most users never notice 
(even in hardware it happens, iirc, some MI modules only modulate some parameters on block boundaries, a kind of ‘control rate’ albeit fast ;))
ofc, this is not ideal, as some of these inputs could be modulated at higher rates IF the user is willing to ‘spend cpu’ on it. so I guess could be made ‘optional’ with default to rate limit = on. but I think this would be more a ‘nice to have’
I know, it can be frustrating not knowing what the CPU impact will be. Bear with us though! We have two things on the roadmap that will make this a more pleasant experience:
- CPU load estimates on VCV and on the MetaModule itself
- Continue to refine the ported modules to make them run more efficiently.
It’s only been out for a week, so please be patient as we improve!
The vast majority of the time, CV-ing a jack has only a tiny effect on the CPU load. You got unlucky and found a few jacks that happen to have a huge impact on the CPU load: Plaits Model CV (which selects the algorithm) in combination with Plaits Harmonic CV. Also the Noise Plethora Prog CV (which selects the algorithm). I can make Plaits exceed 100% when block size is 32, in a patch by itself when I CV the Model and Harmonics at the same time with different audio-rate oscillators. I haven’t dove into the code to see what’s happening, but we can certainly fix it (something like @TheTechnobear suggests would work, or maybe reverting back to the original pre-VCV module code… Sometimes it’s a difference between how NEON simd works vs Intel or a difference between efficiency of 32-bit and 64-bit…)
I will add a TODO issue to improve the efficiency of when CV’ing these jacks on the MetaModule.
There probably are more jacks like this lurking, so don’t be surprised! Making patches like the ones you posted where one CV splits to 6-8 destinations is a great way to find these types of issues, so I appreciate you sharing your findings. And I’m sorry it’s been hard going in the process.
But we can tackle these, it’ll just take a little time.
5 Likes
Thanks for the reply Dan. I’ve opted to start doing is run audio rate CV inside the meta itself. Can’t wait for input expanders… maybe you can make some cv only so we can use those to send to sensitive inputs when designing patches. Of some kind of detection system that sees coupled spiking and just kills whatever is doing it? Or somehow hard limits it in the firmware. I wouldn’t care or probably know it existed so long as it doesn’t crash! So if I was sending cv in I’m just listening and whatever sounds good is good. I don’t care that the firmware is limiting me if I am causing a spike. Seems like a cool idea.
I haven’t had all my patches crash just yet and I’ll use your advise until we get other solutions.
I’m about to go make some generative sequencers from scratch which should be way more stable. The audio stuff seems hard to get cv right because I don’t know where to limit my cv when twisting knobs irl… I have to kinda guess now that I know. You’ll get some dope fixes soon.
I got three plaits working and I’ll post the patch soon, after that I’m going to do a three generative sequencer patch if it fits lol. If I can get two metas playing each other I’ll be pretty happy
@TheTechnobear id love to hear exactly how to patch the limiter.
