Enter Value Automation Point Bug - Ableton 10

Unsure if this issue is being caused by Ableton or Vital but since it is working perfectly fine in other VST3 synths (Checked with U-He Diva) I suspect it is Vital.

I went to create an automation curve on the LFO rate in seconds mode. Since I wanted the rate to smoothly transition from 1/4 note to 1/8th Triplet I figured I would just right click on the second point and “enter value” for the second automation point to create my curve. Although this seems to be glitching and no matter what value I enter it just automatically jumps to the top point. I then was wondering if the issue was only limited to LFO speed and tried it on attack time on my env and same issue. As a test I just entered 1 and it jumps to 32.0003 secs. I even tried entering it as “1 secs” with it still jumping right to 32.0003 secs.

Furthermore I tried this on multiple other parameters such as wavetable frame, Mix Knob on effects etc. It seems only parameters that have a range of 0% to 100% work as intended (i.e Mix knob on chorus effect for example) but if the knob has the ability to be a negative % then you have to adjust for that as entering 50% gives a value of 0% in the synth and is what is read out on the value in my DAW. All other values though like wavetable frame, Db value on compressors etc. just automatically jump to 100% of the value no matter the value I enter.

I double checked this in fresh projects, ensured I was using the VST3 version of the plugin. I am running Ableton Live 10.1.41 (latest version of Live 10), and Vital is running V1.07. I was unable to find any posts on this forum reporting this issue so maybe it is just a bug occuring on my system

I’m not ENTIRELY clear on what you’re doing here but have you tried decimals? I believe some parameters take values from 0-1 so you’d need to enter, say, 0.63 - a value of 1 or greater would skip to the maximum.

Well it seems decimels actually do work but only for some parameters. But this also confirms there is a bug within vital because this is not how VST3 is suppose to work (well at least they added the feature to make it so it doesn’t have to work this way anymore). One of the benefits of VST3 is that the values are translatable directly as 1:1 with the synth and Daw in doing automation instead of some arbitrary value between 0-1.

Here are some screenshots to show you what I am describing in the following paragraphs. (Note you may need to download them, they show up rather small and hard to read on Imgur, but if downloaded the photo is very readable) - Turns out I can’t post more than two links per post, so I will make a couple extra posts with the links spread between them lol

Where it seems to work:
I will try and explain the problem better. When using VST3 plugins one of the benefits is the DAW is able to communicate exact parameter values allowing for better control when doing automation. This is unlike VST2 where the value is 0-1 and the value is represent by say 0.55 in the DAW automation point and the wavetable fram it reads out in Vital will be 140.8 . Now if you repeate this in Vital running the VST3 version instead of VST2 you will notice the Values for wavetable position in the Daw no longer read out as 0-1 on the timeline. You can create a point and drag it up and down and the readout will now be from 0-256.

Now if within vital you right click on Wavetable fram so you can enter a direct value and set it to 140.8 and go to the automation lane on Ableton’s timeline the value of the point it will show if you double click on the dotted red line will be 140.8. Now if you right click that point and select “enter value” it will allow you type in a number and the number that will be in its place is 140.8. Now if I don’t change the value and just hit enter it jumps right to 256. Now I did test what you suggested and tried a decimal place of between 0-1 and in this case did that with a value of 0.55 which set the wavetable frame to 140.8 .

The major reason I see this as a bug / problem now is even though I can just enter decimal points if I am using the VST3 version and want to automate between 2 fairly specific points, say for example 2 wavetable frames I can’t just find what the corresponding automation value is for the 2 points by just setting it in vital first, checking what the first point equals as a decimal point by checking what the value read out is on the DAW timeline and then what the value is for the second. Instead now it’ll only keep showing me what the value readout is on the synth and I have to jus keep guessing and checking till i get a close enough approximation. The workflow in this regard is actually a step down from the VST2 version of the plugin and just makes the process more tedious. This method works fine in the VST2 method and, typically thats how I work in serum if I am modulating say the LFO rate or Wavetable frame position.

I just want to note that I know this is entirely possible with VST3 synths and plugins in general as I use this feature across many different programs such as Diva. There I can click on the filter and go to modulate it in the timeline and enter a value of say 125 and it will go to the point of 125 in the synth since the filter has a range readout of 150-30 for the VCF Ladder filter. It really is a timesaver and workflow improvement because say I am using a filter plugin like Volcano 3 by Fabfilter and I want the LP filter to open slowly I can create two points, Enter 250hz as a rough guess of where I will want it to start and then enter 22000 for where I want it to finish. Sure I may need to change the lower value later but when just trying to get my ideas down when in a more creative workflow it can be handy to create more complex modulation than what I just described fast and have it sound fairly accurate. It takes the guess and check, then adjust and check again aspect out of the equation.

Where Decimal places of 0-1 do not seem to work:
Now If I go to automate the LFO time and I set it to seconds it does not seem that any value works. It is either set to one extreme or the next. This is especially frustrating since the LFO speed is between 0.001 Seconds and 128 with 3 decimal point accuracy all the way up to 128. So trying to drag a point to 1.250 seconds is extremely tedious for example and there is no way to even enter an approx. value that would just get me close enough. It may seem I am heavily focused on getting exact numbers, while it would be nice this is more or less just a workflow issue where it’s a pain just to get things in the right ballpark. It seems that if I enter a value of 1 or larger it defaults to the longest time possible at 128 seconds and if its 0.99 to 0 it defaults to the fastest time possible of 0.001 (at least according to the readout in Vital, although the read out actually says “0.00195312 secs” in the daw timeline). I’ll link some screenshots below. (As noted above, you will find the screenshots in a post below)

There you can more clearly see how it is just not functional at all. Now If I do this in the VST2 version it works as expect, 0.5 = 0.500 Seconds, 0.25 = 0.031 seconds, 0.25 = 8 seconds. Now this range of values means there is a massive amont of jumping between values making it not that useful in reality but it works as it should and all other VST2 plugins with an LFO suffer from this exact issue. In the VST3 version it is just simply broken.

I have noticed other inconsistencies across Vital in the way values are to be entered to get a corresponding value in the synth, which leads me to believe this is a bug. For example on the mix knob of the chorus effect I can simply enter 45 and dont have to enter 0.45 to get 45% mix. Meanwhile another % based parameter that allows for -100% to +100% must be entered as 0.5 for 0% meaning each 0.01 is stepping 2% each time. It is just overall inconsistent in the way you should be entering values to set modulation points across the entire synth which is frustrating when I am trying to focus on making music and not how to enter in values in my synth to get the values I already know I want.

side note:
From the bit I have read on the subject when it comes to programming VST3 plugins to allow modulation for parameters it can be harder/ more tedious to implement so some companies get around this hurdle with synths specifically by supplying 8-16 macro knobs that are just 0-100 values (with some allowing up to 2 decimal places to allow for finer control) and you must assign a macro to anything you want to modulate. I am not a fan of this system but I know PhasePlant, and NI’s Massive utilize method as with synths it is possible to have an extremely higher amount of parameters that are available to be modulated vs say a Distorition plugin. So I do understand if Matt hasn’t be able to implement this fully and maybe he is aware of this issue. I just saw zero posts on this bug with the VST3 version and wanted to see if it was possibly this issue is happening only on my system or if this issue was being seen across the board.

Vital is an awesome synth and in all honesty this feature if fixed would make this the most useful synth in my relatively small library of synths lol

First Set of Screenshots:

Second Set of Screenshots:

There’s a lot to take in here!
I think it’s a slight misuse of the word to label this problem a “bug.” “Bug” implies that the designer/programmer intended it to function differently but a mistake in the coding is altering the desired behaviour. I suspect, as you’ve pointed out, that this is a very definite inconsistency across Vital but that M Tytel made decisions about which parameters would be adjusted in what divisions.
Having said all that, I suspect that the problem is in fact a difficulty in Ableton communicating with Vital. I’ve never used Ableton myself (or VST3s - I’m on Mac) but I see a LOT of posts on this forum about people having trouble with these two packages working together.
Will Ableton record automation on the fly? Perhaps you could manually automate Vital and record it in Ableton, then see what sort of values Ableton is receiving to get an idea of how it might work back the other way? I have no idea if this is helpful.
I agree it’s not efficient but I think you might be left to your trial and error method… maybe keep a calculator and a notepad handy!

Well the reason I am being so thorough here is because if M Tytel didn’t intend for it to work this way then he can have as much information as possible about it to hopefully make it easier to fix. If its not a bug then I suggest addressing this at some point as it would be very helpful and a greatly appreaciated update. I just find it hard to imagine though that the intended design for adjust the LFO timing through automation points in the DAW was to set my mouse sensativity to basically as low as possible with the alternative of just typing in a value (even on a scale of 0-1) just broken. It’s also the only parameter I can find where that is just completely broken. If they all worked just 0-1 then I’d agree this is most likely a design choice and that is perfectly acceptable. Its the fact that its inconsistent across the synth with some of it just completely broken that leads me to think its a bug. When attempting to automate that same parameter in the older VST2 version of the plugin everything works exactly as expected. It is a value between 0-1 and each 0.01 is a predfined step. Thats exactly how VTS2 was designed though, so the question is why doesnt it work at all in the VST3 verison on that same parameter? If thats not a bug idk what is. I also have a bit more faith that M Tytel wouldn’t design his synth to operate like this, its an incredible peice of software that is very logical across the board and simply put one of the best soft synths on the market. It simply wouldnt make sense that anyone that has made this incredible of a synth would get to the automation portion of it and say to themself “you know what this needs, a whole lot of inconsistency when it comes to modulating parameters within the daw.”

Now like I said at the very start of the first post, I am unsure if this is more of an ableton problem or a vital one. Maybe the automation works perfect on other DAW’s, but considering this issue only occurs with vital, none of my other VST3 plugins are experincing this issue, and the automation for every single one of those VST3 plugins is a 1:1 representation of what is seen in the plugin leads me to think overall this is a bug on Vitals end.

If anyone else is working on another DAW (even Live 11) that supports VST3 I’d love to hear if this is working for you or not. This could very well be an issue with my version of Live.

Side note: I saw a post from Steve @ Xfer some time ago explaining why he hasn’t released a VST3 version of serum yet and one of the points he actually noted is how implementing automation in VST3 is more of a pain to get working right, and that is especially true for synths because of this feature. Synths inherintly will have a very high amount of automatable parameters. Thats why a lot of newer synths skip it and now just do increased number of mod knobs within the synth and only making those automatable within the DAW.

I am so very sorry: I appear to have angered you further which was most certainly not my intention!

I don’t want to offer any more unhelpful comments: I’m very sorry that your ability to enter automation point values to adjust LFO timing is broken and I sincerely hope Matt or someone else is able to help.

Oh you have not angered me one bit, I am sorry if I have come off that way at all. You were actually helpful in helping me figure out how certain parameters are still based in a 0-1 system. Didn’t solve the entire issue but helpful nonetheless. So for that I am thankful! Discussion and offering of ones advice is all we can do here, sometimes it solves it & other times it does not. All I mean’t to do was further explain and hopefully figure out what was going on. If it is indeed a bug then Matt can know and hopefully one day address it, if it is not a bug then it’s a me problem (or rather Ableton Live 10 one haha).

Anyways I love this synth and just want to help improve it further by pointing out any odd behaviour. In the meantime I will just use the VST2 version as that runs flawlessly. It is also the only time I have ever seen any issue with Vital which is honestly really impressive imo. I only recently decided to update the synth and started playing around with the VST3 version which the previous version I had installed didn’t have. Honestly think it was like version 1.03 I had installed? idk can’t remember at this point. It worked, so didn’t update for a while.