`juce6` technical preview branch

The Linux VST3 naming issue is now fixed on the juce6 branch:

1 Like

so juce6 + cmake is just amazing. thank you.

this morning I took our SCL/KBM juce, synth finished our juce 6 port and also activated juce 6 in our azure pipelines. microsoft gives free mac windows and linux builds to any opensource project on github, and so on every pull request I do a build on fresh VMs, and when i merge to master, i get a zip/dmg/tgz of the VST3/Standalone/AU posted as a release.

https://github.com/surge-synthesizer/tuning-workbench-synth is the code - and everything worked really well.

The basic trick was: make JUCE a git submodule and add a target to make a .dmg / .tgz / .zip of the final assets to my CMakeLists.txt and voila. Figured I would share in case any of you are trying similar things in your CI environment. Feel free to copy any of the things I did in the azure pipeline or cmake file to your projects. If you have any questions just hit me up on github or here.

And thanks again JUCE team!

11 Likes

Just awesome!!!

I tested the Linux VST3 fixes. Everything seems to work. I was able to load plug-ins in the AudioPluginHost & Bitwig.

All the other fixes work as well. I tested the hpp module headers, debug flags & LTO settings on all three desktop platforms.

Thank you.

The dsp::Convolution class has been updated to add some new features:

  • standard zero latency uniform partitioned convolution
  • uniform partitioned convolution with fixed latency
  • basic zero latency non-uniform partitioned convolution

We’ve also fixed some realtime safety issues.

10 Likes

Tiny data point: I switched my current project from latest stable to juce6 and had 0 issues compiling :sunglasses: Nice job!

1 Like

Looking good! Is live compilation coming with the official release? I’m seeing can't communicate with server when clicking ‘download.’

I tried manually placing the old JUCECompileEngine.dylib in various directories and blowing away settings in ~/Library/Application\ Support/Projucer/ but I’m guessing the Projucer wants a 6.x version.

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

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!”.

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.

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

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.

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

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

1 Like

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.

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());
    }
}

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

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

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

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.

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