u-he Plugins Causing Freezing / Crashing in FL Studio 20.8.4

[tasmaniandevil]

I will try to install the latest versions of Hive and Repro again when I am finished with my track.

We are still trying to reproduce those issues, so we can properly investigate the problem.

What you could try once you reinstalled the latest version of Hive would be to activate the "use fixed size buffers" option in the Troubleshooting section of the FL plugin wrapper settings of Hive.

FL Studio's unique audio engine has often caused trouble in the past, and this option is very often the key to avoiding such problems.

[2NDMOUSE]

I haven't had any issues with any U-he plugins and have most of them, and been using them for years now, but I've bought repro recently and since I've bought it it's crashed 5 times. 2 of those were today and it was doing something really simple like changing a preset as the track was playing. Another time it was changing the wave shape from square to saw.
In each case, the sound cut out completely. I could see FL's play marker was still moving, and then FL crashed. I own hundreds of plugins, and FL is rock solid now and never crashes, so this is unusual.
All my plugins are installed on the C drive, and it's pretty much a clean system.
It was the 64bit vst2 that crashed today, so I changed to the 64bit vst3 and it crashed again.
I filed a ticket, but i've now lost confidence in Repro and won't use it again as it's not reliable....which is a shame because I love the thing and it was fast becoming my favourite.

I have filed a ticket after it crashed a few hours ago, but now that its crashed again, I wanted to see if anyone else was having issues and wound up here where it seems it's not an isolated incident.
Please fix this and restore my faith in Repro because I cannot use it like this, and it's too late for me to ask for a refund.

[Urs]

These things are usually quickly resolved by our support team (which opens ops back up when the week starts in half a day)

[tasmaniandevil]

It's another one of those "FL Studio only" glitches, happening because of the very special audio engine they have.
To avoid those random FL Studio freezes, please use this workaround:
In the plugin wrapper settings, switch on the "use fixed size buffers" option.

[surreal]

Hi! Any solution to this? I'm experiencing the same thing with Hive 2 and Repro (VST3 versions). For me it happens when clicking in the channel rack of FL Studio to open the GUI. Sometimes it works, but often FL Studio just freezes. Reinstalled the previous versions of the plugins and it does not happen there. It does not seem to happen with Diva and Colour Copy. I contacted Image-Line support and got an answer back about trying some graphics settings, but I don't want to install the latest version of the plugins again if it starts to freeze again.

Hi Mellis
Can you please tell us what Image Line recommended with the graphics settings?

[surreal]

The way I am reading this is that sounds like the latest Fl updates also calls in the Avx and Sse4 instructions that is clashes with the newer instructions and optimisations that Urs had implemented. I think this might be related to the same issue that exists with IL and another developers synths where the gui is lagging.. definitely FLS is the common denominator here and IL must look into this

[Urs]

There's a possibility that it's related to expectations by the host that rendering, say, 8 samples takes exactly an 8th of the time of rendering 64 samples. This is not always the case. Pretty much every plug-in developer uses some internal block size to optimise the CPU of their plug-ins. This is called block processing and it is the only way plug-ins like Diva or Repro can run on today's computers. Our internal block size is 16 samples, and we further optimise this by processing up to 4 such blocks at once.

However, FL Studio - like probably few other hosts - does a clever trick by slicing process buffers into smaller units to make parameter automation more accurate than what's possible (or common) with VST plug-ins. Some of these slices can have the length of 1 sample. Most of these slices don't use any CPU, because we need to accumulate them until there's 16 or more samples. But sometimes we get a 1 sample process call that happens to fill our buffers with the 16th sample. In that case, while the host expects the CPU of 1 sample, we process 16 samples. Even if it happens at a slice of 8 samples, the CPU used is still 2 times as what the host might expect. And thus there are synchronisation issues.

I assume that this is the root cause of issues with hosts that do adaptive buffer slicing and plug-ins that rigidly process buffers in slices of 4, 8, 16 or even 64 samples. Pretty much all convolution reverbs and any other FFT based plug-in will work best with fixed buffer sizes that are a multiple of 16, or a power of two. They might even have to, due to the nature of their process. And so do our plug-ins.

I assume that is why setting "use fixed size buffers" resolves pretty much all of these issues.

[surreal]

There's a possibility that it's related to expectations by the host that rendering, say, 8 samples takes exactly an 8th of the time of rendering 64 samples. This is not always the case. Pretty much every plug-in developer uses some internal block size to optimise the CPU of their plug-ins. This is called block processing and it is the only way plug-ins like Diva or Repro can run on today's computers. Our internal block size is 16 samples, and we further optimise this by processing up to 4 such blocks at once.

However, FL Studio - like probably few other hosts - does a clever trick by slicing process buffers into smaller units to make parameter automation more accurate than what's possible (or common) with VST plug-ins. Some of these slices can have the length of 1 sample. Most of these slices don't use any CPU, because we need to accumulate them until there's 16 or more samples. But sometimes we get a 1 sample process call that happens to fill our buffers with the 16th sample. In that case, while the host expects the CPU of 1 sample, we process 16 samples. Even if it happens at a slice of 8 samples, the CPU used is still 2 times as what the host might expect. And thus there are synchronisation issues.

I assume that this is the root cause of issues with hosts that do adaptive buffer slicing and plug-ins that rigidly process buffers in slices of 4, 8, 16 or even 64 samples. Pretty much all convolution reverbs and any other FFT based plug-in will work best with fixed buffer sizes that are a multiple of 16, or a power of two. They might even have to, due to the nature of their process. And so do our plug-ins.

I assume that is why setting "use fixed size buffers" resolves pretty much all of these issues.

Really interesting, thank you Urs for the clarification!

[2NDMOUSE]

There's a possibility that it's related to expectations by the host that rendering, say, 8 samples takes exactly an 8th of the time of rendering 64 samples. This is not always the case. Pretty much every plug-in developer uses some internal block size to optimise the CPU of their plug-ins. This is called block processing and it is the only way plug-ins like Diva or Repro can run on today's computers. Our internal block size is 16 samples, and we further optimise this by processing up to 4 such blocks at once.

However, FL Studio - like probably few other hosts - does a clever trick by slicing process buffers into smaller units to make parameter automation more accurate than what's possible (or common) with VST plug-ins. Some of these slices can have the length of 1 sample. Most of these slices don't use any CPU, because we need to accumulate them until there's 16 or more samples. But sometimes we get a 1 sample process call that happens to fill our buffers with the 16th sample. In that case, while the host expects the CPU of 1 sample, we process 16 samples. Even if it happens at a slice of 8 samples, the CPU used is still 2 times as what the host might expect. And thus there are synchronisation issues.

I assume that this is the root cause of issues with hosts that do adaptive buffer slicing and plug-ins that rigidly process buffers in slices of 4, 8, 16 or even 64 samples. Pretty much all convolution reverbs and any other FFT based plug-in will work best with fixed buffer sizes that are a multiple of 16, or a power of two. They might even have to, due to the nature of their process. And so do our plug-ins.

I assume that is why setting "use fixed size buffers" resolves pretty much all of these issues.

Thanks for setting aside time to explain that. I always wondered what "used fixed sized buffers" meant. I assumed it was something like treating a 64bit plugin as if it were a 32bit, or some kind of "safe mode" with rounded corners to stop people injuring themselves =P
I own hive, ace, bazille, diva and zebra, and use all the free Poldolski, Tyrell, Zebralette etc....too, and i've never had an issue in a few years, until this new issue with Repro-1.
I remember in the early days of FL, it crashed a lot, but they really got their act together and a crash is a rare event now, so I was really surprised when it was a U-He synth that was involved, due to the complete lack of crashes until now.

[saintjohnbaxter]

I've noticed this a lot since the latest update to FL. Repro-1, Hive and Diva crash/crash the DAW (not immediately) but after some interactions with the GUI. I noted it only seems to happen when the transport is running, and thus audio being processed. Use fixed buffer size fixes the issue. This never happened previously AFAIK, only since FL updated to 20.8.4. It doesn't happen in Live which is the other DAW I use regularly. I think Urs' explanation is the most likely.

[Teksonik]

I have the feeling but not the proof that FL has some issues in the latest versions. It's always been rock solid here but in the last month or so I've had more crashes than perhaps in the previous few years with three different plugins that never caused issues in the past.

Although I had one crash with Hive as I reported here on the first page of this thread my biggest issue was with a plugin from another developer. A memory leak was apparently the reason for that and a recent plugin update appears to have fixed it at least so far.

However there have been several support posts at the IL forums recently documenting crashes with various plugins but unfortunately the attitude of their first level support staff is it's always the plugin's fault then they mark the issue as solved.

The more serious issue I had only happened in FL Studio and not in any of the other four DAWs on my system under the same testing conditions. "Use Fixed Size Buffers" on/off made no difference with the non-U-he plugin.

Anyway I'm kind of trying to track or document recent reported issues with FL Studio to see if I can spot a pattern. It's my most used DAW and I'd like to help ensure that it goes back to being stable as before.

[saintjohnbaxter]

However there have been several support posts at the IL forums recently documenting crashes with various plugins but unfortunately the attitude of their first level support staff is it's always the plugin's fault then they mark the issue as solved.

I hadn't reported at the IL forums for much the same reason.

I have noticed Geist2 crashing a lot lately also and it was always very solid before the latest update. That one's a bugger cos it's the first plug-in that loads in everything I do.

[Teksonik]

All we can do is make a post in their Technical Support forum. They have a tendency to set those posts as private at first supposedly to protect user's private information but it really helps if other users can see those posts as they might have the same issue.

The more people that post issues the more they are likely to accept there may be issues introduced in later versions of FL and pass the information on the the guys who write the code.

[Urs]

You can always just use "fixed buffersizes". Fixed. Fixes it

[Teksonik]

Not always. It didn't help with the problem I was having with another developer's plugin. On/off didn't make a difference.

I'll have to check my studio computer but on this one both Hive 2 and Zebra 2 are set to fixed size off and they seem to work fine but I don't do any composing on this system.

Hive 2 gets heavy work in the studio and other than the crash I reported on page one it's always been rock solid all the way back to version one.

I notice in Rob Papen's new Predator 3 plugin he's got a switch in options:

Predator.png

I assume that has something to do with buffers.

But yes fixed sized buffers is always the first thing to try in any plugin that doesn't play well with FL Studio.