View Issue Details
|ID||Category||Date Submitted||Last Update|
|0008460||bugs||2020-10-27 11:41||2021-04-28 02:16|
|Fixed in Version|
|Summary||0008460: Stienberg VST3's do not retain preset's|
|Description||Saving a session using Stienberg VST3 plugins with preset.|
The preset's are empty when the project is reopened.
Equivalent VST2's work.
VST3's work fine in Mixbus
|Steps To Reproduce||Add Stienberg Instrument VST3 to a midi track in a project such as Halion 6. Groove Agent, The Grand 3, or Retrologue.|
Set up instrument preset of any type, factory or otherwise.
Save and close the project.
Re-Open and preset's are gone.
|Tags||No tags attached.|
Which version are you using?
This is likely already fixed in Ardour 6.3-249 or later. Ardour now also picks up changes when the loading presets using the plugin's GUI (assuming the plugin supports that).
I do however not have access to the plugins you've mentioned so it'd be great if you could test those (https://nightly.ardour.org )
Another guess: You may have tested a version 6.3-203 or older. Presets were incorrectly saved, and you'll may to manually delete them, since Ardour cannot re-read them.
On Windows they're in
[my documents]/vst3 presets/$company/$plugin-name/
||Using 6.3.253. Generally I keep up with the nightlies for Windows and buiId from source on my linux instance. I had hope for the commit you mentioned but it didn't address this issue. When a VST3 from Stienberg is added to a project it takes a double save to remove the asterisk from the title line. I.E. the first save flashes the Title bar text but doesn't remove the (unsaved) asterisk. The VST3 presets still disappear on re-opening. I've removed all presets from [my documents]/vst3 presets/$company/$plugin-name/. I'm testing mostly with Stienberg plugins that there are both VST2 and VST3 versions but all those that are VST3 only act the same.|
||Could you test if the issue is still present in 6.3-274-g8bb76f2a65 ?|
||No build environment for Windows so I'll have to wait for new nightlies to be available (Steinberg only provides these VST3's for Windows and MAC). I've tested with 6.3.273 and no symptom change. Expect response in AM.|
I've just received a report that with 6.3.273 retrologue presets works on windows. "Custom and internal presets are restored correctly, no problem!"
(6.3.273 is fine, the -274 commit is unrelated, sorry)
||Not here. Just tested VST3 versions of Retrologue, Halion 6, and The Grand3, and Groove Agent 5 on two Windows 10 computers w/6.3.273. Same symptom. VST2's of GA5 and H6 are fine. When a VST3 is loaded Ardour6 requires a double tap to save.|
||I can confirm on Win10 + Ardour 6.3.304 that Sforzando does not retain VST3 presets on re-opening. Also, It shows the VST2 and VST3 versions I have installed both as VST3.|
||EDIT: I now have "conceal VST2 plugin if matching VST3 exists" unselected but there are two VST3 instances of Sforzando listed...very odd as it doesn't show multiples in any other DAW.|
I also cleared the cache for both VST2 and VST3...Attached is the result of a search.
two vst3.png (14,454 bytes)
two vst3.png (14,454 bytes)
Here are the results of the VST scanner:
C:\Users\cmh>[Info]: Scanning: C:\Program Files\Common Files\VST3\Sforzando.vst3
[Info]: Found cache file: 'C:\Users\cmh\AppData\Local\Ardour6\cache\vst\2fc9ecaf80e4bf0d67759e5138743912f5235f9d.v3i'
[Info]: Cache file is up-to-date.
[Info]: FactoryInfo: 'Plogue Art et Technologie, Inc' 'https://www.plogue.com' 'mailto:firstname.lastname@example.org'
[Info]: Class count: 2
[Info]: Class: 0 'sforzando' 'Audio Module Class'
valid signature detected for C:\Program Files\Plogue\Aria\aria_x64.dll
Engine path:C:\Program Files\Plogue\Aria\aria_x64.dll
queried details:ARIA Engine v1.967 (Win x64)
ARIA Engine v1.967 (Win x64)
vendorName :Plogue Art et Technologie, Inc
[Info]: VST3: media: 0 dir: 0 type: 0 n_busses: 0
[Info]: VST3: media: 0 dir: 0 type: 1 n_busses: 0
[Info]: VST3: media: 0 dir: 1 type: 0 n_busses: 1
[Info]: VST3: bus: 0 count: 2
[Info]: VST3: media: 0 dir: 1 type: 1 n_busses: 1
[Info]: VST3: error getting busInfo for bus: 0 rv: 0 busType: 0
[Info]: VST3: media: 1 dir: 0 type: 0 n_busses: 1
[Info]: VST3: bus: 0 count: 16
[Info]: VST3: media: 1 dir: 1 type: 0 n_busses: 0
[Info]: Skipping non-effect class: Component Controller Class
[Info]: Found Plugin: sforzando
<VST3Cache version="1" bundle="C:\Program Files\Common Files\VST3\Sforzando.vst3" module="C:\Program Files\Common Files\VST3\Sforzando.vst3\Contents\x86_64-win\Sforzando.vst3">
<VST3Info uid="5C5CA79682FC437AB6539BA204BAB349" name="sforzando" vendor="Plogue Art et Technologie, Inc" category="Instrument" version="188.8.131.52" sdk-version="VST 3.6.12" url="https://www.plogue.com" email="mailto:email@example.com" n_inputs="0" n_outputs="2" n_aux_inputs="0" n_aux_outputs="0" n_midi_inputs="1" n_midi_outputs="0">
[Info]: Saved VST3 plugin cache to C:\Users\cmh\AppData\Local\Ardour6\cache\vst\2fc9ecaf80e4bf0d67759e5138743912f5235f9d.v3i
||@bachstudies The duplicate listing of sforzando is solved in 6.3-327-gf9e9c6248d.|
||Terrific! I'm assuming though that this is still a separate issue from the non-retention of values on re-opening of a VST3 plugin?|
||As for the original issue, please test 6.3-331-g5fd2d6cc81|
||6.3.332 confirmed working properly!! More thorough tests to follow with all VST3's. There is still a double tap required to remove the title bar "modified" asterisk but it seems preset modifications are properly recorded on 1 save.|
||Although presets are retained with a single save, it is quite easy to get a Session confused so that it requires safe-mode to start or crashes completely even using safe mode startup. In the case of a crash an un-endable Ardour process is left that requires sign-out to remove. When this happens the symptom is "Could not start process thread". Certain (more complex, like Halion 6 or Padshop) Steinberg VST3's seem to aggravate the issue. I seldom want to use more than drums and Piano or Synth but I'm testing with heavier, more complex sessions to locate the limits. Steinberg The Grand 3 works completely as expected without needing a double save to remove the "modified" asterisk. Adding most others, with or without other settings applied, require the double-tap. -Still- GREAT job, and I hope this info helps.|
Thanks for checking and confirming the fix. it was a stupid bug (uninitialized variable) which explains why it saving state most of the time on some systems but not others.
I do not yet have an explanation why some plugins mark the session as modified after saving the session. I do not have any VST3 installed here that cause this issue. Is it specific to a plugin, or perhaps related to automation or control events sent to the plugin?
PS. I'm tempted to postpone fixing this after the Ardour 6.4 release. It seems a minor issue, not worth delaying 6.4 further.
||Sforzando VST3 working perfectly now. Thanks, Robin!|
Here are some session files copied after each step. Clean is a project with two VST3's . Steinberg The Grand 3 and Halion 6. H6 preset mod has a different preset on H6. The "modified" asterisk displayed but not until I focused to another track. H6 preset mod was copied after the asterisk came on but those session files are identical. The other two are after one save click, then 2 save clicks.
x42: I have two Steinberg dongles. Would it be valuable if you had one loaned with some of these VST's licensed to troubleshoot? Might be possible. Contact me OOB.
e-mail in my profile...
||Absolutely do not delay 6.4 for this issue. I would expect very few Ardour users to have these VST's. At the same time they are probably the gold standard on pushing VST functionality... ;-). The way I use them in my live rig works sooooo much better with Ardour as opposed to Cubase though.|
Steinberg does provide a "VST Host checker" with the VST3 SDK and I'm using that to test. But apparently it only catches a subset of real world issues.
Thanks for offering the Seingberg dongle, but I think it's no use for me, since I do develop on Linux (and occasionally macOS), I do not have a windows machine.
Harrison is doing Windows testing and they do have some iLok and also access to NFR copies from various vendors.
||PS. Nik at harrison did test Retrologue and was not able to reproduce the issue, but he was using a debug build that was less likely to hit this issue.|
||works well now!!|
|2020-10-27 11:41||dth||New Issue|
|2020-10-27 17:01||x42||Note Added: 0025171|
|2020-10-28 00:22||dth||Note Added: 0025174|
|2020-11-02 16:17||x42||Note Added: 0025192|
|2020-11-02 16:46||dth||Note Added: 0025193|
|2020-11-02 16:49||x42||Note Added: 0025194|
|2020-11-02 17:18||dth||Note Added: 0025195|
|2020-11-12 00:13||bachstudies||Note Added: 0025217|
|2020-11-12 00:16||bachstudies||Note Added: 0025218|
|2020-11-12 00:22||bachstudies||File Added: two vst3.png|
|2020-11-12 00:22||bachstudies||Note Added: 0025219|
|2020-11-15 00:29||bachstudies||Note Added: 0025228|
|2020-11-16 17:35||x42||Note Added: 0025229|
|2020-11-16 18:33||bachstudies||Note Added: 0025230|
|2020-11-17 01:53||x42||Assigned To||=> x42|
|2020-11-17 01:53||x42||Status||new => feedback|
|2020-11-17 01:53||x42||Note Added: 0025231|
|2020-11-17 12:33||dth||Note Added: 0025232|
|2020-11-17 12:33||dth||Status||feedback => assigned|
|2020-11-17 13:32||dth||Note Added: 0025233|
|2020-11-17 14:24||x42||Note Added: 0025234|
|2020-11-17 16:46||bachstudies||Note Added: 0025235|
|2020-11-17 18:32||dth||Note Added: 0025236|
|2020-11-18 19:07||dth||Note Added: 0025239|
|2020-11-18 19:26||x42||Note Added: 0025240|
|2020-11-18 19:32||x42||Note Added: 0025241|
|2021-04-28 02:16||dth||Status||assigned => closed|
|2021-04-28 02:16||dth||Resolution||open => fixed|
|2021-04-28 02:16||dth||Note Added: 0025774|