BS 5.3.13 automation broken with UVI Falcon?

[pboy]

Has anyone been successful in writing automation with UVI Falcon? I'm new to this synth/sampler, and it doesn't follow my automation curves as I'm used to in Bitwig. Other instruments obey just fine

Any suggestions? Is there a hidden function in Falcon to activate?

[Milkman]

Ive actually grabbed that falcon own forever bundle, and Im also new to falcon -- Im also having trouble with automation in both 5.3 and 6. The 'last touched parameter' doesnt show up in BWS's automation system, UVI's parameters are labeled "host automation 1, 2, 3", etc, and those parameters dont seem connected to Falcon's controls.

I will send UVI a support message on this soon. Ive read the docs and searched through the interface, but I dont see it if its there.

[Broken]

Has anyone been successful in writing automation with UVI Falcon? I'm new to this synth/sampler, and it doesn't follow my automation curves as I'm used to in Bitwig. Other instruments obey just fine

Any suggestions? Is there a hidden function in Falcon to activate?

I used Falcon in Bitwig at a friend's place a few years ago. I vaguely remember having to do mapping in Falcon's UI before parameters would show up in Bitwig to be automated. I think there is an Automation tab where you can drag and drop host automation points to the parameter you want to automate, which should then be available to Bitwig.

Does that work?

EDIT: I can't remember what version of Bitwig or Falcon I used at the time, but it has worked in the past. Obviously an update could have broken it since, though.

[Milkman]

Ahhh this makes sense, and is in line with UVI's philosophy, lol. I thought something like this might exist (using Falcon's internal automation to enable external automation), as I had to do some heavy lifting just to stop my expression pedal from being connected to Falcon's main volume. I found some fairly cryptic controls over on the left side, under "parts", when you can strip midi mappings. However the default expression pedal mapping isnt under "mappings" its under "modulation", so it was really confusing. ; )

[MegaPixel]

Falcon is awesome, but it oh so needs a lot of work, and I've been waiting a long long time for that, it aint going to happen. Same with Steinbergs Halion.

[JsinOwl]

In Falcon, right click the parameter you want to automate, select 'Assign to Host automation' from the context menu, and select whichever host automation channel you want to use. The host automation channel's name will change to reflect the name of the parameter. Return to the host, you will now see the newly named automation channel is available to automate or modulate to your heart's desire.

It's a bit different. In most plugins you automate a parameter directly, but in Falcon you automate an automation channel which in turn is assigned to the parameter. Dunno why

[fde101]

Many plugin hosts break or simply don't work right if the plugin changes the set of parameters that can be automated at runtime. With the set of parameters in Falcon being dependent on the structure of the loaded instrument, it effectively has a dynamic and potentially unlimited set of parameters that could be automated, and there is no way for it to present such a set directly to the host when the host might not support that capability.

To work around that, it has a fixed set of automation parameters it presents to the host and uses this mapping scheme.

Kontakt does the same thing, except that it automatically maps the parameters of a loaded patch to the first available automation parameters when the patch is loaded, where that is possible. Falcon doesn't automate that, but the basic concept is ultimately the same.

[BobDog]

Many plugin hosts break or simply don't work right if the plugin changes the set of parameters that can be automated at runtime. With the set of parameters in Falcon being dependent on the structure of the loaded instrument, it effectively has a dynamic and potentially unlimited set of parameters that could be automated, and there is no way for it to present such a set directly to the host when the host might not support that capability.

That's incorrect. AU, VST3 and AAX support this "potentially unlimited" set of parameters, changeable in number at runtime. All hosts support this.

To work around that, it has a fixed set of automation parameters it presents to the host and uses this mapping scheme.

Kontakt does the same thing, except that it automatically maps the parameters of a loaded patch to the first available automation parameters when the patch is loaded, where that is possible. Falcon doesn't automate that, but the basic concept is ultimately the same.

VST1/2 had a fixed automation parameter count so plugins would "allocate" a large range and then alter the metadata of those based on the patch/program. AU and VST3 allow the number of automation parameters to change, VST1/2 is dead. As you say Kontakt would work this way. Not "potentially unlimited", but let's say we allocate 10,000 and use those.

Also of course the actual metadata about these "immutable" automation parameters you are talking about are actually mutable, the host is not displaying P00001, p00002 etc if the plugin is coded properly, so the metadata is changing and the host understands this.

So really there is no need for Falcon to be acting in this way, first the idea of a fixed number of parameters is now gone, secondly even if they still stick with this idea as other plugins like Kontakt or Reaktor do (also old code), just use a large pool of automation parameters and change the metadata for those parameters depending on the patch/program loaded.

Falcon is just bad, like Omnisphere. There is just no need for a user to have to map automation parameters to use.

[fde101]

Yes, newer plugin formats are designed to support this, and with some hosts it apparently works just fine, but some hosts struggle with it, and even when it does work, they may not correctly map the automation after these changes: if the 7th of 16 parameters gets dropped, and the 8th was automated, then the host may continue to provide that automation to the *new* 8th parameter instead of the old one, even though it is not the same parameter any more.

Again, it varies with the host. Using these strategies levels the playing field in the absence of consistently good behavior from the assortment of hosts the plugin vendors are trying to support.

[Milkman]

There should be a simple toggle to switch Falcon between host automation mode & internal automation mode. I cant imagine this would be difficult to code into the application and it would solve this hassle for people willing to spend... as much as Falcon is asking.

[BobDog]

Yes, newer plugin formats are designed to support this, and with some hosts it apparently works just fine, but some hosts struggle with it, and even when it does work, they may not correctly map the automation after these changes: if the 7th of 16 parameters gets dropped, and the 8th was automated, then the host may continue to provide that automation to the *new* 8th parameter instead of the old one, even though it is not the same parameter any more.

Again, it varies with the host. Using these strategies levels the playing field in the absence of consistently good behavior from the assortment of hosts the plugin vendors are trying to support.

So in falcon if you map the parameters that you want to automate and then switch to another patch with different mapped automation parameters are you saying that the host will not continue the automate the changed parameter?

[fde101]

So in falcon if you map the parameters that you want to automate and then switch to another patch with different mapped automation parameters are you saying that the host will not continue the automate the changed parameter?

It will continue to automate what might be a different parameter. If a compressor attack is mapped to parameter 1 in the first patch then you switch to a patch which maps a cutoff frequency to parameter 1 then the automation you put in place for the compressor attack in the old patch will in most cases be applied to the cutoff frequency in the new patch.

[BobDog]

So exactly the same as :

if the 7th of 16 parameters gets dropped, and the 8th was automated, then the host may continue to provide that automation to the *new* 8th parameter instead of the old one, even though it is not the same parameter any more.