Add support for playback in Electron apps

[cheap-glitch]

Currently, when trying to create an AlphaSynthWebWorkerApi instance in the renderer process of an Electron app, an error is thrown (Workers not yet supported in Node.js).

But it should be possible to run the alphaSynth APIs in an Electron app, since it's basically a Chromium browser embedded in a desktop app. So this should be as simple as updating the detection logic to include this case, and check it with something like:

typeof window !== 'undefined' && typeof window.process === 'object' && window.process.type === 'renderer'

(source)

FYI, my use case is making an alphaTab plugin for Obsidian. I've tried running the above snippet in the console and it seems the detection logic is working. I can also see the Worker and AudioContext objects are available, so alphaSynth should work out-of-the-box once the detection logic is updated.

[Danielku15]

In electron you have two parts: A node.js backend and a Chromium Frontend. The Node.js backend has no support for Web Audio. For now you likely need to use alphaTab both on the "backend" and "frontend" and communicate through channels.

When using AlphaTabApi there is one main abstraction for integrating with the underlying platform: The IUiFacade and related components.

The IUIFacade takes care of integrating the the User Interface aspects like passing rendered images/SVGs to the UI for display, listening for user inputs, creating background workers, synth outputs etc.. The BrowserUiFacade does this using the DOM and Browser APIs and is not compatible with a node environment.

Likely you are not using AlphaTabApi as the BrowserUiFacade would report an error early:

alphaTab/src/platform/javascript/BrowserUiFacade.ts

Lines 112 to 117 in af692f2

	if (Environment.webPlatform !== WebPlatform.Browser && Environment.webPlatform !== WebPlatform.BrowserModule) {
	throw new AlphaTabError(
	AlphaTabErrorType.General,
	'Usage of AlphaTabApi is only possible in browser environments. For usage in node use the Low Level APIs'
	);
	}

I am not sure if there is a built-in way into Electron to use the Frontend APIs from the Node.js backend (e.g. simply doing a document.createElement()) on the currently loaded page. If that's the case we could reuse the BrowserUiFacade.

There is currently also no "NodeUiFacade" which could be used to run alphaTab (e.g. in a virtual/headless space which could be manually synchronized with an external UI).

[LIUBINfighter]

The core is to initiate AlphaTabApi to unlock full support for rendering, playing and other powerful features built for web.

My solution enables alphaTab to run robustly within an Obsidian (Electron) plugin by tackling two core challenges: environment detection and asset loading.

Environment Emulation

The key issue is that alphaTab's AlphaTabApi is designed for pure browser environments and will throw an error if it detects a Node.js-like context (process or module objects). The fix is to create a temporary "browser-like" sandbox right before initialization:

Temporarily undefine globalThis.process and globalThis.module.
We explicitly force the environment flag: alphaTab.Environment.webPlatform = alphaTab.WebPlatform.Browser. This tricks alphaTab into passing its environment checks and initializing correctly.

https://github.com/LIUBINfighter/interactive-tabs/blob/2b0053af587017bed6a876a7ec2f3361918ac1fa/src/alphatab/initializeAndLoadScore.ts#L245-L264

Reliable Asset Loading (Fonts & SoundFont)
In Obsidian, direct file-system access from the browser context is restricted. Standard file:// paths or relative URLs for assets like fonts fail. The solution is to load all assets into web-friendly formats:

SoundFont & Workers: Use Obsidian's API ( app.vault.adapter.getResourcePath ) to get a valid app:// URL that alphaTab can fetch.

https://github.com/LIUBINfighter/interactive-tabs/blob/2b0053af587017bed6a876a7ec2f3361918ac1fa/src/alphatab/initializeAndLoadScore.ts#L79-L91

SMuFL Fonts (The Critical Part): To bypass alphaTab's internal font loading via @font-face URLs (which often fails), we take manual control:

• Use Node.js's fs to read the font files (.woff2, etc.) from the plugin's directory.
• Convert the font file buffers into Base64 Data URLs.
• Manually inject the @font-face CSS rules into the document's using these Data URLs.
• Provide the same Data URLs to settings.core.smuflFontSources to satisfy alphaTab's internal checks, ensuring it knows the font data is available.

However, I am not sure if alphatab.worker.mjs is enabled.

In essence, this approach creates a compatible "bubble" for alphaTab to initialize in, then pre-loads and injects all its dependencies as web-native resources (Data URLs), decoupling it entirely from the problematic file system interactions. I think it may be easier to initiate alphaTabApi directly in electron, miniblink or something like that rather than obsidian plugin.

[LIUBINfighter]

For some reason, the code snippets don't appear to be rendering correctly in this post. You can find the properly formatted version in the original GitHub issue for easier reading.

LIUBINfighter/Obsidian-Tab-Flow#1 (comment)

[Danielku15]

Environment Emulation

The key issue is that alphaTab's AlphaTabApi is designed for pure browser environments and will throw an error if it detects a Node.js-like context (process or module objects). The fix is to create a temporary "browser-like" sandbox right before initialization:

I think I understand now your problem. I'd have to test some bits here. It seems likely that even in the renderer process there are certain global variables set which make alphaTab detect wrongly a Node.js environment.

I'll try to make an improvement on the platform detection.

Reliable Asset Loading (Fonts & SoundFont)

For the SMuFl Font I just lately added an improvement to allow loading from any custom URLs beside just the built-in paths. Its not yet released but you can test it with the @alpha version already: https://next.alphatab.net/docs/reference/settings/core/smuflfontsources/
Here you can opt for variants like data urls or asset urls. Whatever your environment supports for loading. If there are still specifics which might not work in Electron/Obsidian you can share the details.

For the SoundFont you can also opt to custom loading from any custom source beside URLs: https://next.alphatab.net/docs/reference/api/loadsoundfont This API method also accepts Uint8Array instances you might load through any custom means. The string setting you use currently is just a ease-of-use setting to point it to a URL from where its loaded via a XHR.

I think there is no further improvement is needed on the asset loading.

Worker and Worklet URLs

I think this heavily depends on your project and how Electron/Obsidian handles plugin scripts. As far I can see the basic samples use ESBuild as bundler/transpiler which we do not support from alphaTab. I'm not sure if ESBuild exposes nowdays the required plugin APIs to make a proper plugin work.

Overall it narrows down to one question: Can Obsidian plugins splitup their code into multiple files which can be somehow loaded dynamically through standard browser means? If you switch your project to use a bundler like WebPack or Vite you can activate our plugin to achieve correct code splitting and URL loading.

But the "loading" part is a question towards the obsidian Devs on how the URLs need to look for things to work. I added #2151 to track these points.

For now the best workaround is likely to:

• Bundle the alphaTab script files as assets.
• In the renderer process before initializing AlphaTabApi alphaTab.Environment.initializeMain() with custom factories creating the worker and audio worklet with URLs pointing to the assets. You can take https://github.com/CoderLine/alphaTab/blob/develop/src/alphaTab.main.ts#L10 as a reference.

[Danielku15]

Here we go 🥳🎉: https://github.com/Danielku15/alphatab-obsidian

Obsidian_Bauvqze4wF.mp4

It seems Obsidian does not have a general built-in way of fetching files via URLs. But that's no problem because we can access the file system via Obsidian APIs and load files. Then its just a matter of creating Blob URIs for usage.

Obsidian plugins are generally meant to have always 1 main file. I saw they also just load the plugin file from disk and eval it with some special stuff. Unfortunately this means we cannot split-up the plugin source to have a shared "chunk" we can use for the main process and the worker/worklets. Hence I'm simply copying the alphaTab file from the node_modules folder and load it as blob. I guess for a local Obsidian plugin it doesn't hurt so much loading alphaTab twice as we're talking 1KB for the additional file.

[cheap-glitch]

@Danielku15 I tried to run the example plugin in a new Obsidian vault, but the playback doesn't work, I get this error when clicking the play/pause button:

[AlphaTab][WebAudio] Audio Worklet creation failed: reason=AbortError: Unable to load a worklet's module.

The error seems to come from https://github.com/CoderLine/alphaTab/blob/develop/src/platform/javascript/AlphaSynthAudioWorkletOutput.ts#L195

[Danielku15]

Working generally fine for me. I made some minor fixes (update to latest 1.6.1 and copy font+soundfont) but beside that the plugin works fine including playback. No sign of what you are experiencing. You might want to troubleshoot things deeper on your side what is really going on (e.g. look closely to MyPlugin.onload and what worker data is loaded.

Obsidian v1.8.10

Keep in mind: this plugin is just a basic sample, not a fully working plugin. Pay attention to what's mention in the readme and what is actually happening in Obsidian, then react accordingly.