pixel85 wrote: ↑
Sat Apr 24, 2021 9:49 pm
The_Ogre wrote: ↑
Sat Apr 24, 2021 1:53 pm
plexuss wrote: ↑
Sat Apr 24, 2021 11:31 am
Just know there are those of us (me) that have and use AA products and enjoy them but simultaneous have little to nothing good to say about the company. We tend to keep a low profile for obvious reasons.
Same here! I'm a bit new to Acustica's world, as I changed my computer recently, and now I can use them. Unfortunately, earlier my old laptop didn't them very well, it struggled to run even the freebies, so I avoided to know them more. All I can say is, 'til now, I'm really liking their preamps and EQs, but their comps are kind of trial and error (Coral, Pink and Aquamarine are the ones I'm liking the most). I can't say where, but I think they still need to improve somewhat these ones.
I was in the similar situation recently. I built new powerful PC, happy to finally be able to use a lot of AA plugins without seeing my CPU crying in pain
... But I'm Cubase user and I find out that their plugins crash Cubase when there's around 12x same AA plugin in tge project. So not much use of new PC for AA. Then I saw in their group on FB, how anyone who said anything about Cubase/AA issues to be treated like a pest and lethal enemy. With AA response that "Cubase bad, we innocent"
Their only solution is to use Reaper. I'm not gonna do it. I know Cubase so well, with muscle memory gained over the years, it's the fastest DAW for me to use so I'm not gonna change DAW to Reaper which UX doesn't work well with me. Even my wife use Reaper (on Mac) but for me it's like using CAD or some advanced lab software
At the moment the "Cubase" error has been reported as fixed by everyone.
If there is still a problem please contact support, because the problem you are talking about is apparently closed.
On our products, there remains a limitation that only happens in windows on the number of total instances that can be opened now. We make extensive use of threads and some versions of windows are more limited than others by a counter called FLS, which is a number of allocable slots that change from version to version. This unfortunately is not something we can change, other than radically changing the architecture of what we are using.
About the Cubase problem specifically: actually it was a very rare problem that affected a very small part of the users. For example, we have at least 20 computers in our offices and we have never been able to replicate it. The error became particularly evident from one version onwards, and it was clearly identifiable because Cubase would crash when closing.
It wasn't just us involved, but other developers as well, and it went on like that for a while. We have been in contact with Cubase support for a long time to understand the cause, but the error happened AFTER the closure of one of our plugins, in a portion of code to which we do NOT have access.
So it's not that we wanted to evade the problem, but we didn't have the debugging tools, assuming we were at least able to replicate it.
It slowly emerged that the problem might have been related to an open-source library from Steinberg that we were using with other developers. Probably the handling strategy of DirectX is the same, and explains the reason why the error was visible only in Cubase.
Actually the graphics library forgot to release a library, and it was also a rather inconspicuous problem. We looked everywhere, but we never dreamed of looking in a graphic library for such a trivial error. Besides, debugging a library written by others is not exactly easy, especially if you don't know where to look.
Some developers upgraded to the latest version of this library and from there we realized that the problem could be related to it, and we started a slow debugging process. Upgrading to the latest version is easy when the library is used in a straightforward way, but usually, these kinds of releases are used by building components on top of it, which lose compatibility from one version to the next. This means that sometimes, to change the version, you have to rewrite or adapt the objects that were created on it.
It was easier for us to debug, and we assume that we will switch to another library for this section as well (actually we already used the other library for other sections).
Since we corrected the problem we realized that the plugins worked better also in other very old hosts (e.g. a spectrum analyzer) that had given us crash problems in the past. In that case we had blamed their unmaintained code.
After correcting the problem some users also confirmed a zero crash in other sequencers: in that case we blamed the crash on specific plugin problems, sometimes random and which we fix from one engine version to another. From there we realized that the problem was widespread.
These kinds of problems are intermittent and it's usually difficult to understand the cause. People who don't know the process think that it is always our responsibility or power to understand the source of the problem, but in this case without having access to other people's code we were entering an area where it was difficult to understand the problem.
In fact, we can understand a resource release problem in the following ways
- an area of memory is not released, for example, a memory leak. In this case, we can verify that all the memory is released. This happened, so we were comfortable
- by debugging our code at the crash point. The problem, in this case, is that the crash occurs in portions of the code that are not ours. For example, the spectrum analyzer was crashing randomly when it too was releasing resources.
The error, in particular, was related to a DirectX-related dll that simply was not deallocated, but theoretically was shared via a static object between all our plugins that used the same engine. So it was normal that it remained open, but it was not normal that at the closing of each instance it remained open again. When also Cubase released the same library probably in some circumstances something happened to block this closing mechanism because our processes had not released the dynamic library. The reason why it affected Cubase is simple: probably, being written by Steinberg also they used the same objects. Paradoxically, when they fixed the issue on their side the issue become more visible on our side.