Ableton Forum

First, plugin latency compensation and buffer size do work as expected in Live 6 and in Live 7, and as far as I know, they work the same. The buffer for a plugin is calculated when the plugin is created, so, yes, you need to reload your set OR delete/re-create a plugin, for a change of plugin buffer size to be taken in account.

I have to leave house now, but will prepare several audio-clips to demonstrate that Live 6 and 7 do not work the same when changing Plugin Buffer sizes and add some words of explanation to each clip.

Anyway I suggest to add some words of explanation to the Plugin Buffer settings to both the manual and the Preferences window that explains that you have to reopen all plugins once you change this setting.

Now, I'm not sure I get the thing with plugin buffer size and timing/attack? Do you mean that the attack time of plugins is dependent on the plugin buffer size?

Quite simple: If you have external plugins play short succession of notes (like drum-hits or even just a sinus-wave form) you will get audible sound-modulation of attacks at varrying rates. Changing the Plugin Buffer size changes the modulation rate. This does not happen if you play the very same audio-clip via an Audio track. And to make sure it's not the plugin's fault I played the same plugins via Reaper and no or maybe just considerably less audible modulation could be heard.

Again I will provide you with audio-clips, which I offered from the very beginning.

Timur wrote: Quite simple: If you have external plugins play short succession of notes (like drum-hits or even just a sinus-wave form) you will get audible sound-modulation of attacks at varrying rates. Changing the Plugin Buffer size changes the modulation rate. This does not happen if you play the very same audio-clip via an Audio track. And to make sure it's not the plugin's fault I played the same plugins via Reaper and no or maybe just considerably less audible modulation could be heard.

Again I will provide you with audio-clips, which I offered from the very beginning.

Does this happen if you play a voice of a VST instrument via an External Instrument, only, or even if you play it directly on the track?

Regards,
Amaury

Amaury wrote:Does this happen if you play a voice of a VST instrument via an External Instrument, only, or even if you play it directly on the track?

Happens with both! To make sure it's not due to looping I set up longer clips that play 1/16 notes in succession.

Here are the promised audio-clip (lame mp3 high quality, -12 dB!). These examples are not rendered, but recorded digitally through the Audio Console application of my Creative X-Fi as "What you hear". So this is exactly my speakers' output! Sounds the same through my Audiophile 24/96.

1. Pure Crash sample (1 voice, no overlays = retriggering)

1.1) Audio Clip: crash_120_audio.mp3 - 0.31MB

1.2) Battery, 1024 samples: crash_120_vst_1024.mp3 - 0.33MB

1.3) Battery, 512 samples: crash_120_vst_512.mp3 - 0.32MB

1.4) Battery, 256 samples: crash_120_vst_256.mp3 - 0.31MB

1.5) Battery, 128 samples: crash_120_vst_128.mp3 - 0.31MB


2. Cancellation of Audio track vs Battery track

Eventhough 128 samples sounds as if it is free of artefacts the cancellation test proves otherwise and gives some hints on that attack times vary with Plugin Buffer size:

2.1) 2048 samples: crash_120_cancellation_2048.mp3 - 0.11MB

2.2) 128 samples crash_120_cancellation_128.mp3 - 0.09MB

2.3) 32 samples, extra long to demonstrate extrem bleed-through: crash_120_cancellation_32.mp3 - 0.17MB


3. Non sample-based plugins = FM8 sinusoid wave (2 voices)

When playing only 1 voice of the Init sound of FM8 which is a simple sinusoid wave one will hear an ongoing tone as if a single long note is played. This makes sense and seems to be the right behavior. There are no gaps in between notes that would reveal any attack-timing issues.

As soon as 2 or more voices are played the modulation of the overlaying voices change in time, which is expected behavior because the overlays are not played at even orders of the sinusoid wave.

But that modulation also changes when Plugin Buffers are changed. And at buffer sizes lower than 1024 samples more and more clicks are produced which become clearly audible at lowest sizes. While these clicks could be due to FM8 performance issues/bugs I have to emphasize that Live's CPU meter never exceeded 5%.

Strange but true FM8 works better at high buffers sizes while Battery works better at low buffer sizes. As a comparison I have also recorded a FM8 track played through the DAW "Reaper". It resembles Live's high buffer size examples.

3.1) Reaper, source material buffer 0.64%, render ahead buffer 1ms: sinus_120_reaper.mp3 - 0.16MB

3.2) Live, switching Plugin Buffers from the range of 8192 downto 32 samples: sinus_120_live.mp3 - 0.45MB


Feel free to ask any questions! But keep in mind that I am not getting paid by your Quality Assurance team and not even own a full version of Live. So please consider having these tests done by your own (hopefully well-paid) technicians. This already took too much of my time...

Timur wrote:by your Quality Assurance team

I have come to believe that it does not exist.

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.

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. 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? How do you know you're recording an exact length to do cancellation tests? What's the process? 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.

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.

Regards,
Amaury

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.

This is rather facinating. I just popped into the bugs forum to report a phasing problem that occurs when trying to do parallel compression in Live 7 while using a send.

I wonder if anything here is related to that...

These issues are only (mostly?) related to external VST plugins on Windows (no idea about AU/VST on Mac). I assume that you are using Live's internal compressor? In that case you should not experience these issues (I did not test though), because internal plugins do not seem to be affected by the Plugin Buffer preferences at all and I assume they use a fixed size or maybe even no size at all.

Could someone from Ableton please clarify this point? Why are internal plugins not affected by the Plugin Buffer setting and what size of a buffer do they use instead? Or is it just that Simpler/Sampler are not affected?

And what about the new plugins/instruments which are obviously handled different from Ableton's own ones.

Ableton Support Email wrote:You were right about the memory allocating with Live 7, but there is a difference with the new instruments "analog","tension" and "electric". They do free up memory after deleting them, at least additional ram they did allocate on top of the already allocated ram by Live's devices.

Sounds a bit like these maybe running on their own thread just like any other third-party plugin?!

All in all Plugin Buffers implementation and behavior confuses me. The manual and helpfile is even more confusing, because the way Plugin Buffers are explained there sounds as if higher values would mean more samples being processed per second. It's generally vague and seems to imply to better forget about the existance of this setting all along to stay out of troubles. This part of the manual should be completely rewritten, even if only to include the fact that changing the audio-buffer size needs a restart of Live to make Latency Compensation recognize the corresponding change of Plugin Buffer size when the default setting "As Audio Buffers" is used.

So now that I have posted my test-setup, can you make anything out of it? Is this an acknowledged bug?

I am still waiting for any acknowledgement to this. Why do I go to length to provide audio-samples and everything when even two months later no one cares to reply anymore?