@MikeB

Beyhan, 38, Turkey.

Chemical engineer MSc, Mixing engineer, Graphic designer, Music Producer (Electronic Music & Trailer Soundtracks)

Feature request

It's actually compatibility request. Native Support for Apple ARM cpu computers.

Basically Done - it's not 100% stable, but I can compile a few example projects for M1.

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.

Feature Request:

HQ Wavetable Synthesis with audio import function and similar (LAF adjustable) display below:

Bug Report

Latency Issue on FL Studio: When Delay Compensation is used, there is a big latency only in FL Studio. (Other DAWs are fine with delay compensation)

Bug Report

Write Automation Issue on AU Plugins: Write automation doesn't work in exported AU plugins. Read Automation works. (only AU plugins)

Hi everyone

I want to share some snippets that might be useful for you. I plan to share some stuff periodically. If you want to share yours, you can share here too, so all of the useful stuff will be in one place.

This is the first one, there are 57 vectorized icons (Bootstrap 3 Glyphicons) that I converted to the vectors in Hise, you can use them in your plugins

NOTE: Since the snippet has too many characters to write here, I am adding a text file below.

Cheers

1 - Vector Icon Set:

1_Vector_Icon Set.txt

Merry Christmas! Happy New year...

Bug Report

Multi Instance Crash: There is no issue while opening the multiple plugin instances in the DAW. But when the project saved, closed and opened again, DAW crashes. Probably MoodyChamels Queue issue in Hise.

Sometimes just 4 plugins causes the crash but no crash with 20 plugins in the same computer. Very random issue.

For that, you need an endpoint link in your server. If you use wordpress, you can make WP REST API endpoint yourself, and just use the wp_mail function to send the email.

But sending emails directly from an app or plugin is very risky. Because some email providers may filter that as spam or email never reaches to the other side. The worst, a hacker or spammer can exploit your endpoint.

So in my opinion, definately it is not secure. For emails, I would use only a link to your website's contact form page, or just write your email adress, that would be enough.

@ulrik Have you used ENABLE_ALL_PEAK_METERS=1 extra definition in Hise settings?

@ustk In old macs, XCode 12.2 which is minimum required version for M1 builds, doesn't work. And of course above 12.2 version doesn't work too

In my 2012 Mac mini, I use 10.3 in Catalina, it is stable. But once I tested before, Hise is working with XCode 12.0 and Catalina also. I am not sure if 12.0 is stable altough.

@d-healey said in Develop branch build status:

@orange 2018 Mac Mini, Big Sur.

XCode 12.5 can't being installed to a Mac mini 2012 Server version, Catalina is the latest compatible version for it.

@d-healey said in Develop branch build status:

12.5 working here. Just updating to 13 now, I'll let you know if it works.

Which Mac version are you using? Which year?

@Christoph-Hart said in Develop branch build status:

Ah good to know, I‘ll test it on my old systems.

In order to compile for M1 in intel macs, the minimum system requirment is XCode 12.2.

And on intel macs, XCode 12.2 is not working with Hise. If you can fix this, we can build for M1 in intel macs.

@Natan said in OpenGL ComboBox, And "NO" By Default:

@orange Mate, Saw A Post From You, Here
Did you get This Going?

Since the only way to see this combobox is to set HISE_USE_OPENGL_FOR_PLUGIN=1 , the combobox setting will be "true" by default.

Also, CustomSettings Floating Tile can't be saved in a preset. The value is stored in the GeneralSettings.xml file of the project in appdata folder.

So firstly, you need to use HISE_USE_OPENGL_FOR_PLUGIN=1 and build the plugin with that.

Then in order to make the OPEN_GL="0" on the plugin start, you need to distribute the modified GeneralSettings.xml file (with OPEN_GL="0" modification) to the appdata folder. with the installer. So while installing the plugin, this GeneralSettings.xml file will be created before the plugin initialization and plugin will start with OPEN_GL="0".

This is a cure for that slow macOS GUI performance, not ideal but it works. :

https://www.noiseash.com/knowledge-base/why-the-gui-controls-knobs-buttons-are-so-slow-and-laggy-in-my-mac/

@Christoph-Hart said in OpenGL Slows Down Everything On Multi Instances:

Yeah, my MacBook Air M1 is super slow with OpenGL enabled,

Since M1 MacBooks use Metal, a Metal support (in Hise) would solve this issue.

@Natan Is the issue operating system specific? And which graphic cards?

I've seen this issue generally on macs with Radeon GPU.

@d-healey Very informative as always, Thank you.