Arturia V Collection 6

[ENV1]

I found the CPU usage very high.

It eats quite a bit of RAM too.

Observe:

DX7 V, circa 245MB per instance. A gig of RAM gives you ~ 4 instances.

DX7V-RAM.gif

To compare: FM7, circa 30MB per instance. A gig of RAM gives you ~ 34 instances.

FM7-RAM.gif

PS: This is on a 32bit system. On 64bit its probably a smidgen more.

I think that the high RAM usage is the images of the GUI. It's something that happens on all >V5 Arturia synths.

The GFX are certainly part of it, however they cannot account for the high RAM usage alone because the entire 'resources' folder for the DX7 V is only 157MB (183MB on disk) and not all thats in there is images. (There are circa 3MB of other stuff.)

So even if everything in the resources folder was loaded into RAM, there are still circa 79MB that must come from elsewhere. If we assume that the presets are being copied from disk into RAM as well then circa 24MB could be attributed to that, which would leave about 55. These 55 are then probably attributable to DLL decompression (the main DLL is circa 9MB filesize), DLL imports, etcetera. A small part of that (in my GIFs) would be attributable to whatever SAVIHost used. (Too lazy to check the exact details but it seems like a plausible scenario.)


At any rate, its higher than it needs to be. There is no doubt in my mind that this could be optimized quite a bit, and this goes for diskspace usage as well. (There is absolutely no good reason why 157MB worth of images should take up 183MB of diskspace.) A good start would be to use image strips for animations rather than a single image for each frame multiplied by the amount of available UI sizes. (Which is whats causing all the wasted space.) With 'convert' and a 1-line terminal command you can stitch a whole folder full of single images in under 1 second, and with a second line (just make a .cmd file for repeated use) you can even have the resulting image strip moved to the desired location automatically, still in under 1 second. So its practically no extra work/time, but the gain would be significant, especially considering that we are not only talking about one plugin, but many. (And some of them are way bigger than the DX7 V, the CMI for instance has a resources folder more than twice as large and a presets folder more than 6 times as large.)

The next step would be to make one hi-res 'master UI' (i.e. the 100%-size UI) and then simply scale that down on-the-fly for the smaller sizes. (This has been proven to work very well if done right.) To still have the sharpest-possible text for labels and stuff just generate it during runtime rather than baking it into the images. That way it wont be a problem even if one of the smaller UI sizes is being used on a bigger screen since the text will be rendered at its original size with full anti-aliasing rather than being shrunk with the images and thus suffer from unsightly blurring.

With these 2 things taken care of, both RAM usage and diskspace usage would be but a fraction of what it is now.

[Ingonator]

Most RAM seems to be taken by the first instance of DX7 V while additional instances use less and less aditional RAM. With 10 instances there seems to be an average of around 80 to 100 MB per instance.
Tested with the 64-bit VST2 in Live 9.7.5 64-bit at Windows 10 64-bit.

Anyway that's when the GUI of all instances is closed. If you open the GUI of multiple or all of them the RAM usage increases again.

I agree that RAM usage is quite high for a plugin that does not use samples.
On the other hand this shows that you do not have to use big sample libraries to use a lot of RAM and that using a 64-bit host and a bigger amount of physical RAM could make sense beyond using sample libraries.

Until the RAM usage is reduced i would recommend closing the GUI for DX7 V instances where it is not necessary to ahve it open.

[andrew71]

Regarding DX7 presets. Anyone would not happen to know some good 'Electronic body music' syx resources?

Front 242 was a Belgian Body music band that used the DX7 a lot.
Some typical sounds are "bright basses" like in the included preset "Growling bas".

The song "Headhunter" demonstrates the typical sound of Front 242.

I recall reading that on Headhunter, Front 242 used just the reverb tail of an FM sound for the distinctive opening/bass synth.

[electro]

Does DX7V get closer to DX7 on .syx import than Dexed?

[Ingonator]

Does DX7V get closer to DX7 on .syx import than Dexed?

As i tried to explain earlier DX7 V with imported Syex could sound better than both Dexed AND a real DX7. Of course "better" is subjective in this case but still this is my opinion.

In DX7 V you got the DAC RES switch to change to a higher quality and the Velocity mode switch to switch between the behavior in the first DX7 and using the full velocity range which seemed to be also fixed with the DX7 II that was released later.

FWIW also a DX7 II (D and FD models) had a better sound quality than the original DX7 so a comparison to a DX7 II could make sense too if you really want top compare to the hardware.

As soon as you start to use the lots of advanced features in DX7 V a comparion to both other plugins and a real DX7 gets quite pointless anyway.

[12deadpixels]

ENV1

Please send this report to Arturia, ENV1, to show them that product optimisation is very important for their customers.

I found the CPU usage very high.

It eats quite a bit of RAM too.

Observe:

DX7 V, circa 245MB per instance. A gig of RAM gives you ~ 4 instances.

DX7V-RAM.gif

To compare: FM7, circa 30MB per instance. A gig of RAM gives you ~ 34 instances.

FM7-RAM.gif

PS: This is on a 32bit system. On 64bit its probably a smidgen more.

I think that the high RAM usage is the images of the GUI. It's something that happens on all >V5 Arturia synths.

The GFX are certainly part of it, however they cannot account for the high RAM usage alone because the entire 'resources' folder for the DX7 V is only 157MB (183MB on disk) and not all thats in there is images. (There are circa 3MB of other stuff.)

So even if everything in the resources folder was loaded into RAM, there are still circa 79MB that must come from elsewhere. If we assume that the presets are being copied from disk into RAM as well then circa 24MB could be attributed to that, which would leave about 55. These 55 are then probably attributable to DLL decompression (the main DLL is circa 9MB filesize), DLL imports, etcetera. A small part of that (in my GIFs) would be attributable to whatever SAVIHost used. (Too lazy to check the exact details but it seems like a plausible scenario.)


At any rate, its higher than it needs to be. There is no doubt in my mind that this could be optimized quite a bit, and this goes for diskspace usage as well. (There is absolutely no good reason why 157MB worth of images should take up 183MB of diskspace.) A good start would be to use image strips for animations rather than a single image for each frame multiplied by the amount of available UI sizes. (Which is whats causing all the wasted space.) With 'convert' and a 1-line terminal command you can stitch a whole folder full of single images in under 1 second, and with a second line (just make a .cmd file for repeated use) you can even have the resulting image strip moved to the desired location automatically, still in under 1 second. So its practically no extra work/time, but the gain would be significant, especially considering that we are not only talking about one plugin, but many. (And some of them are way bigger than the DX7 V, the CMI for instance has a resources folder more than twice as large and a presets folder more than 6 times as large.)

The next step would be to make one hi-res 'master UI' (i.e. the 100%-size UI) and then simply scale that down on-the-fly for the smaller sizes. (This has been proven to work very well if done right.) To still have the sharpest-possible text for labels and stuff just generate it during runtime rather than baking it into the images. That way it wont be a problem even if one of the smaller UI sizes is being used on a bigger screen since the text will be rendered at its original size with full anti-aliasing rather than being shrunk with the images and thus suffer from unsightly blurring.

With these 2 things taken care of, both RAM usage and diskspace usage would be but a fraction of what it is now.

[chk071]

I'd be quite surprised if they didn't already know all of that though.

[fmr]

I'd be quite surprised if they didn't already know all of that though.

If this is the biggest complaint about VC6, then things are going really well

But even this isn't true: "DX7 V, circa 245MB per instance. A gig of RAM gives you ~ 4 instances". Did you REALLY measured how much RAM 4 instances would demand? Or did you just multiply by 4?

Here are the readouts I obtained in REAPER:

Empty project: 329 Mb of RAM
With 1 DX7 V instance: 535 Mb of RAM (+ 206 Mb)
With 2 DX7 V instances: 698 Mb of RAM (184 per instance)
With 4 DX7 V instances: 1020 Mb of RAM (172 per instance)
With 8 DX7 V instances: 1653 Mb of RAM (165 per instance)

So, the growing is not linear. The more instances you add, the less RAM per instance it demands.

Anyone can check this - Just download and install REAPER, and load instances of DX7 V one by one.

[The Sarge!]

holy sh!t
44 (!) pages about V-Coll.6 but only Ingo made a mp3 to show a little bit of it (more byte of Retro-5... )

you all can this do better, I think and remember

do you all have the same problems as me:
1.) unsure to pay $199 for V4 -> V6 upgrade
2.) whole weekend moving snow and snow and snow and "rests of dogs pleasure" and snow from the sidewalk

hope to hear some little things, snipets are welcome to

and a little easteregg here:
https://www.reddit.com/r/edmproduction/ ... turias_v6/

regards,
The Sarge!

[ghettosynth]

I am not interested in any recommendations about programs and books that you have never read. Also there is no need for a meta discussion about science theory or objectivity (let the philosophs do that...).

That's clear, you've demonstrated soundly your disinterest in any knowledge of the subject. As far as what there is a "need for", you objected to my clear statement about objectivity with some nonsense. That's the ONLY thing that we've been discussing.

As you didn't provide any answer to the question (no suprise...), we're surely done with this.

I most certainly did, it is just outside of your ability to understand the answer. I'm quite sure, however, that nobody will miss your insightful commentary, so, by all means, please feel free to be done this.

[Ingonator]

I'd be quite surprised if they didn't already know all of that though.

If this is the biggest complaint about VC6, then things are going really well

But even this isn't true: "DX7 V, circa 245MB per instance. A gig of RAM gives you ~ 4 instances". Did you REALLY measured how much RAM 4 instances would demand? Or did you just multiply by 4?

Here are the readouts I obtained in REAPER:

Empty project: 329 Mb of RAM
With 1 DX7 V instance: 535 Mb of RAM (+ 206 Mb)
With 2 DX7 V instances: 698 Mb of RAM (184 per instance)
With 4 DX7 V instances: 1020 Mb of RAM (172 per instance)
With 8 DX7 V instances: 1653 Mb of RAM (165 per instance)

So, the growing is not linear. The more instances you add, the less RAM per instance it demands.

Anyone can check this - Just download and install REAPER, and load instances of DX7 V one by one.

As i mentioned in my post above the RAM use with muliple instances is much less here if the GUis are closed (with 10 instances an average between around 80 to 100 MB).

[ghettosynth]

I don't know what's going on there but there are gaping differences in the bass response.

Youtube will certainly compress and change the sound. Its more an instruction how to do a comparison.
Its also not quite clear, if he used the same DX 7 as MIDI controller, and just recorded the same hit he was playing (but I guess so). The next test would be to normalize levels and subtract a phase reversed version from each other in an audio editor. Then listen to the residium...
The difference in beating frequencies shows a clear error in interpreting the parameters correctly. There must be something fundamentally wrong. Its probably hard to get the exact envelope curves, but that would not explain differences in beating...

That's what I just said, no. I don't see much value in taking it further.

[jme-audio]

you've demonstrated soundly your disinterest in any knowledge of the subject.

What knowledge? You have no knowledge at all, but propose that people should absolve some months/years of DSP training to continue discussion...

Googling up an add-on document of Reaktor (that you even didn't read) is no argument.
It's quite the same as pointing to some physics reference book.

Btw. the document just shows some circuits and their transfer functions, nothing special.

I most certainly did, it is just outside of your ability to understand the answer.

Your game, playing the nerd doesn't work.
Everything can be expressed in a way that is understandable.

But there is one fundamental problem: It is not possible to mathematically prove the accuracy of these emulations.

Asking for an answer was just rhetorical because of your steep claim.

[ENV1]

ENV1

Please send this report to Arturia, ENV1, to show them that product optimisation is very important for their customers.

They know this.

Did you REALLY measured how much RAM 4 instances would demand?

No, of course not, i just consulted my crystal ball.

(I think you know me well enough to know that if i had just been guessing or assuming i wouldnt have stated it as a fact. I have posted 2 GIFs in that post showing the launching of 3 standalone instances of DX7 V and FM7 so go and see. The post is on page 21.)

[beely]

What knowledge? You have no knowledge at all

Oh for goodness sake, enough already. You don't agree, that's fine. Neither of you are going to change their views, so continuous posts on this are just creating more pointless noise that's distracting us from important moaning about upgrade pricing...