Working Faust code exported to Windows32 VST is sometimes compiled incorrectly.

[grame-cncm]

Working Faust code exported to Windows32 VST is sometimes compiled incorrectly.

[DazDSP]

I'm finding a lot of the problems I'm getting when trying to compile working Faust code into a VST appear to be due to combining the following functions...

• Sliding Reduce operations
• FIR filter
• Other filters like highshelf etc.

When the VST compiles in broken form, the VST file size is SMALLER - even though functions have been added to the code!

It's as if the Faust compiler is dropping some parts of the code entirely.

The code works as expected if the code is broken up and compiled into separate VSTs, but this is troublesome to run in cascade.

Any ideas on ways to fix the problem? Or have I hit some compiler or VST limitations?

Daz

[sletz]

When using the online compiler, the same DSP code is sent for any choosen target.

• are you using the Faust IDE (https://faust.grame.fr/ide) to edit and test the code?
• are you exporting for macOS ?
• is the DSP code open and available somewhere to be tested?
• have you tried the JUCE path ? (since JUCE can also export VST)

[DazDSP]

I edit locally on the PC, and test code in FaustLive on Windows 7.
To export to Windows 32 VST, I've been using the Faust editor.

I haven't tried the Faust IDE until now. When loaded, it consumed all available RAM and became almost unresponsive.
I have not tried JUCE.

Here is some audio processing code that causes the VST problem:
The code has a 10 second buffer for look-ahead, so there will be no output for the first ten seconds.
This code runs fine in FaustLive. The metering has been removed for this version.
http://homepages.ihug.com.au/~daz2002/tech/Auto_Stereoizer-5v13d.dsp

[sletz]

Nothing seems wrong with the code. I would suggest to try the JUCE VST export (tested here on OSX and Ableton Live and it seems to work correcly AFAICS)

[DazDSP]

Does the method shown produce a compiled VST, or just source code?
When I tested it, it saved a zip file that appeared to contain cpp source, and a "jucer" file only.

[sletz]

Yes, it produces a JUCE project (the jucer file) that you'll have to compile yourself to get the compiled VST.

[DazDSP]

That is a considerably more troublesome path to take, as I am not familiar with Juce.
This also raises the question: Have I hit a resource limitation of the Faust compiler, or does it appear to have a bug?
I couldn't find any references to VSTs having particular complexity or memory limits.

[sletz]

If you install the JUCE SDK, it should be quite straightforward. For now there is no reason to think there is a specific bug.

[DazDSP]

How could there not be a bug if it is compiling broken VST code?
You would expect the size of the VST to grow larger when more code is added. Instead - when the compiled VST is broken - the VST has a smaller size than previously, even though it has become more complex.

[sletz]

I mean, it could be a bug in the specific VST architecture file (that is the generic file that is added around the code produced by the Faust compiler), but not in he compiler itself. Trying the JUCE path can help answering this question.

[DazDSP]

Is it just a matter of loading the exported JUCE project saved from Faust into Projucer, and compiling it into a VST? I can't seem to find any option to compile the JUCE project to a VST (but this is the first time I have used Projucer).
The "Selected Exporters" list only shows:
Xcode (MacOSX)
Xcode (iOS)
Visual Studio 2015
Linux Makefile
Android

[DazDSP]

Using JUCE to build a VST will require some more time and effort to figure out.
In the mean time, I have done some testing.

Even the "music_detect" routine by itself would not compile into a working VST.
Removing the sliding RMS and recursion made no difference.
BUT.. removing the large look ahead delay enabled it to compile successfully.

Further testing revealed if this code was removed:

//old code
sps = ma.SR; //samples per second
delay = (nmax)+(trim/2)+(3*sps);
trim = 8 * sps;
ddd = dd,dd@(trim):min;
out = l@delay,r@delay,ddd;

and was replaced with this:

//new code
ddd = dd,dd@352800:min;
ld = l@374236; //only one audio output channel is needed because it's mono
out = ld,ddd;

Then the code compiles into a working VST.

Even with only one audio channel being delayed, the VST still breaks using the old code.
But the old code should evaluate the delays to the same numerical result as the new code!

Applying delays to both audio channels breaks the VST. But only one channel is needed because of the mono input.
Applying the "ddd" delay AND including the rest of the original code also breaks the VST.
Leaving out the "ddd" trim delay allows the rest of the original code to compile correctly. But this doesn't function as needed.

At this stage, the easiest option is to compile the code into two sections:
1: The Music Detect code (output is mono audio and a DC control signal)
2: The Stereoizing code, including EQ and limiting (output is two channel stereoized audio)

This also allows the automatic music detection of the first stage to be inspected and edited in a normal sound editor, which is actually an adavantage.

[DazDSP]

A video demo of the code running in FaustLive, with some improvements. Audio is from a mono shortwave broadcast (with some special enhancements).
https://storage.googleapis.com/dazman/misc/2019-12-28-TIAMS-AutoStereo-05.mp4