Linux Issues...

[Morphoice]

I've had multiple reports of my plugins not working in Linux, Reaper etc.
I#ve compiled them just the normal way (dsp first) with either GCC or clang on a debian 12 ser ver, no issues whatsoever, however i don't have a local linux machine nor all the various DAWs.
nor even the linux expertise to diagnose them

are there known issues with HISE plugins running on linux or can someone pinpoint me on what steps to take next to diagnose the problem? or are these probably edge cases. I can't get any more useful info out of those people rather than "the plugin just makes a crackling noise" or "the plugin has no ui in reaper, just a grey box"

[David Healey]

@Morphoice Find out what distro the people who are running into issue are using. Also which host.

[Morphoice]

@David-Healey Debian 13 and Reaper

[David Healey]

@Morphoice: Find out if you are compiling with a newer version of GLIBC - although since they are on Debian 13 I expect not. But first thing I'd check.

Run this on your server, and ask them to run it on their system too if you can

ldd --version

[Morphoice]

@David-Healey i'll see if anyone responds and ask them that.

[Morphoice]

nothgins so far except another guy on Reaper having issues. It's generally always Reaper (whatever that is) causing the problems.

I myself compiled with glibc 2.36 on Debian 12 (Bookworm)

[David Healey]

@Morphoice said in Linux Issues...:

It's generally always Reaper (whatever that is)

Reaper is a DAW, it's very stable so if a plugin fails there it's almost certainly a problem with the plugin. You should get yourself a copy for testing (unlimited free trial) https://www.reaper.fm/

@Morphoice said in Linux Issues...:

I myself compiled with glibc 2.36 on Debian 12 (Bookworm)

As long as they are on the same or newer version that won't be a problem.

[Morphoice]

@David-Healey I havent a linux system so there's nothing I can test sadly. Compilation was done on the server of a friend, I cannot run graphical software there. Im almost certain it is the deferCallbacks but I dont know if I can safely disable it or what else will break on pc/mac

[David Healey]

@Morphoice said in Linux Issues...:

I havent a linux system so there's nothing I can test sadly.

You can use a virtual machine. Or even spin up a cheap VPS on something like vultr.

[Morphoice]

@David-Healey Synth.deferCallbacks(true) is called in Interface.js This means ALL MIDI callbacks (onNoteOn, onNoteOff, etc.) are deferred to the message thread via the deferredExecutioner, right? and from reading through various webs that has issues with JUCE on Linux... can't verify though

[David Healey]

@Morphoice said in Linux Issues...:

Synth.deferCallbacks(true)

The UI script should always use this, and all my plugins use it, so this is not the cause of the issue.

Unless you can test and debug it I'd suggest pulling your Linux version.

[Morphoice]

@David-Healey Agreed. I'm curious as to what the real cause is but given only 0.3% of all downloads is linux, that's not really something I have the capacity to invest my spare time into...

[Morphoice]

@David-Healey said in Linux Issues...:

@Morphoice said in Linux Issues...:

Synth.deferCallbacks(true)

The UI script should always use this, and all my plugins use it, so this is not the cause of the issue.

Unless you can test and debug it I'd suggest pulling your Linux version.

the probably suspendState mechanism - suspends timers/deferredExecutioner when no editor is open
KillStateHandler stuck in Suspended state
which comes with the Silentsynth/Voicekiller construct I use to make faust-only synths

[David Healey]

@Morphoice If your customer is willing to be your tester then make the change and get them to see if it fixes it. Otherwise, without being able to test it's all just guessing.

[Morphoice]

@David-Healey right.

[Morphoice]

@David-Healey I've had a chance to look at it briefly at a friends PC who has Trixie installed and bitwig, the plugins load just fine and the ones with graphical drum pads do produce sound, but none receive midi... so i reckon the DSP and tone generation isnt the problem at all but the underlying JUCE framework isnt passing midi data along

one thing to note is that the midi indicator led i put in my guy does light up, but no sound. so actually the midi is not passed along to the faust automatically

[David Healey]

@Morphoice Must be something faust specific. Is it wrapped in a MIDI container? I could be talking nonsense here as I've not used it.

[Morphoice]

@David-Healey

The HISE export_ci process corrupted parameter values in the binary preset data (PresetData.cpp). All parameters within each HardcodedMasterFX/HardcodedPolyphonicFX node were overwritten with the last parameter's value. For one plugin, the Chorus effect's Volume was set to 0.0, which made pow(20, 2*0) - 1 = 0, multiplying all audio output by zero.

Fix: Wrote a Python script that decompresses the zstd-compressed binary preset (using HISE's custom dictionary), parses the JUCE ValueTree binary format, replaces corrupted values with correct ones from the XML backup, and writes back.

[Morphoice]

When running HISE export_ci on Linux (GCC 12, Debian), the generated PresetData.cpp contains corrupted parameter values for all HardcodedMasterFX and HardcodedPolyphonicFX nodes. Every parameter in each node is overwritten with the last parameter's value.

Reproduction: Export any project containing HardcodedMasterFX nodes on Linux. Compare the binary preset values against XmlPresetBackups/*.xml — they will differ.

Example (Chorus effect with 12 params):

XML has: Delay=5.23, ModAmount=1.0, ..., Volume=0.5, Noise=0.0
Binary preset has: Delay=0.0, ModAmount=0.0, ..., Volume=0.0, Noise=0.0 (all = last param value)
Impact: Plugins produce complete silence when a volume-like parameter gets zeroed.

Location: The bug appears to be in HardcodedSwappableEffect::writeHardcodedData() in HardcodedModuleBase.cpp, reading from the lastParameters MemoryBlock.

Workaround: Post-export script that decompresses the binary, patches values from the XML backup, and recompresses.

Platform: Linux only. macOS and Windows exports are correct.

[Morphoice]

@Christoph-Hart

There are two bugs in the "uncompiled effect" code path in restoreHardcodedData():

Bug 1 (Primary — line 982): v[up.getLast()] should be v[up[i]]

This reads the LAST property name for EVERY parameter index, causing all parameters to get the last parameter's value
Bug 2 (Secondary — lines 967, 563): lastParameters.setSize(numParameters) should be lastParameters.setSize(numParameters * sizeof(float))

The compiled path correctly uses numParameters * sizeof(float), but the uncompiled path allocates only numParameters bytes instead of numParameters * 4 bytes — a buffer underallocation
Why Linux-only: hasLoadedButUncompiledEffect() returns true when factory == nullptr || factory->getNumNodes() == 0. On Linux, during export_ci, the scriptnode factory has no compiled nodes, so this buggy code path is taken. On macOS/Windows, the factory can instantiate the nodes, so the correct opaqueNode path is used instead.