Does everyone turn HISE_COMPLAIN_ABOUT_ILLEGAL_BUFFER_SIZE off?

[dannytaurus]

I'm seeing FL Studio complain about illegal buffer sizes. Claude investigated and said (my summary):

• FL Studio is know to give plugins their own buffer size, regardless of the main Buffer Length setting
• This was an issue in HISE for a while back in 2022 and Christoph added the UI-blocking warning message
• Handling of illegal buffer sizes has since been fixed in HISE, but the UI-blocking message was never removed
• It can be disabled with HISE_COMPLAIN_ABOUT_ILLEGAL_BUFFER_SIZE=0
• Apparently, the audio is not affected and the instrument functions properly

So, does everyone just set HISE_COMPLAIN_ABOUT_ILLEGAL_BUFFER_SIZE=0 and get on with their lives?

Is it time for this preprocessor to default to 0 instead of 1?

[David Healey]

@dannytaurus I don't touch it. I thought it was still an issue in FL Studio.

In fact recently a user sent me this message

Rhapsody kept crashing in my FL Studio until I toggled the "use fixed buffer size" on. Now it's smooth and fast.

Along with this:

[dannytaurus]

@David-Healey I just tested Rhapsody in FL and it didn't show the UI-blocking message. I wonder why?

If you haven't set HISE_COMPLAIN_ABOUT_ILLEGAL_BUFFER_SIZE=0 in your export then I would expect it to show.

I already confirmed the 'Use fixed size buffers' toggle fixes the issue, but I don't particularly want to send my customers to a 'Troubleshooting' page to fiddle with settings, and also be shown this message:

I just tested exported AU and VST with HISE_COMPLAIN_ABOUT_ILLEGAL_BUFFER_SIZE=0 and they both seem to operate fine. That test, along with Claude's assurance that the issue has long-since been dealt with in HISE source, is good enough for me.

[dannytaurus]

@dannytaurus Did your user give you any more details about the crashing in FL? I'd like to do some more tests.

[David Healey]

@dannytaurus said in Does everyone turn HISE_COMPLAIN_ABOUT_ILLEGAL_BUFFER_SIZE off?:

I just tested Rhapsody in FL and it didn't show the UI-blocking message. I wonder why?

I don't see it either. FL Studio is so temperamental, I have another user who gets this

[dannytaurus]

@David-Healey

FL Studio is so temperamental

Ugh, indeed. And not really something I can ignore.

I just did a user survey and FL Studio users are 8%, third largest after Live 61% and Logic 14%.

[dannytaurus]

Here's a tiny PR that sets the macro to zero by default for instrument plugins.

If you set it yourself in the plugin preprocessors, that will override this default, so it's safe.

It uses the confusingly named FRONTEND_IS_PLUGIN (which returns false for instruments ).

https://github.com/christophhart/HISE/pull/1039

In 2022 Christoph said:

I fixed this recently so now it should cope with any buffer size you throw at it (with a slight performance hit at weird buffer sizes). You can safely deactivate the macro.
https://forum.hise.audio/post/59057

Since then the standard forum answer has been to set the macro to 0 (for example 8478, 12569).

[David Healey]

@dannytaurus I've noticed your Claude commits have a lot of comments. I've told mine to minimise them so it doesn't bloat the commits. Most of the time no comments are needed or only a single line.

[dannytaurus]

@David-Healey I like plenty of context in the commit and PR so they stand alone and I don't need to remember what caused it, why I fixed it, and what options we discarded.

What do you mean by 'bloat'? A couple hundred more bytes of text?

[David Healey]

@dannytaurus said in Does everyone turn HISE_COMPLAIN_ABOUT_ILLEGAL_BUFFER_SIZE off?:

What do you mean by 'bloat'? A couple hundred more bytes of text?

When I'm reading through code I find comments get in the way, I lean more towards self documenting code. In general the HISE codebase is self documenting with very few comments, but sometimes a line or two can help. I think the commit message provides more detailed context when needed.

[dannytaurus]

@David-Healey Oh, you mean comments in the code! I thought you were talking about commit and PR messages.

I checked the comments in my last two PRs and stand by them. I feel both require more explanation than the code alone provides.

With confusingly named stuff like FRONTEND_IS_PLUGIN you have to write a comment, because that macro name is the very opposite of self documenting code!

And FL Studio is a special case where the UI warning message is misleading because FL provides per-plugin buffer sizes.

I'll ask Claude to keep comments restricted to explaining non-obvious or contradictory things.

[dannytaurus]

@David-Healey Done

• ABSOLUTE RULES now has a MINIMAL CODE COMMENTS entry. It says to comment only what is non-obvious, contradictory, or missing from self-documenting code, to keep needed comments to one line, and to point at the forum topic or GitHub issue/PR for more context.
• Comments & Documentation under Code Style carries the detail with three examples. The FL Studio comment from PR 1040 and the instrument-plugin note beside the confusingly named macro in PR 1039 are listed as good comments. The multi-line host-echo paragraphs from PR 1037 are listed as too much, with the one-line-plus-reference guidance. It also bans comments that restate code, narrate control flow, mark edits, or leave investigation notes behind.