Just one question as there are so many plugins that work with Waves, and doesnt work with Fourier. What they do better? Also I think the latency is less with Waves system. Yeah, I understand that it is different Architecture of system and Fourier system is isolated per process. Just wonder why most of plugins work with Waves but not with Fourier.
Hello Mika,
Is that true?
I heard of more compatibility problems with the waves superrack livebox (which is Kind of the equivalent to the Fourier engine?) with “non-waves” Plugins.
Latency of the Fourier comes mostly from the Dante Connection (+2ms in total). The Processing itself should be comparable to waves?
Well, at least Defeedback and Kraftur for one example. Also I think processing is bit faster. I’ve never managed to Get at least with my conficuration this magical 3ms latency. Its always at least 4-5ms with Dlive conficuration. I will do some measurements after holiday. But I’ve had quite lot of problems with this box and no help from support.
I haven’t tried Waves box but people Are for example using these plugins I’ve meantioned with Waves and with Fourier they Are just peaking even with 64 samples.
The world of plugins is evolving very fast at the moment. Like every week there are new plugins coming out with special interfaces/functions. I assume it is pretty hard for a FX engine manufacturer like Fourier (or also Waves) to provide compatibility for every Plugin.
I guess some plugins will not run smoothly on Superrack Livebox and some others will not run smoothly on Fourier. But at least Fourier has a Plugin Compatibility List where at least Kraftur is marked as tested. Maybe you should contact the support directly to check why Kraftur is not running smoothly?
I also had some issues in the earlier software versions but i feel that they improved stability/compatibility quite alot in the last update.
As far as latency go, i did some googling and found somebody measuring the Waves Livebox Madi with 2,24ms. But there is a RME Madicard installed and the connection will limit to 32 channels at 96 khz.
With Dante it seems that the built in Marian Dante Card can handle Dante Latency of 0,5ms, which would result in a total theoretical latency of 2,33 ms at 48 khz/32 samples. At 96 Khz the minimum buffer size of the Marian card seems to be 64 samples, so it would be the same. This is if the Marian Card (and your Dante Infrastructure) can handle the 0,5ms Dante Latency (which i don’t know).
For the Fourier it seems that the Dante Latency should be set to 1ms, so we get 2ms for Dante and 2x0,33 ms with 32 samples at 96khz; 2x0,66ms with 64 samples (at 96 khz)
So the theoretical difference of the two systems would be around 0,5-1ms. If the Waves Livebox is set to 1ms Dante Latency, the Fourier would even be faster, running at 32 samples at 96khz.
Correct me if i did something wrong in my calculations.
Because i never measured my setup, i will try to do it on monday and then report the results.
Okay, so i had some time to measure our setup before christmas.
The setup is: Digico Q852, Orange Box in Optoloop → Transform Engine
These are the values i measured (using Systune, a MOTU Soundcard and a XLR Input/Output from the Local IO:
Desk: Input->Channel->Directout:
@48k: 0,865ms
@96k: 0,437ms
1x Busrouting (Aux/Group):
@48k: 1,302ms (difference is 0,437ms)
@96k: 0,646ms (difference is 0,209ms)
The following values are without the channel I/O latency. So the total additional latency for the whole insert.
Fourier over insert 48khz 512 samples: 34,729ms (4,2% CPU Usage)
Fourier over insert 48khz 64 samples: 6,718ms (8,7% CPU Usage)
Fourier over insert 48khz 32 samples: 4,729ms (15% CPU Usage)
Fourier over insert 96khz 512 samples: 18,511ms (8,4% CPU Usage)
Fourier over insert 96khz 64 samples: 4,511ms (20% CPU Usage)
Fourier over insert 96khz 32 samples: 3,511ms (36% CPU Usage)
Fourier over insert 96khz 64 samples (SRC in OrangeBox 48->96k): 4,677ms (20% CPU Usage)
Fourier over insert 96khz 32 samples (SRC in OrangeBox 48->96k):
3,677ms (36% CPU Usage)
Inserting Graphic EQ at 48Khz: 0,125ms
Inserting Chili-6 at 48Khz: 0,468ms
Inserting Naga-6 at 48Khz: 0,395ms
So it seems that it is quite beneficial to run the Engine at 96k to minimize Roundtrip-latency. Also noticable is the higher CPU Usage with higher Sample rate and lower amount of Samples. The project contained 12 chains with mostly Fabfilter Pro-R and some Eventide Reverbs in it. I recognized that the Pro-R is pretty CPU consuming because both Seventh Heaven and Cinematic Rooms are quite a lot more CPU friendly.
So in our case at the moment we cannot run the console at 96k because we have a QSC Q-Sys Audio Matrix following (which sadly only supports 48k at the moment and converting the Samplerate would introduce more latency).
So for the best latency in 48k environments it would be an option to let the orange box convert to 96k (which is in comparison very fast, 0,166ms) to get the shorter processing time for the Transform Engine. Sadly the internal port of the Fourier option does not convert sample rates.
@Fourier Team: Is there something more that could be optimized? Is the Latency through the internal Fourier Ports shorter? I don’t remember excatly how much latency the Optocore is introducing, but i think it will not be alot…
For the Waves/Fourier comparison:
I would assume that the Dante Version of the Superrack Livebox would have similar Latency, the MADI Version should be a bit quicker. Some real measurements would be interesting.
Thanks a lot and have a merry christmas! 
1 Like
Hi all,
Thanks for all the details and questions so far. I’d like to try and break this down into the different points being raised, because there are a few separate things worth clarifying:
- “Why do more plugins work on Waves than on Fourier?”
First of all, I want to make clear that we are working closely with both Alpha Labs and Sound Theory (and other manufacturers) to improve plugin performance on the transform.engine.
MBelle92 makes an important distinction, this depends if we are comparing to VST3 hosts or closed systems.
With VST3 Hosts:
Plugin UI interaction can be stifled through our plugin teleportation, and we work closely with plugin manufacturers to improve the user experience when interacting through our system. Teleporting plugins (instead of hosting them natively) is required for our audio sandboxing and multi client functionality. This also means if you lose client connection, you do not lose audio. We would not consider hosting plugins natively “safe practice” which is why we use a VM based solution.
In a closed system (such as SuperRack SoundGrid), plugins are implemented specifically for that environment.
In any native approach (such as Waves Livebox, LiveProfessor, ect), it is not possible to implement a multitude of our current functionality (Plugin Sandboxing, Multi-Client, ect) and planned future functionality. This is due to limitations with the architecture of the system.
Since the transform.engine runs each plugin in an isolated, sandboxed process. This also means if plugins rely on undefined behaviour, multiple threads, or timing assumptions, they are more likely to fail or be blocked.
So some plugins working on other platforms can be attributed to the system controlling the entire runtime and accommodating for the plugins implementation.
- Latency comparison
To answer @MBelle92, We are actively working on multiple ways to reduce the latency in the system in coming releases.
The transform.engine, when set to 96kHz and a 32 period size operates at 3ms round-trip, excluding any console insert latency. This can be proven by taking a latency measurement across the transform.engine as a measured channel, and routing a Dante patch 1:1 on your reference channel. This means the consoles insert latency will be taken into account.
- “Why don’t more third-party plugins support Fourier?”
The transform.engine is the first of its kind regarding implementation, and the support by plugin manufacturers over the year and a half since its release has been amazing. This is an evolving process and we have established good working relationship with many of the R&D teams.
As a side note, I can see that a post of yours was not responded to on this forum in September, and I would like to apologise for this, support is something we take seriously and any further issues you encounter, please do let us know.
I hope this helps, but feel free to bring up any further questions.
Best,
Ross
Product Specialist
1 Like