Why do you dislike Arturia VSTs?

[Funkybot's Evil Twin]

I'm Edouard, V Collection & Pigments product manager .
A bit surprised by the poll, not much room for love, but I guess it's fine like this.
At least I can expect to find some relevant criticism maybe? So I jumped in to check if some useful information could be gathered to continue improving our instruments and utilities.

Thanks to those who wrote constructive remarks, I'm taking good notes.

Hi Edouard,

I agree with the general sentiment that the Arturia VST's on the whole are very bloated. I'll be specific about why in the hopes that it will help drive some improvement.

You've got way too many images for most VSTi's. Why does every single key on a keyboard need it's own image? Then multiple that across all the different sizes! It can't be efficient to have to load all those resources. And for what gain? Why not just create a 200% set of graphics and scale those down? It would at least save some hard drive space. System drives are frequently SSD's and not as big as a sample library drive. I appreciated that the SQ-80 had a synth tab that ditched the Skeuomorphic GUI, but that was really the only page necessary IMO. Or if you're going to keep the fancy graphics to attract new users, at least be more efficient about the HD space requirements and figure out a better way to do that.

Let's also talk about plugin scanning. After an Arturia round of updates, I have to let Reaper start up, scan the plugins, then walk away because it will take so long. Reaper will inevitably warn me that Analog Lab V got hung up and ask me if I want to terminate, but I have to just let it wait, it will eventually work. Happens with a few others. What is going on with that? Why does this only happen with Arturia plugins?

On a similar note, Arturia plugins also have WAY TOO MANY VST automation parameters. You ever open the automation list? It's insane! Why does a Dimension D chorus plugin require over 2,100 VST automation parameters? All the Arturia FX plugins have about this many, no matter how small the plugin. We don't need literally thousands of MPE and MIDI helper parameters exposed to the DAW. That's crazy. Arturia is the only developer that does this.

And the result of all of this, is that when I load up an Arturia plugin, I'm frequently waiting 20 seconds for the GUI to open and the plugin to be operational. As an end-user, it creates a Pavlovian response: "don't do load those plugins." So I'll frequently start with NI's Phasis over the Arturia Bi-Phase because well, even though the latter may sound better, if I need to work quick, I avoid Arturia plugins because they're slow.

I really hope Arturia begins to operate more lean and focuses on performance by creating more efficient plugins. And I don't mean CPU use! If increasing the CPU use made things sound better, I'd be all for it. When I mean efficient I mean fast to open, fast to scan, no unnecessary automation parameters, no wasted hard drive space with graphic resources I'll never use, etc.

[MrJubbly]

The thing which both frustrated and infuriated me the most regarding Arturia's plugins is the unnecessary 'lag/delay' after the plugin first instantiates in the DAW before being fully authorised for use by the ASC (i.e. the background ASC process that is launched every time an Arturia plugin is loaded.) Since all my other plugins load lightning fast with zero delays (and no additional background processes required), the ASC lag for Arturia plugins was extremely noticeable and infuriating to me.

Yep, this sucks. Pigments, for example, takes about 10+ seconds to load upon first instance for me. It's not just the license check either. Additional instances are slow too. A second instance of pigments typically takes around 4 seconds to load. If I had one complaint for Arturia, it would be these painful load times.

Exactly the same for me. The initial Arturia plugin instance takes around 10+ seconds (after loading) to get the 'okay' from ASC to operate, and any subsequent Arturia plugin instances take around 3 to 6 seconds ~ since 'ol lazybones 'ASC' is already launched and lurking in the background by then. And if it's not 'only' licence check-related, then it's definitely something else ASC-related from my tests.

What's insane with the first Arturia instance, is that you can clearly see the plugin has already loaded within the DAW wrapper after just a few seconds, but then then it 'locks' itself up, while it launches the ASC to "ask mommy for permission to play" ... Honestly, I've sat there with the DAW and Task Manager side-by-side, and so it's obvious to witness what's going on (and hella annoying as a paying customer).

It only rubs salt in the wounds even more, once you realise that we paid for such a substandard user experiences, while other 'less-scrupulous' (i.e. 'non-customer') users side-step such issues so don't suffer these unnecessary 'lagging issues'. Which begs the question: "who are Arturia really punishing here?" Since, it is only their legit customers (who they are forcing to endure such loading performance lagging), while those other scallywags (who presumably, such processes were 'supposed' to prevent), manage to circumvent this (and so don't suffer such issues?) How is that fair? It's nuts!

I once made the mistake of including around a dozen or more Arturia plugins within the same project (of both Pigments and V Collection variety). Upon subsequent reloading of the project, I was like: "You've got to be bloody kidding me!", sitting and waiting the extra 'time penalty' for each Arturia plugin to get its 'permission' to unfreeze from the ASC. Meanwhile, all my other included plugins from other developers, were just whizzing by loading in with zero issues. I honestly think it was during one of these sessions where I finally decided, "Nah! ... Enough is enough ... Arturia has got to go, bruh!"

I've now successfully sold my V Collection 8 licence and am working on selling the rest also.

[MrJubbly]

Let's also talk about plugin scanning. After an Arturia round of updates, I have to let Reaper start up, scan the plugins, then walk away because it will take so long. Reaper will inevitably warn me that Analog Lab V got hung up and ask me if I want to terminate, but I have to just let it wait, it will eventually work. Happens with a few others. What is going on with that? Why does this only happen with Arturia plugins?

Yup! The plugin scanning of Arturia V Collection (and Pigments) is likewise 'interminably long' within Studio One, FL Studio, Ableton Live, Cakewalk, Renoise and seemingly any other DAW we could probably mention.

And the result of all of this, is that when I load up an Arturia plugin, I'm frequently waiting 20 seconds for the GUI to open and the plugin to be operational. As an end-user, it creates a Pavlovian response: "don't do load those plugins." So I'll frequently start with NI's Phasis over the Arturia Bi-Phase because well, even though the latter may sound better, if I need to work quick, I avoid Arturia plugins because they're slow.

Exactly this! You'll be in a project about to open a plugin, but then you'll question the choice (thinking do I really want to endure additional 'time penalties' in future for this project by using Arturia? Then upon reflection, I invariably decide to go with another more user-friendly option instead. The "Pavlovian response" is the perfect description of this phenomenon.

[Aloysius]

Takes forever to load any Arturia Plugin on my system (Windows 10). Support assured me a long, long time ago that this was related to preset handling and that this would be fixed sometime. I can't use any of these plugins. It's much easier to use something else than go through the waiting game every time. Some of the plugins I'd love to use because they really do sound good. Arturia have come a long way over the years.

[Vortifex]

Edited

[chk071]

Yeah, on many of the plugins which take longer to load, it's only the first instance which does. After that, it's pretty quickly. Apart from Massive X, which always takes a bit longer to load, even when switching tracks. Although that also seems to be DAW dependant. On Reaper, it takes less time.

[davidka]

Hello.
I'm Edouard, V Collection & Pigments product manager .
A bit surprised by the poll, not much room for love, but I guess it's fine like this.
At least I can expect to find some relevant criticism maybe? So I jumped in to check if some useful information could be gathered to continue improving our instruments and utilities.

Thanks to those who wrote constructive remarks, I'm taking good notes.

For the more vague remarks, I can't really help if someone says it sounds bad... As I don't know which instrument you are talking about, or even which parameters.

If you like wanting to share, feel free to refine your sayings if you have a precise idea of what you feel is wrong. If it's about the sound, are talking about the newer instruments or the old ones? (note that there are 15 years since our first emulations and the most recent onces, thus the fact that we are updating the instruments as much as we can since 2019.
Do you have precise parameters on which you think it's not on the point?
Did you compare to the original machines or is it simply a guess?
Feel free to let me know
Best
Edouard

Hi Edouard,
generally speaking, everyone would benefit from a boost to the GUI performance, I also experience this. I don't know the scale of work needed for improvements, or a complete redesign.

Much work has been done at Arturia on these interfaces, and it's good to look at them. However sometimes it's better to just focus on the sound and use a simpler UI.

What are your thoughts on this?
Do you see it viable to offer a performance-oriented (non-skeumorphic) GUI as an option for users?

[Edouard Arturia]

Hello everyone,

Thanks to those who took the time to be specific, this is helpful and appreciated.

2. To my ears, most Arturia VA synths don't have enough "oomph" compared to other vendors. The benchmark is quite high, of course, but when I've A/B'ed, say, SEM-V and Oberhausen, I find the difference pronounced. So too with most other pairs, most recently the Matrix-V against Obsession... [wince] That was a stark contrast.

To soften the blow, though, someone here on KvR challenged me to A/B Jupiter-V to Roland Cloud's Jupiter-8, and Arturia actually came out ahead, to my ears. C'est manifique. Also, I do really find the digital emulations to be quite good. I'm especially enamored with SQ80-V, myself. OTOH, I do think Chiptunes OPS7 is a "better-sounding" emulation of the DX7. ...I still think DX7-V is ... good. . Okay, sorry: there are a lot of synths, it's complicated.

This is understandable, the first examples you quoted are emulation that start to age now.
Nowadays the CPU processing and our DSP expertise evolved which makes us able to provide totally different levels of accuracy.

This is why we are now reworking our old emulations to make them up to nowadays CPUs and expectations. Jup-8 V4 was the first of the series, and more will come next in the future.

MrJubbly wrote: ↑Tue Jan 18, 2022 12:16 am
The thing which both frustrated and infuriated me the most regarding Arturia's plugins is the unnecessary 'lag/delay' after the plugin first instantiates in the DAW before being fully authorised for use by the ASC (i.e. the background ASC process that is launched every time an Arturia plugin is loaded.) Since all my other plugins load lightning fast with zero delays (and no additional background processes required), the ASC lag for Arturia plugins was extremely noticeable and infuriating to me.

Ok, I understand that this is a big source of frustration for a lot people here.
This rather surprising we don't receive much complaints about this at the tech support...
I guess this time can be variable for various reasons, and is maybe not enough of a pain to trigger support tickets, but I take good note about this. I will throw this topic in the pipeline as soon as possible. Thank you

generally speaking, everyone would benefit from a boost to the GUI performance, I also experience this. I don't know the scale of work needed for improvements, or a complete redesign.

Yes, this is not an easy topic, but this is definitely something we have in our scope.
I know this can be a problem for people with weak GPU processing, for example with computers using small graphic chipsets.

Much work has been done at Arturia on these interfaces, and it's good to look at them. However sometimes it's better to just focus on the sound and use a simpler UI.
What are your thoughts on this?
Do you see it viable to offer a performance-oriented (non-skeumorphic) GUI as an option for users?

Talking about recreations of existing instruments, simplified views is a choice I made for SQ80 V because the original interface was not really suited for mouse+KBD usage. The result is pretty satisfying indeed.
This approach for other products is not excluded and can make a lot of sense depending on the nature of the instrument. But it would not replace the original instrument 3D, as we pay a lot of importance to the feel of the original machine. Is there any particular instrument you'd like to see with a software view?

Thank you again for your feedback,

Edouard

[davidka]

Thanks for the quick reply.
Outside SQ80, I use OBX-D, Jun-6V, and the FX Collection most of the time. But that changes by season.
There's no particular 'need', of a different UI, I was just thinking loud if such option would reduce the resource overhead.

I have a Vega GPU, would a video card improve this situation?

[J Veronica]

Arturia plugins load great for me, just a few seconds and I'm in.

The Jun6v sounds identical to the Juno 60 I used to own, and the Jup8V4 is one of the best I've ever heard. I barely want to use the Roland Cloud versions now.

If you are collecting feedback, all I can add is I am looking forward to more updated plugins, the voice dispersion feature is wonderful, and I hope you make a JX-8P

[Examigan]

Nowadays the CPU processing and our DSP expertise evolved which makes us able to provide totally different levels of accuracy.
This is why we are now reworking our old emulations to make them up to nowadays CPUs and expectations. Jup-8 V4 was the first of the series, and more will come next in the future.

Any hints as to which one will be next in line?

[BezO]

I don't dislike Arturia VSTs, but the presets are mostly useless to me. But that's most instruments.

[xbow]

Talking about recreations of existing instruments, simplified views is a choice I made for SQ80 V because the original interface was not really suited for mouse+KBD usage. The result is pretty satisfying indeed.
This approach for other products is not excluded and can make a lot of sense depending on the nature of the instrument. But it would not replace the original instrument 3D, as we pay a lot of importance to the feel of the original machine. Is there any particular instrument you'd like to see with a software view?

It's a really nice surprise to see this constructive discussion in a thread I had largely ignored because I didn't like its hostile premise.

Regarding simplified interfaces, I'd like to add a thought: I really dislike having to scroll to see the whole plugin. With almost any synth (except the Jupiter and Juno), as soon as I open the advanced options, it gets too tall to fit into the window, so either the top part or bottom part is cut off. On the other hand, I don't need to see a visual representation of the synth's keyboard at all. So it would be awesome if you could implement an option to hide it, saving screen real estate and giving the plugin a much more focused appearance.

The SQ80 synthesis view is excellent in this regard. Hiding the keyboard of the CZ and DX7 would achieve a similar result, as they already have "digital" interfaces.

On the analog synths, a "compact" view that gets rid of the keyboard and rearranges some controls, if necessary, might be practical alternative to a full blown digital reinvention of the UI.

Regarding the Emulator II, you could get rid of the screen outline (I would much prefer the main controls to be larger at the same window size rather than sacrificing screen real estate for something purely ornamental).

[aMUSEd]

Talking about recreations of existing instruments, simplified views is a choice I made for SQ80 V because the original interface was not really suited for mouse+KBD usage. The result is pretty satisfying indeed.
This approach for other products is not excluded and can make a lot of sense depending on the nature of the instrument. But it would not replace the original instrument 3D, as we pay a lot of importance to the feel of the original machine. Is there any particular instrument you'd like to see with a software view?

It's a really nice surprise to see this constructive discussion in a thread I had largely ignored because I didn't like its hostile premise.

Regarding simplified interfaces, I'd like to add a thought: I really dislike having to scroll to see the whole plugin. With almost any synth (except the Jupiter and Juno), as soon as I open the advanced options, it gets too tall to fit into the window, so either the top part or bottom part is cut off. On the other hand, I don't need to see a visual representation of the synth's keyboard at all. So it would be awesome if you could implement an option to hide it, saving screen real estate and giving the plugin a much more focused appearance.

The SQ80 synthesis view is excellent in this regard. Hiding the keyboard of the CZ and DX7 would achieve a similar result, as they already have "digital" interfaces.

On the analog synths, a "compact" view that gets rid of the keyboard and rearranges some controls, if necessary, might be practical alternative to a full blown digital reinvention of the UI.

Regarding the Emulator II, you could get rid of the screen outline (I would much prefer the main controls to be larger at the same window size rather than sacrificing screen real estate for something purely ornamental).

Yes an option to hide the keyboard (which serves no purpose for me personally) would be great

[sQeetz]

Yes an option to hide the keyboard (which serves no purpose for me personally) would be great

First thing I do if the plugin offers the option to. I have a keyboard right in front of me. No need to have one displayed on the plugin.
One of the worst offenders is Softube's Model 72.. it takes up half of the whole interface. Luckily one can hide it and the setting gets stored globally for the plugin.