elemaudio / srvb Goto Github PK

Linux support is already nearly there, I just need a bit of help getting it over the finish line from anyone who has more experience with Linux VST3.

The work involved is as follows:

• Inspect the VST3 bundle layout on Linux and update the getAssetsDirectory() here for the JUCE_LINUX case
• Attach the native webview handle to the viewContainer for the JUCE_LINUX case here and here
• Re-enable CI running on linux here and update the required dependency install step here so that the builds are happy

I think that should be it, but it's very possible I'm missing something.

Similar to #7, this issue is in the spirit of making sure we're resilient against crashes and instead relay helpful information to the user to facilitate a nice dev experience.

In PluginProcessor, anywhere we try to evaluate user code in the jsContext we should try/catch to prevent uncaught errors or syntax errors from crashing the native binary. I'm thinking that the general gist should be: if we fall into that catch block for any relevant jsContext.evaluate, serialize a helpful error message and get it to the editor so the user can see the error logged in the frontend dev console.

The dispatching of those error messages will follow the pattern from this commit: e69797f, except that with this PR I think we can improve the logging: any time we try to log to the editor, we should put the message into a queue. Then, if the editor exists, drain the queue. If the editor does not exist, we leave the queue as-is, and on any subsequent createEditor call we should drain the queue once the editor is open. This way we prevent losing any messages if the editor happens to be closed at the time of the log.

Right now if you use any of the analysis nodes (meter, snapshot, etc) the events never go anywhere because the template here has not wired them up. This task is to fix that.

The work should be easy enough: Add a juce::Timer which periodically calls Runtime::processQueuedEvents, serializes the event batch, and dispatches it to the webview (if exists) by calling a new __receiveGraphEvents__ global (if exists)

Now that we have hot reloading for debug builds, C++ asserts are detrimental to the dev experience because unless you're running under a native debugger, the app will just crash.

So the goal here is to remove the asserts and in their place put appropriate behavior. A quick git grep shows two main culprits:

native/PluginProcessor.cpp:    jassert(assetsDir.isDirectory());
native/WebViewEditor.cpp:                jassert(args.size() > 1);

In the first case, we can probably just remove that jassert altogether and make sure in all of the places that try to use the asset directory that we first check if the files we're trying to load there exist. If they don't, we shouldn't try to load them.

In the second case, for the webview/c++ bridge, we should probably just return a helpful value if args.size() < 2 to indicate to the caller that they gave the wrong args. On the javascript side of that call we can add some glue that checks: did the native side return a value to indicate wrong args? Then throw an error on the js side to help the user.