Cherry Audio Voltage modular

VST, AU, AAX, CLAP, etc. Plugin Virtual Instruments Discussion
Post Reply New Topic
RELATED
PRODUCTS
Voltage Modular Core + Electro Drums Voltage Modular Ignite Voltage Modular Nucleus

Post

i am selling a licence for Voltage Modular Core + Electro Drums + Misfit Audio Digi Drums , if someone want to buy it , contact me ;)

Post

The thread opener sells it... Not a good sign for it :scared:

Post

martinjuenke wrote: Thu Feb 07, 2019 11:12 am The thread opener sells it... Not a good sign for it :scared:
Just i don't use it ..i m addicted to Softube Modular...

Post

plexuss wrote: Wed Feb 06, 2019 8:28 pmI have Blocks but I have no experience with them as I haven't used them. But I have used other modular VIs and they consume way less CPU than VM. :party:
VM on its own is very CPU efficient, but - from my experience - Vult's filters are really heavy so that might be your issue right there. It's the only thing preventing me from getting that particular bundle :(
Music tech enthusiast
DAW, VST & hardware hoarder
My "music": https://soundcloud.com/antic604

Post

antic604 wrote: Thu Feb 07, 2019 11:31 am
plexuss wrote: Wed Feb 06, 2019 8:28 pmI have Blocks but I have no experience with them as I haven't used them. But I have used other modular VIs and they consume way less CPU than VM. :party:
VM on its own is very CPU efficient, but - from my experience - Vult's filters are really heavy so that might be your issue right there. It's the only thing preventing me from getting that particular bundle :(
Have also noticed the Vult bundle being very heavy on the CPU. I bought it though so I’m really hoping Vult can update its efficiency. They sound amazing.

Post

simmo75 wrote: Thu Feb 07, 2019 5:52 pm ...
Vult bundle being very heavy on the CPU.
...
They sound amazing.
That's usually a related trade-off. Hopefully, there's still something to optimize :?:
Last edited by Koshdukai on Thu Feb 07, 2019 6:03 pm, edited 1 time in total.

Post

oops, dup, sorry

Post

simmo75 wrote: Thu Feb 07, 2019 5:52 pm
antic604 wrote: Thu Feb 07, 2019 11:31 am
plexuss wrote: Wed Feb 06, 2019 8:28 pmI have Blocks but I have no experience with them as I haven't used them. But I have used other modular VIs and they consume way less CPU than VM. :party:
VM on its own is very CPU efficient, but - from my experience - Vult's filters are really heavy so that might be your issue right there. It's the only thing preventing me from getting that particular bundle :(
Have also noticed the Vult bundle being very heavy on the CPU. I bought it though so I’m really hoping Vult can update its efficiency. They sound amazing.
That makes sense though. If you have played with U-he’s RePro, then you know a good sounding filter (per voice) will hit a CPU hard. Even the Cytomic filters available in Ableton instruments almost double the CPU hit over the regular Clean one. I think it may be a question of VM working to increase the overall efficiency because some of the more complex patches I tried were using the standard VM filters, and they were very crackly all the same.

Post

Hi all,

Hey there! We haven't been ignoring you, just recovering from NAMM and hard at work on new features. A few notes on efficiency:

* Voltage Modular is very CPU efficient, and we work hard to ensure our modules are very CPU efficient. However, just like with any plug-ins, it's up to third party developers to build efficient modules, and some third party modules can be CPU hogs.

* That said, we're working hard to make VM even more CPU efficient. We'll have an updated release in the near future - likely next week - that may help make mixing smoother.

* Regarding multi-processor mixing, as was mentioned earlier in this thread, there's no way to do multi-processor mixing in a modular synthesis environment that doesn't add latency. We've experimented with different ideas for multi-threaded mixing, but in every case things end up being less efficient and using more CPU. I'd be happy to discuss this with everyone on a more technical level if you'd like, but everything discussed on this thread so far is very accurate - software threads simply aren't designed to go to sleep and wake up 48,000 times per second, so even with the added latency, far less efficient methods have to be employed to split the work up between multiple threads. This is very easy to do if you're simulating a classic polyphonic synthesizer, but it is very, very difficult to do in any meaningful way if you're using free-form modular synthesis. We'll keep pondering this problem and we'll see what happens..

* New modules are coming along with the new build next week. I'll keep you all informed!

All the best,
Dan @ Cherry Audio

Post

You don't need to yield 48,000 times a second between module timesteps. Only once per VST process() buffer. You can spinlock between each sample. If your algorithm to allocate modules to threads is decent (like OpenMP's `guided`), each thread will spend about equal time on actual DSP work, and your spinlocks will only "clean up" the difference of time at the end. This gets you pretty close to the ideal case users are expecting where using N threads allows nearly N times more modules, and using only a fraction f of the maximum possible modules requires slightly more than f CPU time on those N threads, instead of pegging N cores at 100%.
VCV Rack, the Eurorack simulator

Post

vortico wrote: Tue Feb 12, 2019 4:19 am You don't need to yield 48,000 times a second between module timesteps. Only once per VST process() buffer. You can spinlock between each sample. If your algorithm to allocate modules to threads is decent (like OpenMP's `guided`), each thread will spend about equal time on actual DSP work, and your spinlocks will only "clean up" the difference of time at the end. This gets you pretty close to the ideal case users are expecting where using N threads allows nearly N times more modules, and using only a fraction f of the maximum possible modules requires slightly more than f CPU time on those N threads, instead of pegging N cores at 100%.
You're hired! :phones:

Post

vortico wrote: Tue Feb 12, 2019 4:19 am You don't need to yield 48,000 times a second between module timesteps. Only once per VST process() buffer. You can spinlock between each sample. If your algorithm to allocate modules to threads is decent (like OpenMP's `guided`), each thread will spend about equal time on actual DSP work, and your spinlocks will only "clean up" the difference of time at the end. This gets you pretty close to the ideal case users are expecting where using N threads allows nearly N times more modules, and using only a fraction f of the maximum possible modules requires slightly more than f CPU time on those N threads, instead of pegging N cores at 100%.
I understood some of these words. :lol:

Post

Tappistry wrote: Tue Feb 12, 2019 5:01 am
vortico wrote: Tue Feb 12, 2019 4:19 am You don't need to yield 48,000 times a second between module timesteps. Only once per VST process() buffer. You can spinlock between each sample. If your algorithm to allocate modules to threads is decent (like OpenMP's `guided`), each thread will spend about equal time on actual DSP work, and your spinlocks will only "clean up" the difference of time at the end. This gets you pretty close to the ideal case users are expecting where using N threads allows nearly N times more modules, and using only a fraction f of the maximum possible modules requires slightly more than f CPU time on those N threads, instead of pegging N cores at 100%.
I understood some of these words. :lol:
Me too! 8)

(kinda lost me with the 'f' and the 'N', but otherwise I nailed it.) :tu:
I'm not a musician, but I've designed sounds that others use to make music. http://soundcloud.com/obsidiananvil

Post

vortico wrote: Tue Feb 12, 2019 4:19 am You don't need to yield 48,000 times a second between module timesteps. Only once per VST process() buffer. You can spinlock between each sample. If your algorithm to allocate modules to threads is decent (like OpenMP's `guided`), each thread will spend about equal time on actual DSP work, and your spinlocks will only "clean up" the difference of time at the end. This gets you pretty close to the ideal case users are expecting where using N threads allows nearly N times more modules, and using only a fraction f of the maximum possible modules requires slightly more than f CPU time on those N threads, instead of pegging N cores at 100%.
Are we witnessing a possible merge of VCV Rack and Voltage Modular? :lol:
Fernando (FMR)

Post

Dan, thanks for the good news. I will wait for new modules to appear. I noticed that other synthesizers are not interesting to me already. Because I can build any synthesizer myself.
cherryDan wrote: Tue Feb 12, 2019 2:24 am * Voltage Modular is very CPU efficient, and we work hard to ensure our modules are very CPU efficient. However, just like with any plug-ins, it's up to third party developers to build efficient modules, and some third party modules can be CPU hogs.
Yes, I feel that my computer spends a lot of resources. But I have not updated the computer since 2008. I have a Xeon e5450 3 Hhz Lga 771, 8 GB DDR2 800. I can work with 5-6 tracks. But if more, I freeze, and it suits me.

Post Reply

Return to “Instruments”