Acon Digital VSTs Issues In SAWStudio64

[Todd R]

Happy to help. Parameter automation may be a tougher issue to tackle.

hmmmm, further, I was reading up on VST3 spec

and PROGRAM CHANGE is not allowed
I grasp why

I'm pretty shocked at how CPU friendly the Reason Rack VST is...I'm guessing Reason running in the "background" is handling processing...and it's just a latency issue for SAW

NOW I have a Reason ;-P to put RML MWS to use....bought it for something!

I would like NRPN/ dual channel 14 bit MIDI, tho!

[Dave Labrecque]

hmmmm, further, I was reading up on VST3 spec

and PROGRAM CHANGE is not allowed

What do you mean by program change? You mean the PC MIDI command? What are you trying to do?

[Todd R]

What do you mean by program change? You mean the PC MIDI command? What are you trying to do?

Yes, essentially MIDI PC concept for lack of a better description. The terms kinda need defining to get into deep discussion....different manufacturers and hence different users have different terminologies for "custom user preset of parameters"...many use the term PATCH (Marshall JMP-1)...Lexicon was using "REGISTER" on PCM8x/9x...DigiTech GSP2101 and Fender CyberTwin used PROGRAM. I typically say "PROGRAM" for this...like the MIDI spec.

If I could automate VST plugins' PRESETs during playback, that would essentially be what I need to do...and is essentially what most of us do but use a "workaround"

rather than have set, always on FX as in old school hardware, running through various AUXs

instead, we bounce/ burn-in our FX...set up AUXs...WaveLab/CoolEdit yadda yadda etc

[Dave Labrecque]

If I could automate VST plugins' PRESETs during playback, that would essentially be what I need to do..

This has been a requested feature addition for a very long time. One approach, as you may know, is to instantiate multiples of the plugin, each with its own settings, then automate the bypass state of each as needed. But automating plugins' bypass state in SAW is often not smooth sailing, unfortunately.

[Bob L]

Another option would be to cut the track region where each preset change is wanted, then move the next section to another track and patch the new plugin settings on that track... by splitting the original track across many tracks, you can have seamless preset changes from section to section.

Bob L

[Dave Labrecque]

Another option would be to cut the track region where each preset change is wanted, then move the next section to another track and patch the new plugin settings on that track... by splitting the original track across many tracks, you can have seamless preset changes from section to section.

Bob L

Great idea, Bob!

[Todd R]

This has been a requested feature addition for a very long time. One approach, as you may know, is to instantiate multiples of the plugin, each with its own settings, then automate the bypass state of each as needed. But automating plugins' bypass state in SAW is often not smooth sailing, unfortunately.

indeed, this is the method I have been using for many years in SAW

[Todd R]

Another option would be to cut the track region where each preset change is wanted, then move the next section to another track and patch the new plugin settings on that track... by splitting the original track across many tracks, you can have seamless preset changes from section to section.

Bob L

Bob, thanks for responding...I've used your proposed workflow a bit.

I'm not mixing music, per se; regions are patchwork as I have shown in previous screen shots...it's mostly interview of human voice comps and M&E.

Bob, seems like it would ADD to VST count in the jobs...which I'm trying to keep lean. Increasing MT Load is what I'm trying to avoid. My "preset changes" automation events are outside of REGION boundaries so latency has time to process and bypass/on state is inaudible.

Further, I'm automating in the busses (AUX or OUTPUT SUB), NOT on INPUT tracks because ACON was not working on input tracks and I typically have 4 input tracks routed thru the AUXs; and then AUXs and INPUTS in the Busses.

Heck, Stian suggested I switch to Reaper :-O I'm not doing that!

STILL, the issue remains:
multiples of the same plugins have the same names in the FX Patches windows in SAW. SAW doesn't support VST3, anyway...hence MetaPlugin...cool,...VST3 in SAW, hooray. Didn't think I'd need or want it, but glad it's possible. I have NEVER asked for VST3 implementation in SAW; I was only pointing out what I read re: the VST3 spec about PROGRAM CHANGE...nothing more.

One HUGE issue is of LABELLING FX:
and then another is of MARKING specific plugins in the multitrack channel's automation view.

The workaround of using differently named .ini VST ID docs where the name of the .ini doc could be the FX PRESET NAME does work to deliver the labelling for the VST instance in the SAW FX Patches lists.

Visual differentiation of automation events Markers in the MULTITRACK are not possible in SAW at this time; all automation events for Patched FX in SAW are orange/brown. I'm using the CONTROL TRACK for noting IN TEXT what each automation event is. 4 or 5 color choices for the automation event would be great for my needs. I've already spent enough time writing out in text in the CONTROL TRACK, so I do have a workaround....I don't like it, but it does work.

I mean, two colors would be a BOON! One color for "ON" and another for "BYPASS"...I'm supposing there are no more colors available...

anyhow, thanks for taking the time

[Todd R]

oh my...same problem with MetaPlugin
acon plugs just stop working
MetaPlugin does allow context menus, where without it they are locked out

I gonna hafta bounce everything

It has been fine since 2011...move to JUCE I can only guess is the issue :-/

that's 70 more bux down the drain

[Dave Labrecque]

The workaround of using differently named .ini VST ID docs where the name of the .ini doc could be the FX PRESET NAME does work to deliver the labelling for the VST instance in the SAW FX Patches lists.

What do you mean by this?