Multi Instance DAW Crash Issue Guide

orange

Hi everyone

As you might know from the forum, in some plugins, there are multi-instance crash issues in all DAWs but mostly Cubase, Reaper, Studio One.

If the user inserts one plugin instance in the DAW project, it will be ok. But if the user inserts multi plugin instances (like 5 to 10), in some machines, the DAW project can not be opened again (no problem while inserting and using in the DAW project by the way, the only problem is about re-opening the DAW project again) and this is a nightmare for a user/customer also for you too as the plugin developer :)

These multi instance crashes can be inverse proportion. For example, DAW project may crash with only 3 instances of your plugin. But it may not crash with 50 instances :) Or vice versa. It's all about moodycamels queue issue with Hise.

Of course this issue is up to your code optimization. If the communication queue between audio thread and UI is full, that means your plugin is sending too many messages. These too many messages can cause a congestion / bottleneck and then the crash happens finally. The DAW project can’t be opened again!

I’ve been investigating this issue (also acording to the users’ feedbacks of course) for a while and I just wanted to share my observations with you. These are my experiments and observations. If you find out anything else please wellcome and share.

Please note that “Multi instance DAW Crash Issue” has no only one cause. This issue is the sum of various situations. If you will be careful about these causes, the crash issue can be reduced or even fixed. The main goal is making a very light cpu / ram user plugin. So, possible causes are described below:

Wrong If Statement usage

One cause is using too much sequential if statements in a wrong way. Just a quick example for wrong usage:

if (value == 1)
{
Do something
}

if (value == 2)
{
Do something
}

if (value == 3)
{
Do something
}

if (value == 4)
{
Do something
}

In above code, since each if statement will be checked and that will cause too much message during the initialization. Instead of the sequential if statements, this implementation should be done like that:

if (value == 1)
{
Do something
}

else if (value == 2)
{
Do something
}

else if (value == 3)
{
Do something
}

else
{
Do something
}

Now it is correct. With using else if, when the condition complies it will exit the statement and each if statement won't be checked. This will massively reduce the clog and the plugin will be much more tranquiled, relaxed :) Alternatively you can use switch / case statements for this purpose too.

setAttribute:
Another cause is the amount of used setAttribute APIs. More setAttribute you use, it means the plugin probably will crash more likely in multi-instances. (Remember sending too many messages). Of course you will need to use it in most cases. But if there is a case that you can live without using even one line, try not to use it. Do not over use setAttribute in your code and be careful while you use it especially in an array usage.

Shared Functions:
Shared functions have been used in various places in the same plugin. If these functions have lot's of setAttribute APIs, and if you used multiple shared functions in one GUI element (for example Link Button), the plugin tends to crash in multiple instances of course because of the bottleneck on the initialization.

Image size:
Total used image size is very important too. Please note that, even if you compressed images and the size is reduced; it doesn’t matters! On the exported plugins, the image will take it’s normal place inside the memory like it’s not compressed, as big sized bitmaps. So be careful about image dimensions and formats. For example if your background image doesn’t have transpency, there is no need to use it as.png file. Instead, use as jpg. Because .png files can be 3 or 4 times bigger than jpg files. Using jpg files will end up big bitmaps too but at least you will not get "Heap is Out of Space" error while compilng.

Also avoid using big pixel sizes. For example if your GUI canvas size is 1000 x 600 pixels, there is no need to use 5000x3000 pixels :) Try to sharp the pixel sizes too, as much as you can. For knobs, calculate the optimum frame size for your GUI mesaurements and then prepare the imagestrip acording to this size. Don’t use oversized image strips. We need to make a very light cpu and ram sucker plugin :) Acording to my observations, going above the 15MB total image size, the multi instance crash possibility will be much more higher :)

Deferring Callbacks:
It’s not the ultimate cure for the crash issue but it can be a big improvement for some situations. Search forum for the usage of deferred callbacks. Also if you can reproduce the crash issue in your system, try using and not using plugin exports individually. Observe the impact, if deferring callbacks makes the improvement, use it. Also multi instance DAW testing is a good idea, save multi plugin opened DAW sessions individually (like 5 instances, 10 instances or 30 instances) and try to reopen them :)

Timer Objects:
Over used Timer objects can cause problems too. Especially very short times like 10ms, 20ms….etc.

Simple Serial Copy Protection:
If you are using thousands of long serial number batches in your plugin, since these thousands of serial numbers will be checked in every initialization, it can cause crashes. Instead of using thousands of lines for the serial copy protection, use the formula technique for serial number usage. Or make the serial check once a day.

OpenGL

If your plugin uses lot's of live analysis, vector based animations...etc, using OpenGL will be a good improvement. But if your plugin doesn't use stuff like that, it will has no impact, in some conditions also negative impact like black screen, not loading the plugin, extra crashes.... etc.

LeeC

@orange massively appreciate you sharing this info!

Natan

@orange Thank You Orange, I Did All The Testes You Mentioned, And Looks Like I'm In A Safe Side.
BTW, Play With Your Plugin For More Than A Month At Least, Then Do Release.
Try As Much Scenarios As You Can, Like Open / Close / Open / Close...
People Are Doing Crazy Stuffs With Audio Plugin Nowadays, Take A Look At The Video Below:

ulrik

@orange Great information, thanks a lot! :)

Dan Korneff

@orange said in Multi Instance DAW Crash Issue Guide:

Instead, use as jpeg

Are we able to use JPG? I thought PNG was the only option.

Dan Korneff

just tried... it worked

Sawer

@orange Thanks for this. Is there a way to create custom knobs with Hise (panel.setPaintRoutine) without to use knobman or any other software?

Thanks

d.healey

@nesta99 Custom Look and feel, or panels and paint routines.

Jpeg/png shouldn't make a difference because they'll both end up as bitmap.

Sawer

@d-healey Ok, thanks so much! Will be working o this today.

Fortune

Thank you man for this great guide Amazingly useful!!!!

Like you've suggested, for test purpose I removed some setattributes in my code and the crash issue almost fixed interestingly. Why is this happenning?

Sawer

It will be awsome if you end up using Panels, Paint Routines and Custom Look and feel for EVERYTHING (animations, knobs, callback animations etc), so that you won't relay anymore on images or rlottie and other 2D/3D softwares graphic softwares.

Just like Web UI, UX interactions. Can this be possible in future or its already possible with more tests and knowing HiseScript? Just a curiosity

orange

@Fortune said in Multi Instance DAW Crash Issue Guide:

Like you've suggested, for test purpose I removed some setattributes in my code and the crash issue almost fixed interestingly. Why is this happenning?

I remember @Christoph-Hart was saying that is about the moodycamel queue that shares the same UI thread. So it is more open to clogging in multi-instances and because of this too many messages situation.

Dan Korneff

@orange said in Multi Instance DAW Crash Issue Guide:

Number one cause is the amount of used setAttribute APIs

@orange @Christoph-Hart does this also include setValue()? If not, I might use scripts to set the value of panels, and then us the Panel Property Editor to assign Processor/Parameter IDs.
Can panels even do that?...

LeeC

@orange @Christoph-Hart
I know it depends, but is there a ballpark number for the amount of setAttributes we should be using simultaneously?

Also, would using the showControl instead of set("visible",value); to toggle visibility of components help to avoid crashes aswell?

d.healey

This sounds fishy to me. Setting attributes shouldn't be causing any issues. I suspect there are other problems with the scripts.
Are you setting attributes only in deferred scripts?
Are you setting attributes in MIDI callbacks or timers?

orange

@dustbro said in Multi Instance DAW Crash Issue Guide:

@orange said in Multi Instance DAW Crash Issue Guide:

Number one cause is the amount of used setAttribute APIs

@orange @Christoph-Hart does this also include setValue()? If not, I might use scripts to set the value of panels, and then us the Panel Property Editor to assign Processor/Parameter IDs.
Can panels even do that?...

Since generally I use setAttributes, I haven't made experiments with setValue() & Panels.

But setValue should be ok I think.

orange

@LeeC said in Multi Instance DAW Crash Issue Guide:

@orange @Christoph-Hart
I know it depends, but is there a ballpark number for the amount of setAttributes we should be using simultaneously?

Also, would using the showControl instead of set("visible",value); to toggle visibility of components help to avoid crashes aswell?

I haven't seen any issues yet with using too many showControl or set("visible")... stuff. For multi-instance crash you need to make experiments with beta testers.

orange

@d-healey said in Multi Instance DAW Crash Issue Guide:

This sounds fishy to me. Setting attributes shouldn't be causing any issues. I suspect there are other problems with the scripts.

It's been covered here by @Christoph-Hart befrore: https://forum.hise.audio/topic/2826/debugging-with-reaper/25

You can use as many setAttributes as you can, it's not a problem on most systems. But the issue is "Multi Instance DAW Crash" in "Some Systems".

That doesn't mean it happens in all computers. But if you see this in a computer, it will do that crash in all DAWs :) You know what: while I haven't seen any multi instance crash in my 7 years old laptop, some users were repoting this issue to me. Honestly I couldn't replicate it. Then I got a new Intel 10th generation i9, 128GB RAM, 12GB NVidia 2080Ti computer, then guess what: it crashes for 5 plugins :) Same plugin, new system.

Are you setting attributes only in deferred scripts?

Yeah, I am using it in main interface script only. But the issue happens also with the plugin that uses only One Timer Object (100ms - on preset label only). Whole plugin is a Parametric eq, ShapeFX and setAttributes. Nothing more. I can open 20 instances in old pc, but crash for 5 instances in new one :) Crash reporting beta testers see the multi instance crash too.

This is more interesting, when the deferring callbacks are disabled, sometimes crash reduces :)

Are you setting attributes in MIDI callbacks or timers?

No.

Dan Korneff

@d-healey said in Multi Instance DAW Crash Issue Guide:

Are you setting attributes only in deferred scripts?

Synth.deferCallbacks(true);

This is the second line on my onInit. I don't need to call this on my separate "include" scripts, right? Those should be considered part of the Interface script.

d.healey

@dustbro Correct.

Could someone create a minimal example project that consistently demonstrates the issue?

Multi Instance DAW Crash Issue Guide

41

1.7k

11.7k

101.9k