Amaury wrote:Hi Timur,
We'll investigate all of this in details. Quite a lot has already been done by our engine team guys, and we like to believe they know how to conduct a test.
Thanks alot, I appreciate the care, especially since these things
are important for me when working with a DAW.
The most important in that story, is to indeed know how to setup a test that's meaningful, and be very careful before making conclusions.
You are right, but then again, if anything behaves unexpected under normal circumstances aka not like it should then something is wrong. That part is quite simple.
For instance, do you know if the things you experience with plugins are caused by "dynamic" change of buffer size, by the way their engine was build, by their envelope?
Since I went to length and did some tests with restarting Live after chaning buffer sizes and play the very same plugins via another DAW and checked several different envelope settings I am at least quite sure.

By the way, when doing these tests I found a bug with Battery's envelope (Hold parameter behaves different with AHDSR vs AHD). Anyway, it can be completely switched off.
How do you know you're recording an exact length to do cancellation tests? What's the process?
No recording done, only live playing of premade samples taken out of Battery's sample-library.
Also, what to expect when doing a comparison of a sample played through a plugin, versus through an audio track? I'm not even sure myself.
That one is tricky. One cannot assume that a plugin will always play a sample neutral. But if I use a sampler (and Battery is just that) and switch off
all effects, envelopes and everything and play the sample at its original sample-rate then I expect it to play unaffected.
In this case however the main problem is not that the cancellation test did not work. In fact it
did work for almost all parts of the sample, but the attack obviously varries by quite a great ammount. Also the regular extrem bleed-through with the short sample buffer setting where you can hear almost the whole attack phase (instead of just some short pops/clicks) is worrying. Battery has not proven to be very bug-free software, so it's quite possible that it is to be blamed at least partly.
But again, I'd suggest you don't spend too much energy on this. As far as quality is concerned, we investigated a lot, I mean a lot of time and resources on that in the last development phase, and are confident that the expertise of the people involved is reliable. Nonetheless, we'll make sure we continue that work.
I do believe you and appreciate the effort and time your team invests into their product. Nevertheless this person (I) for some reason has a talent of finding bugs in all kinds of technical products. Maybe I tend to dig too deep into these things, maybe I am just less ignorant and more understanding of what's happening under the hood. Whatever I prefer reporting these things and try helping developers better the products
I need to work with than grumbling about it.
Most likely I am going to spend several hundred Euro on your products in a few days and from that point on I need them to reliably work. Unfortunately I have found several bugs, oddities or simply undocumented "habits" that I am not happy about. I have managed to crash Live 7 several times during only a few days work with rather small experimental projects (I still cannot save in my Demo version, so building something big is a waste of time atm). I want these things to be handled soon and I spent energy on helping you achive it.
