Web Workers can't be initialized with NodeJs

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

While every needed ressources are loaded in the api object, the player is stuck with:

• _workerIsReady: false
• _workerIsReadyForPlayback: false

Expected Behavior

The player should be ready for playing, and the track hud (cursor) should be visible.

When launching the player with api.player.play(), the track sound should be audible.

Steps To Reproduce

1. Initialize a typescript Vue project with Vuetify
2. Import @coderline/alphatab with npm
3. Use alphatab with import { AlphaTabApi, Settings } from "@coderline/alphatab
4. Initialize a new Settings object 4.1 Set settings.core engine = html5 and useWorkers = true 4.2 Set settings.player enablePlayer = true and enableCursor = true 4.3 Link settings.player.scrollElement to an html element
5. Initialize a new AlphaTabApi with a context and the settings
6. Load score with api.load(<Bytes buffer>)
7. Load sound font with api.loadSoundFont(<Bytes buffer>)
8. Render with api.renderTracks([api.score.tracks[0]])

Link to jsFiddle, CodePen, Project

https://github.com/mlhoutel/Tablatures

Found in Version

1.3-alpha

Platform

Node.js

Environment

- **OS**: Windows 10 
- **Browser**: Chrome 94.0.4606.61
- **Node**: v16.3.0
- **Webpack**: 4.46.0
- **Vue**: 2.6.11
- **Vuetify**: 2.4.0

I tried multiples versions of the npm package **@coderline/alphatab**, from **1.2.0** to **1.3.0-alpha.131**

Anything else?

Reader component: https://github.com/mlhoutel/Tablatures/blob/main/src/components/TabReader.vue Log of the API object: at https://mlhoutel.github.io/Tablatures then click on the [TRY IMPORTING] button and load a tab file

[Danielku15]

I had a look and it seems one issue is related to the bundling: https://alphatab.net/docs/getting-started/installation-web#bundling In your setup you are bundling alphaTab which is not well supported due to the spawning of Workers which require Web Worker compatible code. Looking at your code the workers are launched with a wrong URL due to some bundling specific stuff in your environment:

I recommend disabling bundling for alphaTab completely and include it as standalone script to avoid any conflicts with other scripts it is bundled with, or that any bundler messes with the initialization routines of alphaTab.

alphaTab requires to run some initialization routine directly after it is included:

1. On the main thread it needs to find the script file it is contained in to correctly spawn workers. Alternatively you can also configure the alphaTab script file manually to work around this detection.
2. Within the WebWorker alphaTab needs to setup some global listeners on the worker context to actually handle the messages that are coming from the main thread.
3. Just like on 2. there are also AudioWorklets spawned (if supported) to handle audio playback in the background.

Considering these aspect I recommend that you first try to get alphaTab running without webpack. If you have it running you are sure alphaTab is working fine without issues. When you then start introducing WebPack step-by-step you will have to find out what is wrong in your setup that makes alphaTab fail to launch. This I cannot do for you in your project, alphaTab is working fine and it is known that bundling causes various issues.

I have it on my agenda to document better how alphaTab can be best integrated into applications using WebPack and Rollup but I still have to dive into this topic myself to give out good recommendations. Until then the recommendation is: Don’t merge alphaTab into bundles.

As you can see on this screenshot, alphaTab is initialized from the app.js instead of the chunk-vendors.js (notice the callstack), this means initialization routines are not executed correctly on script load (likely due to the fact that alphaTab is only registered as dependency). You might check the WebPack docs to find out how you can ensure that initialization code of bundles is executed on include of the bundle and not when only resolved.

[Danielku15]

Closing this issue in favor of #759