KVR Audio

plexuss · Post by **plexuss** » Wed Feb 06, 2019 8:28 pm

martinjuenke wrote: ↑Wed Feb 06, 2019 8:15 pm Are they better than Reaktor Blocks?

I 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.

W23 · Post by **W23** » Wed Feb 06, 2019 9:01 pm

martinjuenke wrote: ↑Wed Feb 06, 2019 8:15 pm Are they better than Reaktor Blocks?

I don’t know about better. Better in the sense that VM offers poly modules, and Blocks is a monophonic thing, and all patching for Blocks happens in a patching window separate from the performance area. I have played with several complex patches in Blocks and never experienced audio dropouts (unlike VM) but, then again we are talking about mono patches here. I have a feeling that VM will sort out the audio issues but, it’s important to keep in mind that polyphony is a complex thing. It’s a bit of exaggeration to say an 8 voice poly synth is basically 8 mono synths but, it’s not that far off the mark either. Logic Pro X told me the other day that VM was operating at a different sample rate than the host...something like 41087.374838HZ (I had Logic at 48000, and reduced to 44100 with no difference), and I have NO IDEA what that means but, it sure made a crackly noise while doing it. Simpler patches seem to work fine, and sound quite good! Better than Blocks? That would be subjective

pekbro · Post by **pekbro** » Wed Feb 06, 2019 10:02 pm

Well it certainly seems like the CA guys aren't too interested in addressing less than positive comments
about their product. Cmon, guys you got to have thicker skin than that. Ignoring the problem
is definitely not going to lend any confidence in CA's abilities as developers around here.

Sry if I'm off base here, but it sure seems like it...

-Cheers

wagtunes · Post by **wagtunes** » Wed Feb 06, 2019 10:13 pm

pekbro wrote: ↑Wed Feb 06, 2019 10:02 pm Well it certainly seems like the CA guys aren't too interested in addressing less than positive comments
about their product. Cmon, guys you got to have thicker skin than that. Ignoring the problem
is definitely not going to lend any confidence in CA's abilities as developers around here.

Sry if I'm off base here, but it sure seems like it...

-Cheers

As much as I love VM, I am kind of surprised that Cherry Audio is silent on the audio problems people are having.

However, as active as they have been with development, I have to believe that the issue WILL be addressed. For all we know, they're working on it now and spending more time working and less time communicating.

Let's just wait and see how this all plays out.

plexuss · Post by **plexuss** » Wed Feb 06, 2019 10:21 pm

wagtunes wrote: ↑Wed Feb 06, 2019 10:13 pm [snip...]
Let's just wait and see how this all plays out.

Better "play out" - I now have $265US invested in the platform that is pretty useless to me unless I stick with simple patches. I'll give it some time but Cherry needs to prioritize this now. We need multi-core support and over-all much improved performance.

DarkStar · Post by **DarkStar** » Wed Feb 06, 2019 10:31 pm

CA have helped me out with a few things and are considering some of my suggestions. Why not log the issue on their forum or in their Help Centre:
https://forums.cherryaudio.com/viewforum.php?f=8
https://cherryaudio.kayako.com/login
(The only thing is you do need to Register for each one).

Dillinger · Post by **Dillinger** » Thu Feb 07, 2019 3:30 am

I reported the issue on page 41

plexuss · Post by **plexuss** » Thu Feb 07, 2019 4:13 am

Dillinger wrote: ↑Thu Feb 07, 2019 3:30 am I reported the issue on page 41

I reported the CPU issues on their help site, conversation ID 190277

Dillinger · Post by **Dillinger** » Thu Feb 07, 2019 4:21 am

Great Plexuss, they can’t say they weren’t aware then.

I’m sure they’ll get it sorted out. In the meanwhile my trial expired and it has caused me to pass on it.

Neutron here I come!

lnikj · Post by **lnikj** » Thu Feb 07, 2019 7:49 am

To be fair, effectively implementing multithreading in a modular without introducing delays on the wires is not trivial.

Urs reckoned it couldn't be done; Andrew Belt is only now implementing it in 1.0 of VCV Rack; Softube who need it more than anybody have not done it.

There is a significant CPU/thermal cost to doing it it seems because the only effective solution at the current time appears to be through utilising spinlocks, because CPUs cannot put threads to sleep and wake them up 48k times a second.

Don't hope for miracles here.

plexuss · Post by **plexuss** » Thu Feb 07, 2019 7:52 am

If anyone can do it you can.

Thing is even with 1 core (or whatever the technical term is) I have other synths that perform WAY better. It seems like there is a lot of opportunity to improve the performance even is multi-core is not available. Be that with VM itself and/or the developers of the modules (thats you PSP and Vult). Get on it!

lnikj · Post by **lnikj** » Thu Feb 07, 2019 7:58 am

plexuss wrote: ↑Thu Feb 07, 2019 7:52 am If anyone can do it you can.

Thing is even with 1 core (or whatever the technical term is) I have other synths that perform WAY better. It seems like there is a lot of opportunity to improve the performance even is multi-core is not available. Be that with VM itself and/or the developers of the modules (thats you PSP and Vult). Get on it!

I don't own Vult on VM so I couldn't replicate your patch, so I tried to build it in VCV Rack and was there or thereabouts. It did not prove taxing on my computer (an ailing 2011 MBP). If it means anything (ie if you use Rack) I had about 650mS left, so I would be expect to be able to run twice as many modules before encountering any audio glitching.

pekbro · Post by **pekbro** » Thu Feb 07, 2019 8:27 am

lnikj wrote: ↑Thu Feb 07, 2019 7:49 am To be fair, effectively implementing multithreading in a modular without introducing delays on the wires is not trivial.

Urs reckoned it couldn't be done; Andrew Belt is only now implementing it in 1.0 of VCV Rack; Softube who need it more than anybody have not done it.

There is a significant CPU/thermal cost to doing it it seems because the only effective solution at the current time appears to be through utilising spinlocks, because CPUs cannot put threads to sleep and wake them up 48k times a second.

Don't hope for miracles here.

You would think you could solve something like that with a matrix. Where you wouldn't
have to put them to sleep at all.

Koshdukai · Post by **Koshdukai** » Thu Feb 07, 2019 9:33 am

pekbro wrote: ↑Thu Feb 07, 2019 8:27 am
lnikj wrote: ↑Thu Feb 07, 2019 7:49 am To be fair, effectively implementing multithreading in a modular without introducing delays on the wires is not trivial.

Urs reckoned it couldn't be done; Andrew Belt is only now implementing it in 1.0 of VCV Rack; Softube who need it more than anybody have not done it.

There is a significant CPU/thermal cost to doing it it seems because the only effective solution at the current time appears to be through utilising spinlocks, because CPUs cannot put threads to sleep and wake them up 48k times a second.

Don't hope for miracles here.
You would think you could solve something like that with a matrix. Where you wouldn't
have to put them to sleep at all.

If you want to think of it like a matrix, then the spinlocks are exactly what's happening on the "empty" cells of that conceptual matrix

... Hope that can more clearly illustrate the issue at hand.

resynthesis · Post by **resynthesis** » Thu Feb 07, 2019 10:39 am

Does anybody know how VM handles Java? Are modules distributed as bytecode in the JAR or are they further processed after they're uploaded from the module designer to the Cherry website?

Cherry Audio Voltage modular