Any suggestions regarding to Acustica Audio?

[JerGoertz]

I think they sound great, but use too much CPU in my case (top spec MBP 16”). I also am waiting for Lemon to be updated and it seems that it never will.

What's wrong with Lemon?

[perpetual3]

I think they sound great, but use too much CPU in my case (top spec MBP 16”). I also am waiting for Lemon to be updated and it seems that it never will.

What's wrong with Lemon?

It has not been updated to latest tech, interface is very blurry. That sort of thing.

[plexuss]

Some pretty big bugs/limitations with Acquas have come up and are being discussed on GS. Just reporting here that if the sample rate of a project changes, Acquas can not be relied on to work properly at the new sample rate. Every module/band will need to be turned off and back on again. For exanple if you are using an EQ with 2 bands enabled and a filter, when you switch same rates you have toggle the bands and filter off and on to reload the right files for the new rate. Otherwise the band's frequency gets shifted by the multiple difference of the same rate change (eg. if you go from 48 to 96, all bands actual processing frequencies will be double what they were at 48, howeve the actual GUI control will not reflect this).

This is apparently an known issue with Acquas and AA doesn't want to fit it. So, that's the work around. I have yet to confirm if this toggle works with the compressors and preamps.

The other issue is related to recalling the set settings between sample rate changes. Many Acquas have this bug but the exact list of those affected is unknown to me right now. AA is appanrely working on it.

So keep these limitaitons in mind if your worklfow involves working in multiple rate or if you changed your system rate with a project open, it may screw up all your settings. The exact nature of the issue is also DAW depenedent so switching back to the original rate may not work as expected. I haven't seen any conclusive testing and reporting on this yet: It should come from AA but they seem to prefer to back away from these issues leaving customers to try and figure it all out for themselves.

[0degree]

Some pretty big bugs/limitations with Acquas have come up and are being discussed on GS. Just reporting here that if the sample rate of a project changes, Acquas can not be relied on to work properly at the new sample rate. Every module/band will need to be turned off and back on again. For exanple if you are using an EQ with 2 bands enabled and a filter, when you switch same rates you have toggle the bands and filter off and on to reload the right files for the new rate. Otherwise the band's frequency gets shifted by the multiple difference of the same rate change (eg. if you go from 48 to 96, all bands actual processing frequencies will be double what they were at 48, howeve the actual GUI control will not reflect this).

This is apparently an known issue with Acquas and AA doesn't want to fit it. So, that's the work around. I have yet to confirm if this toggle works with the compressors and preamps.

The other issue is related to recalling the set settings between sample rate changes. Many Acquas have this bug but the exact list of those affected is unknown to me right now. AA is appanrely working on it.

So keep these limitaitons in mind if your worklfow involves working in multiple rate or if you changed your system rate with a project open, it may screw up all your settings. The exact nature of the issue is also DAW depenedent so switching back to the original rate may not work as expected. I haven't seen any conclusive testing and reporting on this yet: It should come from AA but they seem to prefer to back away from these issues leaving customers to try and figure it all out for themselves.

They definitely should sort out their QA team, it's really annoying to have all those bugs in plugins that are not exactly super cheap. Loos like this new bug affects like half of their plugins and nobody on their side bothered to do testing to catch this?

[plexuss]

They definitely should sort out their QA team, it's really annoying to have all those bugs in plugins that are not exactly super cheap. Loos like this new bug affects like half of their plugins and nobody on their side bothered to do testing to catch this?

From what I gather this bug, call it the "sample rate frequency shift bug", that moves EQ and harmonics frequencies around is something AA knows about and doesn't want to fix. Giancarlo recently posts some typical AA strawman points on GS. The usual "we want to avoid CPU spikes and loads" BS.

Some support changing the rate at runtime, some do not. Apparently, this is always an easy operation to do, but often it's easy to forget that reloading all plugins of a session at a different rate can become catastrophic if there are many open plugins and if in our case we have to load all samples from scratch while the audio continues to be processed. Imagine you have many plugins open, and you change the rate of all of them at the same time. For our products, this results in massive loading, which often ends in a crash because the system resources run out. This is one reason why we used to avoid this feature, which is triggered by a tag in our plugins. Lately, computers are faster and hosts are more reliable, so we're introducing this feature more and more often, hoping it won't create more problems. Let's take a practical example: sometimes users synchronize their clock to an external clock, which continuously communicates microscopic variations in sample rate. This can lead to a system that stops responding because all plugins are busy changing the rate all the time. Fortunately, hosts are getting smarter and lately, the rate change happens at specific times, e.g. at a suspend/resume of resources (when doing start/stop).

So we can't rely on AA to address and fix this BUG. But we can figure out a work-around so we can at least work with them. And, of course, keep warning people about all this so they don't end up spending money on something that will frustrate them like it does us.

[plexuss]

For the Acqua "sample rate frequency shift bug", where when the product sample rate is changed some Acquas will shift the frequencies of their bands and preamps will shift their harmonics, a work-around is: in the new sample rate toggle on/off all the bands, filters and preamps individually in each instances. I did some analysis of compressors in PluginDoctors and did not see an effect on threshold or dynamic timing however to be safe I'd say also toggle on/off compressors. Toggle from the AA GUI, not bypass or using the DAW as this will not re-load the correct files (aka kernels) into the plugin. AA can't say which products are affected and which are not so it's best to assume all are affected.

The other bug being looked at is the "recall bug" where some Acquas will not reliably load the previous session settings. AA is appanrely working on this one.

[0degree]

For the Acqua "sample rate frequency shift bug", where when the product sample rate is changed some Acquas will shift the frequencies of their bands and preamps will shift their harmonics, a work-around is: in the new sample rate toggle on/off all the bands, filters and preamps individually in each instances. I did some analysis of compressors in PluginDoctors and did not see an effect on threshold or dynamic timing however to be safe I'd say also toggle on/off compressors. Toggle from the AA GUI, not bypass or using the DAW as this will not re-load the correct files (aka kernels) into the plugin. AA can't say which products are affected and which are not so it's best to assume all are affected.

The other bug being looked at is the "recall bug" where some Acquas will not reliably load the previous session settings. AA is appanrely working on this one.

That's really bad - so now what should I do? Do one hour beta testing before I start working with those plugins and make sure they work as intended? Does it mean I can't change sample rate in my DAW or should reload everything after the change?

The recall bug is even more horrible - I feel sorry for the engineers wasting their time trying to figure out why their mix sounds off when going back to it. What is even worse - according to OP on GS the issue was ignored by AA during and before beta testing phase
This doesn't sound too professional to me

[MogwaiBoy]

But if you stay in the same samplerate, it's fine? It's only when you move between samplerates? Who does that - maybe 48k mix session / 96k master session? Wouldn't they be completely separate sessions, each one "native" to itself? I never change samplerates in the middle of a project.

[plexuss]

But if you stay in the same samplerate, it's fine? It's only when you move between samplerates? Who does that - maybe 48k mix session / 96k master session? Wouldn't they be completely separate sessions, each one "native" to itself? I never change samplerates in the middle of a project.

I do. I track and mix in 44 to conserve CPU then I switch to 96 to render the mix. Most of the time it works but sometimes it doesn't usually because of some plugin/s that dont work properly at higher rates or dont switch rates properly. But this doesn't happen often and when it does I let the dev know and they fix it. No muss. No fuss. I am using primarily software instruments as my source and these can benefit sonically running at higher rates, if they are implemented properly to work at different rates.

But with AA....

[dionenoid]

But if you stay in the same samplerate, it's fine? It's only when you move between samplerates?

No. If you work on any other samplerate than 44.1, chances are that your AA plug-ins will not recall correctly. Noticeable especially with frequency shifting of eq's.

There are 2 issues happening with AA right now : The "recall" issue and the "samplerate switching" issue.

That is, ofcourse, aside from all the usual issues that are becoming too many too mention.

[pixel85]

Some pretty big bugs/limitations with Acquas have come up and are being discussed on GS. Just reporting here that if the sample rate of a project changes, Acquas can not be relied on to work properly at the new sample rate. Every module/band will need to be turned off and back on again. For exanple if you are using an EQ with 2 bands enabled and a filter, when you switch same rates you have toggle the bands and filter off and on to reload the right files for the new rate. Otherwise the band's frequency gets shifted by the multiple difference of the same rate change (eg. if you go from 48 to 96, all bands actual processing frequencies will be double what they were at 48, howeve the actual GUI control will not reflect this).

This is apparently an known issue with Acquas and AA doesn't want to fit it. So, that's the work around. I have yet to confirm if this toggle works with the compressors and preamps.

The other issue is related to recalling the set settings between sample rate changes. Many Acquas have this bug but the exact list of those affected is unknown to me right now. AA is appanrely working on it.

So keep these limitaitons in mind if your worklfow involves working in multiple rate or if you changed your system rate with a project open, it may screw up all your settings. The exact nature of the issue is also DAW depenedent so switching back to the original rate may not work as expected. I haven't seen any conclusive testing and reporting on this yet: It should come from AA but they seem to prefer to back away from these issues leaving customers to try and figure it all out for themselves.

They definitely should sort out their QA team, it's really annoying to have all those bugs in plugins that are not exactly super cheap. Loos like this new bug affects like half of their plugins and nobody on their side bothered to do testing to catch this?

I think I read it some time ago on their "happy AA users on Xanax" group on FB, that early adopters serve as beta testers: you get plugin cheaper, but you serve as a beta tester, and you deal with eventual issues - a happy compromise
Dunno if they have any other QA besides that.

[The_Ogre]

I think I read it some time ago on their "happy AA users on Xanax" group on FB, that early adopters serve as beta testers: you get plugin cheaper, but you serve as a beta tester, and you deal with eventual issues - a happy compromise
Dunno if they have any other QA besides that.

Damn! That is for the stone-hearted ones only. My ears has not improved that much yet, and I don't know if I have patience to serve as a beta tester. Just look this situation with the sample rates issue. I should congratulate the users who managed to discover this, because I'm still in doubt if I perceived that there was something strange or if I was thinking it was just my untrained ears playing tricks on me.

I was thinking to get the Snow, but it seems it's still too CPU intensive (maybe it isn't the definitive version yet) and I probably wouldn't be able to find any issue that easily - not yet, as I'm still trying to improve my skills in the art of recording.

[plexuss]

I think I read it some time ago on their "happy AA users on Xanax" group on FB, that early adopters serve as beta testers: you get plugin cheaper, but you serve as a beta tester, and you deal with eventual issues - a happy compromise
Dunno if they have any other QA besides that.

Damn! That is for the stone-hearted ones only. My ears has not improved that much yet, and I don't know if I have patience to serve as a beta tester. Just look this situation with the sample rates issue. I should congratulate the users who managed to discover this, because I'm still in doubt if I perceived that there was something strange or if I was thinking it was just my untrained ears playing tricks on me.

I was thinking to get the Snow, but it seems it's still too CPU intensive (maybe it isn't the definitive version yet) and I probably wouldn't be able to find any issue that easily - not yet, as I'm still trying to improve my skills in the art of recording.

I was working on the below track when I discovered there was a sample rate problem with Snow. I put Snow EQ on each of 8 tracks on the mix and EQed accordingly, while in 44k. Then as part of my workflow I switched to 96k for the final render. I usually then do QA and listen through the render. I also compare to previous versions of the mix and also look at the spectrograph. On listening I could tell something was not right as the mix sounded different at 96 than 44. But on the spectro I could see brickwalling at 44k. So I posted about it on GS...

The next post on GS was from kuulart who specifically showed that the EQ curves were shifting. I didn't go so far with my analysis to find that but the shifting is what was changing the sound of the mix for me. kuulart wasn't responding to my post but discovered this on their own coincidentally.

FYI This is the track, with a "real" 96k master render, with Zynaptiq SRC down to 44/24 and of course Soundcloud takes care of the streaming compression:


https://soundcloud.com/musicofplexus/blue-dream

[JerGoertz]

https://soundcloud.com/musicofplexus/blue-dream

Nice song!

[plexuss]

https://soundcloud.com/musicofplexus/blue-dream

Nice song!

+1 very nice, sounds amazing.
It reminded me the of the days when I used to listen to System 7.

Thanks Buds!