Cherry Audio Voltage modular
- KVRAF
- 6969 posts since 28 Dec, 2015 from Atlantis Island
The thread opener sells it... Not a good sign for it
https://sonograyn.bandcamp.com/music Experimental Ambient
https://martinjuenke.bandcamp.com/music Alternative Instrumental
https://martinjuenke.bandcamp.com/music Alternative Instrumental
- Banned
- Topic Starter
- 3490 posts since 6 Sep, 2007 from France
Just i don't use it ..i m addicted to Softube Modular...
- Banned
- 11467 posts since 4 Jan, 2017 from Warsaw, Poland
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
-
- KVRAF
- 4496 posts since 25 Mar, 2016 from Seattle
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.
- KVRist
- 470 posts since 11 Mar, 2007 from Portugal
- KVRist
- 470 posts since 11 Mar, 2007 from Portugal
oops, dup, sorry
- KVRian
- 527 posts since 22 Sep, 2016
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.simmo75 wrote: ↑Thu Feb 07, 2019 5:52 pmHave 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.
-
- KVRist
- 298 posts since 1 Oct, 2018
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
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
- KVRist
- 323 posts since 19 Jul, 2008
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
- KVRAF
- 5927 posts since 8 Jul, 2009
You're hired!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%.
#NONFR Check out my music at Bandcamp Free Streaming!
Free music with your support on Patreon | Youtube: Music of Plexus Videos (music videos) | Youtube: Plexus Productions (audio related) Stop whining. Make music.
Free music with your support on Patreon | Youtube: Music of Plexus Videos (music videos) | Youtube: Plexus Productions (audio related) Stop whining. Make music.
- KVRAF
- 1672 posts since 3 Aug, 2017 from San Diego, CA
I understood some of these words.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%.
-
- KVRAF
- 10984 posts since 19 Jun, 2008 from Seattle
Me too!Tappistry wrote: ↑Tue Feb 12, 2019 5:01 amI understood some of these words.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%.
(kinda lost me with the 'f' and the 'N', but otherwise I nailed it.)
I'm not a musician, but I've designed sounds that others use to make music. http://soundcloud.com/obsidiananvil
- KVRAF
- 11093 posts since 16 Mar, 2003 from Porto - Portugal
Are we witnessing a possible merge of VCV Rack and Voltage Modular?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%.
Fernando (FMR)
- Banned
- 498 posts since 23 Jan, 2008
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.
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.