Thanks.
add:
and:
About RichTextEditor, WebBrowserComponent + JS-editor is a good choice?
any help??
Ableton-Link and AudioBus3 support on iOS.
A general steady move towards making PROJUCER itself a workable ( and enjoyable and productive-to-code-in ) IDE for as much as possible, with basic but useful typical (but better implemented? ) refactoring operations such as found in XCode9 or CLion, reducing the need for flipping beween PJ and Xcode ( or VS )
Perhaps they don’t produce music every day, but most likely they listen to music every day.
Unfortunately for us JUCE seems to be about implementing ROLI-needed features first followed by letting features trickle down to licensees. I think this is more than fair given the scope of JUCE, the small number of developers working on it, and the relatively inexpensive licensing terms.
I would think something like rich WYSIWYG would be far out of the scope of JUCE (like another “heavy” content authoring component often requested, a piano roll). JUCE provides all the necessary heavily-tested cross platform building blocks necessary to implement this yourself.
Example: I needed a bunch of low-level networking stuff (raw socket read/write, raw packet inspection). This is clearly outside the scope of JUCE, which provides a simple socket abstraction. So I wrote my own in the JUCE style using libpcap using all JUCE code and it fit together easily! Or I needed a much more customizable slider class based on inheritance rather than an enum so I wrote one. The way I’ve always seen it JUCE isn’t about really heavy duty features (unless they’re important to ROLI, like BLOCKS support), it’s about giving you robust, portable building blocks to assemble things.
In a post-ROLI acquisition world, I think it’s safest to assume that whatever you have when you buy a license is what you’re gonna get + some bug fixes - just look at how JUCE 4 users were screwed out of the DSP module, which was a headliner feature to push users to buy JUCE 4 licenses.
If I were you I wouldn’t hold my breath on any of these except maybe video functions (Jules has said in the past he wants to expand the video functionality a bit).
no reply from JUCE official?
？？？…
None of those are on our immediate roadmap but as always we’re happy to take a look at pull requests and potentially merge them in if they’re useful features.
I’m wondering about your point 5 above. Wouldn’t that mean that the font and size would differ between different OS (Mac Windows, linux etc)? Which in turn would make the appearence of the application differ which I think is bad for a number of reasons.
My humble suggestion is to implement a bunch of good-looking sliders and knobs that could match the look of other professional plugins…
Totally can’t understand why not? so weird.
I think such as this perception is unrealistic any more after JUCE has been purchased by ROLI and 5.0 released with that splash AD and the strategy of user data collection secretly…
It’s not unrealistic at all - we merge in pull requests frequently. However, most of the time we don’t do it directly as we can see better ways of adding the same functionality.
I don’t see what this has to do with the splash screen and analytics, or your opposition to them. These are mandatory only if you want to release a closed source application on a Personal license. Releasing a closed source application without paying for a subscription was not possible before JUCE 5.0, and the splash screen and analytics allows JUCE users to do this. If you were previously releasing closed source (or GPL) JUCE applications then nothing has changed.
I also object to your notion that we are collecting data in secret. It was announced on the forum, it’s flagged up online, a pop-up when you launch the Projucer for the first time, clearly in the Projucer settings, and the source code is not disguised.
