@Christoph-Hart So…macOS only reports crashes that terminate the process via an unhandled exception/signal. It might not read it's head because one (or more) of these applied:

• HISE/JUCE intercepts the crash (custom crash handler) and exits cleanly, so CrashReporter never triggers.
• Running under Xcode/LLDB suppresses the system crash dialog and routes it to the debugger.
• It wasn’t a crash (hang, forced quit, graceful shutdown) → no CrashReporter event.

Reports are silent even when generated; they live in ~/Library/Logs/DiagnosticReports (visible in Console.app) and may not show a dialog.

That’s why the custom crash logger is useful: it captures a backtrace even when macOS doesn’t show or generate a report.

@Lindon Your installer is dope, and very cool.

@David-Healey Dave is…correct (as usual) about the old version of new Packages. I don't remember if the new version does or not. There is, however, a built-in scripting now built into the new Packages.

@Lindon The audio plugins folder is now a default option in the menus—you don't have to point it.

@Christoph-Hart It doesn't always. I'll do a little more research, and post info on why. It's Apple's way of saying, "We're Apple, and we don't think you need to worry about this. Because we're Apple."

Has HISE crashed on you? Of course it has. Did it report anything to operating system? Of course not…where would the mystery be? Here to spoil all the fun is a crash reporter. So, at least you're not gaslit when you could swear HISE vanished from your screen. I'm on macOS, so no idea about other operating systems and I don't care.

---

Save the below as crash-handler.patch, then run git apply crash-handler.patch.

diff --git a/hi_backend/backend/BackendProcessor.cpp b/hi_backend/backend/BackendProcessor.cpp
index 3b45c6d2e..95b42bc1a 100644
--- a/hi_backend/backend/BackendProcessor.cpp
+++ b/hi_backend/backend/BackendProcessor.cpp
@@ -49,6 +49,47 @@ void printData()
 
 namespace hise { using namespace juce;
 
+namespace
+{
+void installBackendCrashHandler()
+{
+	static bool installed = false;
+
+	if (installed)
+		return;
+
+	installed = true;
+
+	SystemStats::setApplicationCrashHandler([](void*)
+	{
+		static bool handling = false;
+
+		if (handling)
+			return;
+
+		handling = true;
+
+		auto crashDir = File::getSpecialLocation(File::userApplicationDataDirectory)
+							.getChildFile("HISE")
+							.getChildFile("CrashLogs");
+
+		crashDir.createDirectory();
+
+		auto logFile = crashDir.getChildFile("HISE_CrashBacktrace.txt");
+		FileOutputStream stream(logFile);
+
+		if (stream.openedOk())
+		{
+			stream.setPosition(logFile.getSize());
+			stream << "----\n";
+			stream << Time::getCurrentTime().toString(true, true) << "\n";
+			stream << SystemStats::getStackBacktrace() << "\n";
+			stream.flush();
+		}
+	});
+}
+}
+
@@ -274,6 +315,8 @@ BackendProcessor::BackendProcessor(AudioDeviceManager *deviceManager_/*=nullptr*
   autosaver(this),
   pluginParameterRamp(this)
 {
+	installBackendCrashHandler();
+
 	//printData();

---

This writes crashes to ~/Library/Application Support/HISE/CrashLogs/HISE_CrashBacktrace.txt

@DanH Yes, it is a brand new addition.

@David-Healey It works (no bugs), and thanks to your truly, it has built-in support for installing audio plugins.,

@Christoph-Hart Agreed. You still need to know what it should do, why and how. And bottom line, you still need to know how to create a good plugin—and there is not enough training data to model that.

@David-Healey Seth Willits, Araelium Group

@clevername27 Oh gosh, I just saw this. I didn't mean to blow off your question. I may have noped out of HISE at that point. In any case, he's got a new version of Packages that specifically supports audio plugins (plus whatever is in HISE these days).

@David-Healey (Thank you.) Yes, that was one of the nice things that @Christoph-Hart did, and it solved an issue where (as I recall) the old callback would fire before the samplemap actually loaded. (EDIT: It. may have been your idea, lol.)

@David-Healey You're right, and HISE already solves that problem quite elegantly. I've removed that text.

HISE Startup / Samplemap Threading Notes (2026-01-18)

A year ago, one of the reasons I abandoned HISE was problems where Sample folder, and Samplemaps, either moved or resolved dynamically, within the context of threading. I eventually got it to work with duct tape and glue. I'm now looking at the HISE source, and the model made these suggestions (below). I'll start tinkering—if anyone wants to help, that would be helpful. I found one bug that prompted @Christoph-Hart to promise me a t-shirt (still waiting, Chris ).

Findings (HISE-PRISM)

1. Link file missing folder can still be returned
   In FileHandlerBase::checkSubDirectory(), if the Link file points to a path that no longer
   exists and the user cancels the dialog, HISE returns the missing path anyway. This can lead to early “samples not found” or missing-session problems unless script logic overrides it later.

   • File: HISE-PRISM/hi_core/hi_core/PresetHandler.cpp

2. Default sample location can be auto-created before scripts run
   If the Link file is missing, FrontendHandler::getSampleLocationForCompiledPlugin() selects a default location, writes a new Link file, and returns it. This happens early in startup, before your scripts can relocate sample paths.

   • File: HISE-PRISM/hi_core/hi_core/PresetHandler.cpp

3. Preset load compiles scripts while sample preloading is deferred
   MainController::loadPresetInternal() sets setShouldSkipPreloading(true), restores the module graph, compiles scripts, prepares audio, and sends the preset-load rebuild message before preloading resumes. This creates a timing window where scripts execute but samples are not yet loaded.

• File: HISE-PRISM/hi_core/hi_core/MainController.cpp

4. User preset restore completes before samples are preloaded
   UserPresetHandler::loadUserPresetInternal() also sets setShouldSkipPreloading(true), restores state (including script controls), then calls postPresetLoad() and only afterwards calls preloadEverything().

• File: HISE-PRISM/hi_core/hi_core/UserPresetHandler.cpp

5. SampleMap change message is sent after parse, not after sample I/O
   SampleMap::load() parses the ValueTree and then calls sendSampleMapChangeMessage(). This notification can fire before actual sample files are fully loaded, so “samplemap loaded”
   signals may not guarantee sample availability.
   • File: HISE-PRISM/hi_core/hi_sampler/sampler/ModulatorSamplerData.cpp

Implications for dynamic sample locations

• If your scripts assume samples are ready in onInit / preset callbacks, the above timing
  windows can cause failures in workflows that relocate sample folders or load samplemaps
  dynamically.

---

My solutions/work-arounds

Regardless of what AI has to say about it, here is what I did in my old code, that still works, for having Samples referenced dynamically. It's specific to my usage case, but anything you need should be in there. (If not, hit me up.) It should work with the codebase going back at least a year.

The way i made the samplemap dynamic was to encode them in a JSON file (using HISE's API to do that, there and back).

1. Restore a known-good sample folder before Session init
   Make sure user data is loaded early, and restore the last valid sample folder before
   you scan for Sessions.

inline function InitalisePrism() {
	// ...
	// ------------- User Data
	
	HandleUserDataFileStartup ();
	
	// ------------- Session
	
	SESSION_SetFrameworkState("init");
}

inline function HandleUserDataFileStartup () {
	// ...
	// Restore last sample location (avoids startup "samples not found" state).
	RestoreLastSampleFolderFromUserData();
	// ...
}

2. Populate Sessions on init, but suppress errors until startup completes
   This avoids noisy error popups while still scanning the Sessions folder at startup.

inline function SESSION_SetFrameworkState (moduleState) {
	// ...
	// Populate the Sessions menu on init, but suppress errors until startup completes.
	if (g_executionFlags.onInitComplete && !g_executionFlags.presetLoading)
		SetListOfSessionDataFolders (false);
	else
		SetListOfSessionDataFolders (true);
	// ...
}

3. Centralize sample-folder changes and persist them
   Avoid redundant Link file writes and keep a single, tested path for recording the
   last sample folder.

inline function ApplySampleFolderChange(sampleFolder) {
	// ...
	Settings.setSampleFolder(sampleFolder);
	RecordLastSampleFolderPath(sampleFolder);
	// ...
}

4. When a Session/Articulation is chosen: set the sample folder, load the map, reload samples
   This ensures the Link file is updated before sample IO begins.

if (g_articulationData) {
	// Load the Samplemap, which should be embedded in the plugin.
	local sampleMapName = GetSessionDataGenus("samplemap");
	// ...
	mySampler.loadSampleMap(sampleMapName);
	// ...
	ApplySampleFolderChange(sampleFolder);
	Engine.reloadAllSamples ();
}

@David-Healey Great. I'll teach to cross-check with that repo when accessing Rhapsody.

@David-Healey Thank you for the information, David. Rhapsody isn't the primary source for the model; the current Develop branch is, as well as earlier versions of the source (to track changes). Is your version of the source publicly available?

@dannytaurus One thing I'd suggest is being clear with the AI that HiseScript is not JavaScript—in order for the LLM to be useful, it needs to understand every aspect of HISE. Otherwise, it's just vibe coding, which (personally) I think is useless. Either it works or it doesn't.

@Christoph-Hart It's too much to explain in a forum posting, but I'm happy to share all the information with you in some other format.

Yes, some of the files are JSON-formatted data. Others are MD-formatted. I like the MD stuff because it's human-readable. However, the JSON stuff is more efficient for the LLM, so it's a mix. The MD stuff is usually stuff I work together with the LLM on.

I really am astonished at how well it works.

@dannytaurus

@Oli-Ullmann said in Checking the HISE Source with AI?:

You created an AI model that generates the complete code for a complex plug-in, and since then you haven't had to write a single line yourself? Does that mean you didn't have to change anything in the code generated by the model? Am I understanding that correctly?

I'm using the word "model" in a very general sense. It's not an LLM model, per se. It's a set of data files that enables the AI to understand HISE, and contextualise it within the larger body of available knowledge of JUCE, audio development, etc.

I don't want to programme plugins. I want to develop them. The model helps me design them better, and writes all the source code. It learned some its patterns from @David-Healey, and produces beautiful, clear, and well-architected output.

But it's not magic, and many things in plugin development (as we all know) are only revealed through the process of development. You still need a fundamental knowledge of HISE, C++, audio development, and software engineering. Otherwise, you have nothing to talk about with it. For example, I asked it to refactor one of my plugins to use Broadcasters—it was helpful for me to tell it how, where and why I wanted this done. At another point, it looked at David's use of namespaces, and suggest I use that architecture.

Obviously, the model needs persistence between Agent sessions. And it needs to do this in a way that minimises token usage. Otherwise, by the time it loads everything up, you don't have enough tokens to actually do your work. And even then, the model is almost infinitely larger than can fit in the available token space (and with respect to other limitations). So, my model includes strategies to inform decision-making on whether it can act with what it knows, or whether it needs to access the model for additional information, and how to do that without forgetting what it needed with to begin with.

Needless, to say, you need to max out everything in Cursor that increases the Token capacity. And you want to use chat-GPT because it excels at this type of learning.