@David-Healey I now managed to install reaper and the compiled plugin now works. so it was those listed bugs

@David-Healey I wouldnt know how to show you how to recreate the issue. I already posted all the info I have including detailed reports on the found bugs.

@David-Healey I don't see how that would help, the problem isn't specific to my setup there are fundamental bugs in HISE/JUCE. the more dig into this with CC the more walls I hit. I've been running it for hours now, installing virtual machines blah. I'm at the point where I just pull the plug and go to the pool with all my other friends instead of wasting hour after hour. I write beautiful sounding DSP and I can compose and do graphics. the rest around it really isn't my forte.

it does finally make a sound in hise on linux after a long struggle, but whether a compiled vst3 works in linux - sstill no change to test.

here's more findings so far

HISE on ARM64 Linux: three bugs blocking DSP-network / project-DLL compilation

Environment: Debian 13 (trixie), aarch64 (Apple Silicon), HISE develop (4.9.x, JUCE 6.1.3),
g++-12, Faust 2.79.3. Building the standalone and exporting plugins/DLLs natively for arm64.

Three separate bugs had to be fixed to compile DSP networks / project DLLs on arm64. Two are
architecture-independent UB (only bite on arm64); one is an arm64 MIR codegen loop.

---

1. CustomKeyboardState writes one element past its array (segfaults on arm64)

Any project load / export / compile_networks crashes immediately:

#0 hise::CustomKeyboardState::CustomKeyboardState()
#1 hise::MainController::MainController()
#2 hise::BackendProcessor::BackendProcessor(...)

hi_core/hi_core/UtilityClasses.h:

Colour noteColours[127];   // 127 entries, valid 0..126

The constructor (UtilityClasses.cpp) writes all 128 MIDI notes:

for (int i = 0; i < 128; i++)
    setColourForSingleKey(i, Colours::transparentBlack);   // writes noteColours[127] -> OOB

setColourForSingleKey also guards noteNumber <= 127, so 128 entries are intended. Index 127
is out of bounds. Harmless on x86_64 (overwrites the adjacent lowestKey), segfaults under -O3
on arm64.

Fix:

Colour noteColours[128];

---

2. SNEX MIR JIT infinite loop on arm64 (expression node)

"Compile DSP networks as DLL" and the compile_networks CLI hang at 100% CPU forever on arm64
(IDE looks frozen). It happens while the exporter instantiates each node in
DspNetwork::createAllNodesOnce(). Backtrace of the spinning thread:

#0 generate_func_code ()                                <- MIR generator
#1 MIR_link ()
#2 snex::mir::MirCompiler::compileMirCode(juce::String)
#3 snex::mir::MirCompiler::compileMirCode(juce::ValueTree)
#4 snex::jit::Compiler::compileJitObject(juce::String)
#5 snex::JitExpression::JitExpression(...)
#6 scriptnode::dynamic_expression::updateCode(...)
...
#15 scriptnode::DspNetwork::createAllNodesOnce()
#16 hise::DspNetworkCompileExporter::DspNetworkCompileExporter(...)

Creating a math.expr / dynamic_expression node JIT-compiles its expression through the MIR
backend. MIR's aarch64 generator (generate_func_code, from MIR_link) loops indefinitely.
Lowering MIR_gen_set_optimize_level from 3 to 1 in snex_MirObject.cpp does not help (it loops
at lower levels too), so this is a MIR aarch64 codegen bug (bundled MIR in hi_snex/snex_mir/src).

During createAllNodesOnce() the JIT result is never used (the node's C++ is generated from the
expression source), so the JIT is skippable there. Flag on DspNetwork set during
createAllNodesOnce, checked in dynamic_expression::updateCode before new JitExpression:

if (node->getRootNetwork()->isCreatingAllNodesOnce())
{
    r = Result::ok();
    return;
}

This unblocks DSP-network / DLL export on arm64. Live JIT of expression nodes in the IDE still
hits the MIR loop; the real fix belongs in the MIR aarch64 backend.

---

3. Headless/CLI export crash: JUCE display query derefs null

With #2 worked around, compile_networks on a headless display (no monitor / Xvfb) segfaults
while the export dialog is constructed:

#0 juce::Component::getParentMonitorArea()             (then later centreWithSize)
#1 juce::AlertWindow::updateLayout(bool)
#2 juce::AlertWindow::setMessage(...)
#3 juce::AlertWindow::AlertWindow(...)
#4 hise::DialogWindowWithBackgroundThread::DialogWindowWithBackgroundThread(...)
#5 hise::DspNetworkCompileExporter::DspNetworkCompileExporter(...)
#6 CommandLineActions::compileNetworks(...)

DspNetworkCompileExporter is a DialogWindowWithBackgroundThread, so it builds an AlertWindow
even from the CLI. On a headless Linux session JUCE detects zero displays and these deref null:

juce_gui_basics/components/juce_Component.cpp:

// getParentMonitorArea():
return Desktop::getInstance().getDisplays().getDisplayForRect(getScreenBounds())->userArea;
// ComponentHelpers::getParentOrMainMonitorBounds():
return Desktop::getInstance().getDisplays().getPrimaryDisplay()->userArea;

getDisplayForRect() returns nullptr when no display intersects (or the list is empty);
getPrimaryDisplay() returns nullptr when the list is empty.

Fix - guard both:

Rectangle<int> Component::getParentMonitorArea() const
{
    auto& d = Desktop::getInstance().getDisplays();
    if (auto* x = d.getDisplayForRect(getScreenBounds())) return x->userArea;
    if (auto* p = d.getPrimaryDisplay())                  return p->userArea;
    return { 0, 0, 1920, 1080 };
}
// getParentOrMainMonitorBounds(): same guard around getPrimaryDisplay()

After these three changes, compile_networks -c:Release runs to completion on a headless
display and produces a working DspNetworks/Binaries/dll/.so for arm64 Linux.
getParentMonitorArea / getParentOrMainMonitorBounds derefing null also affects the CLI on any
Linux box with no usable display, so it is worth guarding regardless of architecture.

@David-Healey yes

@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.

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.

@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.

@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 right.

@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 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...

@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 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

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)

@dannytaurus said in ALT+S requires TWO confirmations. Can this be switched off?:

CMD+S > Enter > Enter > SHIFT+CMD+S > Enter > Enter

yes my muscle memory exactly. and i caught myself doing this in other programs where the two Enters cause a lot of trouble depending on the program, it might have saved and then jump execute something else two times, worst case the second enter is a confirmation for the first that already did something it shouldnt lol

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

@David-Healey Debian 13 and Reaper

@ustk im just looking for a way to ged rid of those two confirmation dialogs. ALT+S needs to save, not ask twice if I wanna really save and then again if I really wanna overwrite the file.

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"

Ahoi,

I'm pretty sure you all know hitting ALT+S requires two confirmations, which conditioned me to hit Enter twice in pretty much every other software I ever use, when I save something. This is causing real problems and damage....

Is there a way to turn this off and have ALT+S work like in any other program?

cheers!