Waldorf Largo + PPG Wave 3.V + Waldorf Edition: 64-bit/VST3/AAX updates

[c_voltage]

Ok. About 1.0.5. The first thing which i paid attention this is slightly more slowly knobs response (than in 1.0.2), and then noticed that during turning knobs the numeric value of the changing parameters reflected in Studio One with a significant delay (in plugin current parameter window), here



But the fact is that in 1.0.2 this problem does not exist, there is no feeling of slowness, and numeric data in Studio one is reflected perfectly (simultaneously with turning the knob).

Why am I so worried about it - All other problems simply fade after this, because it is a general feeling during work with plugin (but it very good plugin, on which i was a lot of hope).
And the worst thing that this problem, as opposed to specific bugs, can simply be ignored as insignificant.

This is what that can say as the "bad optimization".
And I beg you to pay attention to it, the more so because v102 is a fine indicative example, and find the reason will be much easier (and there is also above-mentioned certain symptom in Studio one).

Win7 64bit, DAWs 32bit VST2

[EvilDragon]

IMHO, you should tweak with your ears, not eyes looking at numbers. Speed of parameter value refresh is not nearly important as the actual sound coming out. Besides, you have the same parameter value readout on the plugin GUI itself - and it's snappy and fast there!

[Ingonator]

I admit that while on Windows 7 64-bit i got 8 hosts/DAWs for testing at the moment (Cubase Pro 8, Cubase 7.5, Live 9, Studio One 2.6, Reaper 4, Bitwig Studio, Pro Tools 10 and Pro Tools 11) i am using Cubase 8 and Live 9 most of the time while i use Studio One mostkly for testing purposes. Will re-check PPG Wave 3.V in Studio One ASAP.

Anyway for Studio One 2.6 i currently only got the 64-bit version installed. For "pure" 32-bit testing at the moment o only use Cubase 7.5.40 32-bit and Live 9.1.7 32-bit (and sometimes the bridge in Cubase Pro 8.0.10 64-bit and reaper 4.77 64-bit).

--------------------------------------------------------------

I found that sometime it is easy to get "lost" with testing in different hosts and plugin formats while it is possible to miss certain details (and sometimes also bugs...) in certain hosts.
This seemed to be much simpler in times where at Windows we only had 32-bit VST2 plugins and i had only 2 hosts...
Including both Windows and OSX for a single product like PPG Wave 3.V we currently have 14 plugin formats that have to be checked (opposing to 3 in the past when we had 32-bit VST2/AU only).

[c_voltage]

Anyway for Studio One 2.6 i currently only got the 64-bit version installed. For "pure" 32-bit testing at the moment o only use Cubase 7.5.40 32-bit and Live 9.1.7 32-bit (and sometimes the bridge in Cubase Pro 8.0.10 64-bit and reaper 4.77 64-bit).

Need re-check exactly in Studio One, to reproduce this.

IMHO, you should tweak with your ears, not eyes looking at numbers.

Evil sorry i do not think so, let it be a pleasure to work with synth.

Clarify - I admit that feeling while turning the knob in v105 almost no differs from v102, is very little difference. But cumulatively with behavior in Studio One about which I have said and considering the fact that in 1.0.2 this does not occur - it is quite a issue, quite specific and detectable.

[c_voltage]

Will re-check PPG Wave 3.V in Studio One ASAP.

Thanks. Try it even if only in 64-bit (if you can not 32), but with VST2, May be able to reproduce.

I just think (suppose) that this issue who successfully defined in Studio One after his improve is add optimizes the overall.
Damn, well, if in the previous version this was not, then why there is now? (Is that not enough?)

[EvilDragon]

IMHO, you should tweak with your ears, not eyes looking at numbers.

Evil sorry i do not think so, let it be a pleasure to work with synth.

Clarify - I admit that feeling while turning the knob in v105 almost no differs from v102, is very little difference. But cumulatively with behavior in Studio One about which I have said and considering the fact that in 1.0.2 this does not occur - it is quite a issue, quite specific and detectable.

So, you completely disregard the fact that the parameter display on the plugin GUI itself is working fine and snappy and you can use it for exactly what you want?

[c_voltage]

IMHO, you should tweak with your ears, not eyes looking at numbers.

Evil sorry i do not think so, let it be a pleasure to work with synth.

Clarify - I admit that feeling while turning the knob in v105 almost no differs from v102, is very little difference. But cumulatively with behavior in Studio One about which I have said and considering the fact that in 1.0.2 this does not occur - it is quite a issue, quite specific and detectable.

So, you completely disregard the fact that the parameter display on the plugin GUI itself is working fine and snappy and you can use it for exactly what you want?

No, I'm not entirely disregard this, and i can understand your confusion, but for me, the described symptom (behavior) there is a probably mark of overall plugin engine condition. And I admit that in the process of trying to fix it, developer will be able to improve some other possible problems (which I have not yet mentioned, but which also were not in 1.0.2, the same as this issue).

Well, and secondly, yes - for me important moment of displaiyng numerical data by realtime via host (even if it is implemented in the plugin), it is very convenient, incl. indirectly for work with automation.

[EvilDragon]

but for me, the described symptom (behavior) there is a probably mark of overall plugin engine condition.

And you're entirely wrong if you judge plugins just by that.

[Ingonator]

Ok. About 1.0.5. The first thing which i paid attention this is slightly more slowly knobs response (than in 1.0.2), and then noticed that during turning knobs the numeric value of the changing parameters reflected in Studio One with a significant delay (in plugin current parameter window), here



But the fact is that in 1.0.2 this problem does not exist, there is no feeling of slowness, and numeric data in Studio one is reflected perfectly (simultaneously with turning the knob).

Why am I so worried about it - All other problems simply fade after this, because it is a general feeling during work with plugin (but it very good plugin, on which i was a lot of hope).
And the worst thing that this problem, as opposed to specific bugs, can simply be ignored as insignificant.

This is what that can say as the "bad optimization".
And I beg you to pay attention to it, the more so because v102 is a fine indicative example, and find the reason will be much easier (and there is also above-mentioned certain symptom in Studio one).

Win7 64bit, DAWs 32bit VST2

Just checked with the 64-bit VST2 in Studio One 2.6.5 64-bit. I confim a small delay at the display in Studio One when using one of the knobs in the GUi of the plugin. Anyway the display it the GUi of the plugin show the values without any delay. This is what i normally used for progrmming patches (where the amount of my own pathes is close to 300 at the moment...).

I also checked in Live 91.7 64-bit and opened some parameters at the device panel (with the "Configure" button. This adds the parameter value and a fader to teh Live device panel. While turning a knob in the GUI there also seems to be s small delay in teh value at that device panel. If i move the fader at the device panel ther are no more delays. Still the display directly at the plugin GUI does not seem to have that delay.

This is indeed something that could be easily overlooked as first not every host a a built-in display of the values like Studio One has and second most people (including myself) do usually look at the display in the plugin GUI while programming.
Usually i also create patches with adjusting by ear than looking at the display all the time (like EvilDragon already mentioned), sometimes also using a MIDI-Controller like e.g. a Korg NanoKONTROL or a M-Audio Ozonic.

Not sure if there will be a fix for this, at least this would be a bug with "low priority". Of course this would be different if another issue would be somehow related to this (sometimes two different issues are caused by the same source).

[c_voltage]

I confim a small delay at the display in Studio One

But I have seen a significant delay. Ok, i perhaps will be make a video of this issue with both versions for compare. And who know, maybe it better reproduced exactly in vst2 32bit.

And then, if it's not a bug, and has no relation to the synth engine (ie does not require laborious intervention), ie eg just an element of the algorithm of GUI work, then why not just copy and paste it part of the code from the 102? In any case, it would be a benefit. (or i;m wrong ?)

[Ingonator]

UPDATE (to the tests in my previous post):

In Live 9.1.7 64-bit I just checkd using my Korg NanoKONTROL with PPG Wave 3.V. I added the Cutoff, resonance and the enveloepes to the Live device panel (with "Configure" button and MIDI Learn).

This is what i found concerning the values and the sound when moving the knob at the NanoKONTROL:
- This time the faders added to the device panel do move in real-time
- the knobs at the GUi seem to move correctly without a delay
- The dispaly at the GUi has a delay now (when the mouse cursor is hovered over the cporresponding knob, without that you will not see the value)
- I do not notice a delay between knob movement at the controller and the sound, even when moving fast (e.g. moving Cutoff at high resonance)

So when using a controller the displays behavior seems to be opposite to that when moving the knob in the GUI with the mouse.
Anyway in both cases there does not seem to be a problem with knob movement and the resulting sound.

[Teksonik]

Just as an update to a post I made about 15 pages ago........My opinion on Waldorf Support has changed 180 degrees. I had an unpleasant experience but Christian has more than made up for that with an excellent gesture. I'll say no more about that but now I'm a huge fan of Waldorf..........

[robotmonkey]

Installed FL Studio 12 today and found out that Waldorf VST3 plugins will crash it during deep plugins scan. Both PPG Wave and Waldorf Edition. All x32 latest versions.

Not that I personally care much at the moment as VST2 does work, but still.

[subterfuge]

We want to finish all bug fixes for the Waldorf Edition ASAP so any bug reports for the included plugins are welcome.
Ingo

No pre-testing, so late in that regard. But if you can verify/pass this info Ingo, that may help with the possible future fixes. Maybe other users could also confirm this?

So, it's about the Waldorf Edition 2.0.1, Attack drum module. Same thing happens with both VST and VST3 64-bit versions.

Preset: 808 Kit.
Problem: With sounds 22 (FM Bass), 23 (Reso Bass) and 24 (Sine Attack), when the first or the last key in the Attack keyboard is pressed (and hold) and the mouse cursor is then dragged to any other direction but towards the other keys, a high pitched sine wave is stuck playing. This is easy to reproduce by playing a glissando with a mouse and letting the cursor go over the bounds of the last key on each end of the keyboard.

The sound will not stop unless a MIDI reset is sent from the DAW or the preset kit is changed into something else. This problem will not occur if Attack is played from external keys, only with the GUI keyboard. This leads me to believe the problem is some kind of UI glitch, but I've only been able to reproduce it with these three 808 kit sounds.

[Ingonator]

We want to finish all bug fixes for the Waldorf Edition ASAP so any bug reports for the included plugins are welcome.
Ingo

No pre-testing, so late in that regard. But if you can verify/pass this info Ingo, that may help with the possible future fixes. Maybe other users could also confirm this?

So, it's about the Waldorf Edition 2.0.1, Attack drum module. Same thing happens with both VST and VST3 64-bit versions.

Preset: 808 Kit.
Problem: With sounds 22 (FM Bass), 23 (Reso Bass) and 24 (Sine Attack), when the first or the last key in the Attack keyboard is pressed (and hold) and the mouse cursor is then dragged to any other direction but towards the other keys, a high pitched sine wave is stuck playing. This is easy to reproduce by playing a glissando with a mouse and letting the cursor go over the bounds of the last key on each end of the keyboard.

The sound will not stop unless a MIDI reset is sent from the DAW or the preset kit is changed into something else. This problem will not occur if Attack is played from external keys, only with the GUI keyboard. This leads me to believe the problem is some kind of UI glitch, but I've only been able to reproduce it with these three 808 kit sounds.

Hi,

this was already reported by one of thetesters at the official Waldorf bug database. I could confirm this here too. Anyway i found this only seems to happen when the Amp envelope Decay is set to maximum, like in e.g. Instrument 22 at the 808 kit (and same for instruments 23 + 24). If you reduce the Amp envelope Decay the issue does not seem to happen.

In Live 9 the most simple way to stop this was deactivating the plugin and re-activating it (with the button at the Live device panel).

The issue indeed does not seem to happen when using a MIDI controller or when playing back recorded notes (or notes created from the piano roll).


Ingo