No, look under the Tools menu. LiveBuild is there too.
Thanks. I did find an issue. Adding the GUI does not preface any classes with juce:: and projucer now recommends that you leave adding using namespace juce to disabled.
If I go Indie now, do I still have to commit for 12 months, or will it blend into the 1 month commitment once JUCE 6 pricing applies?
So, assuming the new repo isn’t under WeAreRoli is this the new repo (deliberately obfuscating link, to avoid confusion) https:// github . com / juce-framework /JUCE.git
Yes, this announced a few days ago: The JUCE repository has a new home
What would you suggest if we’re planning to release in May and have no prior JUCE licence? (only Indie licence is necessary).
I would suggest buying Perpetual Indie licenses for all of your developers now, then upgrading them all to JUCE 6 Perpetual licenses within 1 month of JUCE 6 launching.
This would be exactly the same price as waiting for the launch of JUCE 6 and purchasing JUCE 6 seats directly.
Perfect, thanks tom!
This should now be fixed on the
Slightly OT but relevant to the potentially increased costs for JUCE Pro: at the same time github has reduced costs massively to the extent that many “Pro” users might be able to use their free tier or very likely their team tier. If you need to talk to bosses about costs (!) then this might help sweeten the pill. But TBH for us we haven’t worked out the details of the change in JUCE costs and Tom’s explanation is very clear and sound very fair!
Can anyone comment on the performance of a WebView approach vs a native GUI approach?
Thanks. It seems like the WebView approach would be great for getting things up and running quickly.
Seems current implementation of WebView for Windows will not be able to serve a locally hosted GUI, at least not through http + localhost, see this for details:
Due to loopback limitation in Edge-based WebView cannot be used even as a fallback to Chrome based WebView2, so it would be great if it was skipped altogether in favor of WebView2, or maybe another cross platform solution altogether (like https://ultralig.ht).
Isn’t it actually very unsafe to rely on a localhost/loopback solution? Any other application can hijack the open ports. Please let me know if I’m wrong.
Sounds like the much better solution for me.
Not really (you can’t bind to the already open port twice without terminating the listening process). The way you can approach it is to bind a file server hosting your html interface to a random port on 0.0.0.0 every time you initialize the plugin/app, and then your WebView loads the GUI from there. This also allows you to have several plugin instances running on the same machine without interfering with one another.
BTW, I use this http server for hosting the GUI from a local folder on disk: https://github.com/yhirose/cpp-httplib
gone a bit OT here, but i believe that the fact macOS WKWebKitView requires NSAppTransportSecurity “NSAllowsArbitraryLoads” in the host app plist makes running a webserver for plug-in UIs impossible. [EDIT… unless you can serve HTTPS]
Will there be support for VST3 note expression in juce6?
Does that mean, as far as the free open source license goes, this will be easier to make a package script for vcpkg or MSYS2 MinGW64?