`juce6` technical preview branch

General JUCE discussion
42

There will be an updated live-build in the official release but for the time being (assuming you’re on macOS) if you move the old JUCECompileEngine.dylib into Projucer.app/Contents it should pick it up and use it.

2 Likes
43

I think there might be an issue with the AudioPluginHost example or maybe one of the vst3 wrapper classes. It’s crashing when I delete a plugin while its editor is open. If I run with a debugger, I get a jassert error in VST3PluginFormat when it checks that getActiveEditor()==nullptr with the message “You must delete any editors before deleting the plugin instance!”.

44

I am getting this same issue in Windows 7 64 bit. The release build of PluginHost crashes when deleting a plugin while its editor window is open.

45

Thanks for reporting. This is fixed on the juce6 branch now.

46

I have had some breaking change with the use of IO streams and AudioFormatWriter/Reader classes, it’s great that streams are now emitted as std::unique_ptr however when you give these to a writer which according to the documentation:

the stream that the data will go to - this will be
deleted by the AudioFormatWriter object when it’s no longer
needed.

ok great so now there’s:

       auto writer = format->createWriterFor(file_output_stream.get(), 44100, 2, 16, StringPairArray(), 0);
       if (writer != nullptr)
       {
              writer->writeFromAudioSampleBuffer(buffer, 0, buffer.getNumSamples());
              delete writer;
        }

the dilema is if I get the file output stream and it creates a writer it will be deleted by the writer and again by the unique ptr. but if I release the file output stream then i’ll need to delete it manually in the case that it wasnt used, which is fine but means it’s back to square one with manually managing the streams. I’d say that if streams are to be emitted as unique_ptrs then any Classes taking streams as arguments ought to either accept unique ptrs requiring a move, or that they take the raw pointer and delete it under no circumstances, I’m sure there is a good reason this cant be applied across the board, just seeking clarification on the right way to update application code for this change.

47

Hello IvanC,
I try to Build my VS2019 project with APVTSparameters and I obtain:
Erreur C2679 '=' binary: no operator for type 'std::atomic<float> *'
Do you have exemple to how to use APVTSparameters with Juce 6?

Source code:
m_freqParameter = PVTSparameters.getRawParameterValue("freqID");

Thanks

48

m_freqParameter = PVTSparameters.getRawParameterValue("freqID")->load(); ?

1 Like
49

Still in error with ->load function. But I change std::atomic<float*> to std::atomic <float> * and it works.
But std::atomic<float*> works fine with Juce 5 but not with Juce 6… strange.
Thanks for your quick reply.

50

I’m building a working JUCE 5.4.7 VST3 MIDI plugin in JUCE 6 just to see how it goes, and it actually builds fine, except I get a warning that I’m using the deprecated MidiBuffer::Iterator, which makes sense. I’m now just trying to figure out how to use the new MidiBufferIterator that replaces it, but I can’t find a usage example anywhere, and it has a different signature than the deprecated Iterator. Can anyone rewrite the code below using the new MidiBufferIterator as an example?

void SomeClass::doMidiStuff (MidiBuffer& inMidiBuffer)
{
    int samplePosition;
    MidiMessage message;

    for (MidiBuffer::Iterator iterator (inMidiBuffer); iterator.getNextEvent (message, samplePosition);)
    {
        DBG ("note number: " << message.getNoteNumber());
    }
}
51

I think it would look something like:

void SomeClass::doMidiStuff (MidiBuffer& inMidiBuffer)
{
    for (const MidiMessageMetadata m : inMidiBuffer)
        DBG ("note number: " << m.getMessage().getNoteNumber());
}

There should never be a need to directly construct a MidiBufferIterator. Instead, use the member begin and end functions on MidiBuffer (perhaps via a range-for, as above).

4 Likes
52

Awesome, that runs, and it’s a much cleaner API! Thanks @reuk

53

We’ve added WebView2 support to the WebBrowserComponent in 87fcf2f. Please give it a test and let us know how you get on!

5 Likes
54

Thank you for adding WebView2!

After testing it for a day I can confirm that for standalone apps it works fine and loads localhost urls (which is huge)!

I ran into several issues however:

  • Enabling JUCE_USE_WIN_WEBVIEW2 in Projucer breaks VST3 support - the plugins build without error but fail to load in DAW or pass validation (pluginval reports “Num types found: 0” and fails). A simple way to replicate this is to enable the Webview2 support on the example Gain plugin that ships with JUCE / Projucer.
  • I was not able to configure a build using cmake - the builds were failing with LNK2001 as they would not be able to find the WebView2Loader.dll or the Edge instance (not sure), a working example would be very appreciated.
  • Upgrading the hard coded version of WebView2 in Projucer to newest available in NuGet would break the builds (that’s most likely an issue on the NuGet side, as I found other reports about the module being broken in some instances). It would be great if the version could be configurable from Projucer or via cmake.

IMPORTANT for anyone that is trying this - use only dev or canary channel of Edge Insider Preview, normal channel has disabled support for this use case until the Webview2 redistributable is launched later this year.

55

I was not able to configure a build using cmake

This is a known limitation, and we’ve documented it in the CMake API document as well as the config flag in juce_gui_extra. Currently there is no way to add a NuGet package to a Visual Studio project via CMake so you will need to manually add it via the package manager in Visual Studio.

It would be great if the version could be configurable from Projucer or via cmake.

This is intentionally not configurable. As the WebView2 package is currently in developer preview and subject to a lot of API changes, we are restricting the package to the version that is known to work with JUCE (currently the latest). We’ll update this as the API becomes more stable.

Enabling JUCE_USE_WIN_WEBVIEW2 in Projucer breaks VST3 support

That sounds odd, we’ll look into this,

1 Like
56

Thanks! Looking forward to the VST3 fixes.

Would something like VS_PACKAGE_REFERENCES make CMAKE version possible? https://cmake.org/cmake/help/v3.15/prop_tgt/VS_PACKAGE_REFERENCES.html

57

Unfortunately no. It uses NuGet PackageReference which isn’t supported in C++ projects: https://developercommunity.visualstudio.com/idea/351636/use-packagereference-in-vcxproj.html

1 Like
58

So this is because WebView2 requires that WebView2Loader.dll is shipped alongside the program (it’s basically the entry point for finding the Edge installation and creating the browser instance). When a plug-in is loaded inside of a host process the system DLL search paths are for that host process, not the plug-in, and it fails to load the DLL causing the error that you’re seeing. You’d also see this if you moved an .exe outside of the builds folder as the DLL is no longer next to it. As this isn’t a standard system DLL, we can’t rely on it being installed on a user’s machine and visible via the normal system DLL search paths so there needs to be a way of specifying the DLL location when creating the WebBrowserComponent - to facilitate this we’ve added the WindowsWebView2WebBrowserComponent wrapper which takes a dllLocation argument in its constructor (as well as an optional non-default user data folder location).

In order to use WebView2 you therefore need to ship the WebView2Loader.dll (found in the Microsoft.Web.WebView package) with your app or plug-in, install it to a location on the user’s machine and specify this location when creating the WindowsWebView2WebBrowserComponent instance in your code. Hopefully Microsoft will update this before the 1.0 release of WebView2 to make it an easier process and we can remove this workaround (there is some discussion on the feedback page on Github - Don't require DLL to ship with app · Issue #110 · MicrosoftEdge/WebView2Feedback · GitHub) but this is the only way to make it work for the time being.

More information can be found in the documentation for the wrapper, and the changes are on the juce6 branch in this commit:

59

Did you specify the WebView2 user data folder? Didn’t see exactly how this is passed in in JUCE6 but in my work on this, I found plug-in builds would not work without specifying that, where as standalone app builds seemed to use the default Edge user data folder. Permissions thing i think

60

AFAIK WebView2 folders can be customized via system ENV vars and registry entries, but I haven’t had any difference when doing so as those seem to be set correctly and pointing to correct Edge folder.

Thanks a lot for quick turnaround on this fix! I’ve just confirmed that VST3 not working was indeed related to the invalid WebView2Loader.dll file location. I moved the .dll to the same folder as pluginval.exe and all plugins loaded and validated just fine.

I also built a new plugin with the WindowsWebView2WebBrowserComponent wrapper, specifying an absolute path to the WebView2Loader.dll and leaving the user data folder parameter empty - it loaded successfully in Studio One 4 DAW.

So this is resolved, thanks a lot! Let’s hope there’s a static library coming soon.

Side note: plugins only load in Studio One 4 if the .vst3 file is located exactly in the C:\Program Files\Common Files\VST3 folder, place it in a subfolder and plugin will not show up.

1 Like
61

Plot twist: the VST3 inside DAW actually loads Internet Explorer 11 instead of Edge 85, if I don’t specify the user data folder.

Microsoft docs say:

“WebView2 creation can fail if the executable is running in a directory that the process doesn’t have permission to create a new folder in. The app is responsible to clean up its user data folder when it is done.”

Once I set user data folder to File::getSpecialLocation(File::userApplicationDataDirectory).getChildFile("MyPluginName") then Studio One 4 loads Edge 85.

Interestingly enough, pluginval now fails again with a stacktrace in the “editor” phase:

Starting test: pluginval / Editor...
*** FAILED: VALIDATION CRASHED
 4: UnhandledExceptionFilter + 0x1e7
 5: memcpy + 0x4fc
 6: _C_specific_handler + 0x96
 7: _chkstk + 0x12f
 8: RtlUnwind + 0x7cc
 9: KiUserExceptionDispatcher + 0x2e
 10: Javelin6: <lambda_93dff958aa7e8b4013b50895c39a20c4>::operator() + 0xe2
 11: Javelin6: Microsoft::WRL::Details::DelegateArgTraits<long (__cdecl ICoreWebView2CreateCoreWebView2ControllerCompletedHandler::*)(long,ICoreWebView2Controller *)>::DelegateInvokeHelper<ICoreWebView2CreateCoreWebView2ControllerCompletedHandler,<lambda_93dff958aa7e8b4 + 0x55
 12: CreateWebViewEnvironmentWithOptionsInternal + 0x264e4
 13: CreateWebViewEnvironmentWithOptionsInternal + 0x2544a
 14: CreateWebViewEnvironmentWithOptionsInternal + 0x26612
 15: CreateWebViewEnvironmentWithOptionsInternal + 0x28214
 16: CreateWebViewEnvironmentWithOptionsInternal + 0x28782
 17: CreateWebViewEnvironmentWithOptionsInternal + 0x315a4
 18: CreateWebViewEnvironmentWithOptionsInternal + 0x136ed
 19: CreateWebViewEnvironmentWithOptionsInternal + 0x13655
 20: GetHandleVerifier + 0x1a841
 21: CreateWebViewEnvironmentInternal2 + 0x7ed58
 22: CreateWebViewEnvironmentInternal2 + 0x7dfea
 23: CreateWebViewEnvironmentInternal2 + 0x79ba2
 24: GetHandleVerifier + 0x1de7a
 25: CreateWebViewEnvironmentInternal2 + 0x47c6d
 26: CreateWebViewEnvironmentWithOptionsInternal + 0x58fb
 27: CreateWebViewEnvironmentInternal2 + 0x5855c
 28: CreateWebViewEnvironmentInternal2 + 0x581d7
 29: CallWindowProcW + 0x60e
 30: DispatchMessageW + 0x4a3
 41: BaseThreadInitThunk + 0x14
 42: RtlUserThreadStart + 0x21

While standalone and VST3 inside Studio One 4 work just fine.