Hi Jules,
As a software and services company we have been using Juce for our tools for 7 years and so far it has been a great experience.
You didn’t give details on the projucer plan, but I hope you don’t expand your target too much, and continue providing excellent tools for excellent developers :
considering how perfectionist and care taking you are, If you provide a tool for newbie programmers, I’m a bit scarred that you will spend most of your time doing babysitting and cleaning the forums after them.
as others said, I think most of your professional user base is ready to pay more. Paying a part of the license price every year is a guarantee that support will continue (also a little life insurance on you ; ) ) plus it is perfectly understandable as your product evolves continuously and considering the incredibly fast bug fixing support you give. I think a lot of companies are ready to share this as an industry effort to make our life better as Juce gets better.
Juce still needs to be better known to non audio C++ developers who are concerned with performance and efficiency.
I found back the link that made me discover Juce the 1st time from April 2005 (btw you should correct the dead link )
You recently did an incredible work with the OpenGL accelerated graphic context, and I think no one knows it in the OpenGL world !
I’m sure a lot of programmers out there would pay a lot to have such a powerful library to create UI over the existing OpenGL context their game/simulation/imaging/broadcast software…
Desktop software development is changing radically, and a lot of people now understand that user interface design is crucial (thank you Steve), but look at how many uncertain platform and API choices have to be made for someone who only wants to create a new, intuitive and responsive software user interface.
Audio people have been the first to have nice UIs, but this is spreading to other fields now and Juce should be known as the best tool for this.
You probably know all of this already, let’s hope it is part of your plan
I’m working over JUCE since 3 years and there has never been a time I felt that it lost the way… All the forum topics are very well answered and organized to deliver the solution soon as possible… Since I’ve joined I’ve seen wonderful evolution which has always benefitted everyone… I’ve been using it and recommending it to people who’ve found it cool enough to work as well…
See, I’ve not been using the audio support of JUCE to a very great extent like some of you people as I’ve been working over apps that are mainly cross platform with a classy and efficient GUI… So for me JUCE is my library to work open source plus cross platform and for all my needs I’ve always found a class inside it… So like Jules mentioned he needs interest from the people beyond the AUDIO world, which Projucer can certainly provide and that was the reason for everyone praising it…
Handling such a massive lib alone should be a Guinness record and he’s doing the best he can so there’s nothing more to expect… I love working with JUCE under the leadership of Jules, as I believe that whatever he does has a reason that shall be justified… I’m glad to know that you’re thinking over the future prospects and I’m sure that the next year will be splendid and satisfactory for everyone… All the best with your SECRET project, please keep us updated with it and keep in mind that you’ve always got our backs…
To be fair, Vinnie, the main reason I’m making the projucer is because I want to use it myself! Maybe that makes me a noob, but I’ve already found a bunch of places where it saved me a lot of time and hassle, and I suspect that when it’s done you’ll also find that it’s more useful than you thought.
It’s secret, but not new… Wish I could say more! Having a january deadline is awkward though, as I’d prefer to have been able to get the projucer done first, and it’s difficult to multitask on more than one big project.
Yeah, you know, that’s true - I’m proud of that 2D renderer. I’ll speak to the head of my marketing department and ask why they’ve not made more fuss about it in the openGL world!
Yes, of course! It’s clearly going to be an important platform, and I hope MS are successful with it, as Apple and Google need some decent competition. When will I support it? Probably february when things are a bit less hectic for me.
I find it really hard to believe that Jules could do it all on his own so far. The Lib is so amazingly great and comprehensive that I’d really have expected a team of at least 10 skilled developers to build it. And the coding couldn’t possibly be more cleverly done. I’m still baffled by the pure simplicity of the LiveAudioInputDisplayComp. Every time I have a look at such coding, it’s a real humbling experience. Plus the guy still has time to develop some “secret” projects on the side, unbelievable!..
I understand his desire to keep the highest standards for his library, and the difficulty of finding someone who will be up to the mark. I think the better option would be for third party programmers to work with him as freelancers and propose him new modules, for which he would have a say on the quality and features.
As far as the license fees are concerned, I must say this has been one of the best investments in my life, so I wouldn’t be against paying a little more if it was needed to get some new interesting stuff. But so far, I’m more than satisfied with all that’s already there. So if the licensing terms are to be reviewed, I would expect to have a system where you pay by modules, so that the basic ones still remain affordable.
Finally I wish other software companies would be as supporting of their clients as Jules. I don’t think I ever had to wait for more than a day for an answer to a problem I was facing. Keep it up Jules, you’re a genius, man!
Better collaboration is definitely a good idea. Project like JUCE needs a team to keep improving it.
In order to get a road map for JUCE we need to decide what to do and what to not do. In my opinion, JUCE should concentrate on the desktop platforms, instead of trying to support iOS and Andriod. The mobile apps are just too special to be written in the same set of code.
[quote=“cxhawk”]Better collaboration is definitely a good idea. Project like JUCE needs a team to keep improving it.
In order to get a road map for JUCE we need to decide what to do and what to not do. In my opinion, JUCE should concentrate on the desktop platforms, instead of trying to support iOS and Andriod. The mobile apps are just too special to be written in the same set of code.[/quote]
Not sure if I agree. VFLib is built on JUCE, and both are extremely handy. Platform-independent abstractions like synchronization primitives, threads, data structures, and the audio subsystem work great on handhelds! I think, that the “special” part you refer to is mostly having to to with the GUI which I agree needs work.
But thinking about what should be worked on, I feel that the areas deserving of the highest priority would be things that will provide immediate benefit to the largest number of people. For example, adding support for the new audio plugin type gives us a lot of bang for the buck. All a developer needs to do is update to the latest JUCE and recompile their app and then their users can enjoy new features. This is the kind of stuff that is really worth doing because it provides a large benefit.
You should be proud. It’s the sort of thing that ‘can’t be done’ in OpenGL - many people have spent years trying to do similar.
But (there’s always a but), it was ready at exactly the time that everyone else’s GUI went all-singing all-dancing 3D enabled. It’s a crying shame, to be honest, that I can set an OpenGLRenderer, but I can’t:
animate my components (trivially) in 3D space,
use OpenGL callbacks in any component in place of 2D drawing.
In my mind, with literally those two tweaks, Juce would leapfrog over Qt, Cocoa, whatever that Windows thing is, etc. The power is there - the APIs in use have the functionality.
It pisses me off when my XBox can animate every control’s appearance and movement, and it would be such a grind for me to do that (I’d have to essentially ignore the Component/Parent model). Not to mention that Mac, windows and modern Linux wm’s now animate every window and dialog on and off seamlessly.
So, has Juce lost it’s way: no. Has Jules probably broken projects down into slightly too big chunks, so the time in between them is vague and massive and frightening? I think so.
Yeah, 3D components would be cool, but a lot of work to implement - although it’d relatively simple to do in GL, the hard bit would be also doing it in the software renderer, CoreGraphics etc.
Jules, I’ll be interested in seeing what you’re up to at NAMM. I understand your hesitation regarding hiring another programmer: I’d have the same sort of problem myself. I wonder if you (if your budget allows) might consider getting an administrator/documenter. One of the more time-consuming parts of juce has always been finding your way around inside. And of course changes, deprecations and such can occupy a lot more time. Perhaps a junior coder/tech writer could help organize documentation and customer outreach. I’m sure you wouldn’t mind having that stuff offloaded.
What about a fallback to an alternative 2D style if OpenGL not available?[/quote]
I’d be more in favor of that. The joy of a single look and feel across platforms is wonderful, but having an app that feels old compared to everything else on that platform is not so cool.
I can see that expecting OpenGL (or other 3D API systems) for a basic appearance would lead to problems, but allowing more interesting transitions between consistent looks depending on the platform would be quite reasonable, it seems.
Where a 2D only renderer would just do a basic move seems like it would work and not mess anything up. It could be an override method (since I understand default params are no longer welcome), so no code breaks.
Bruce, you’re asking for is CSS3’s transforms (and for the API, jquery’s easing is the easiest to use).
All in all, everything boils down to what they agreed on HTML + CSS.
I think the initial/old idea Jules talked about when he was redesigning/preparing Juce2, would still be the best to have.
All in all, I don’t care if it’s OGL/Core2D/Direct2D/whatever, but I do care about the look & feel, and the behaviour of my application.
I would like to specify this behaviour out-of the code (but that’s something that’s out of reach right now), and if the platform doesn’t support it, I would like to specify the fallback behaviour like CSS does.
Currently, the animation framework in Juce needs lot of work, from fluency to features, but that’s not all that’s missing.
I’m afraid the projucer will lead to more static code finally (you’ll tweak your C++ code to have what you want exactly, but this also means that the possibility to change the parameters at runtime will be reduced/disappear later on).
IMHO, it seems the actual standard is to specify the L&F in a separate place, so it can be changed and tweaked without recompiling, it can be done by the final user, etc…
I wonder if the idea/software Jules is working on will allow deep hook inside the C++ code so he could plug an automatic scripting system to update the behaviour/L&F via external files.
The projucer is actually agnostic about things like that… It doesn’t matter whether you write a completely hard-coded C++ component class, or a component class which loads its content from some kind of external file, it doesn’t care, it just runs your code and shows you the result. If you wrote a component that dynamically loads itself from a file, it might still be handy to run it in the projucer, just using it as a handy UI preview tool while you edit your file. Sure, I’m writing a bunch of refactoring tools that understand the hard-coded C++ stuff, but eventually I want to make the whole GUI editor part customisable, so that it could be used for any conceivable type of UI design.
[quote=“X-Ryl669”]I think the initial/old idea Jules talked about when he was redesigning/preparing Juce2, would still be the best to have.
All in all, I don’t care if it’s OGL/Core2D/Direct2D/whatever, but I do care about the look & feel, and the behaviour of my application.
I would like to specify this behaviour out-of the code (but that’s something that’s out of reach right now), and if the platform doesn’t support it, I would like to specify the fallback behaviour like CSS does.[/quote]
The big Juce GUI design update that didn’t happen? Yes, that sounded good from a functionality point of view. But it’s been leapfrogged by other frameworks, where dynamic movement of controls has become the norm.
Specify fallback behavior would work too, but a 2D only transform seems like an easy drop-in for 3D. I suppose, now I think about it, there would be some GUI designs that use a 3D space (like a carousel picker) that really only works in some sort of 3D space.
If the OpenGLRenderer is available on every platform now, maybe we do need to be able to target an app to that renderer and get extra abilities, such as 3D Component positioning, custom shading.
Jules - do you suppose that anyone who has targetted the OpenGLRenderer would really expect to be able to add a new target on a non-GL platform, or switch renderer and expect it to be exactly the same? We’re talking developers here, not users.
No, not at all. Actually, if I had time to actually implement this, what I’d do would be to replace the component’s 2D transform with some kind of virtual class that can perform any kind of mapping, e.g. 2D or 3D transforms, mesh deformations, animated transforms, etc. That way, it’d be possible to only allow the the non-2D transformers when there’s a GL surface involved. This is all stuff that I’d love to see happen, but just one of the things on my mountain of “cool ideas that need doing”.
And I do think that before long, GL is going to become the default engine on most platforms. Certainly once it becomes safe to assume that nearly all Android devices are GL-capable, it’d make sense to just always use it there.
No, not at all. Actually, if I had time to actually implement this, what I’d do would be to replace the component’s 2D transform with some kind of virtual class that can perform any kind of mapping, e.g. 2D or 3D transforms, mesh deformations, animated transforms, etc. That way, it’d be possible to only allow the the non-2D transformers when there’s a GL surface involved. This is all stuff that I’d love to see happen, but just one of the things on my mountain of “cool ideas that need doing”.
And I do think that before long, GL is going to become the default engine on most platforms. Certainly once it becomes safe to assume that nearly all Android devices are GL-capable, it’d make sense to just always use it there.[/quote]
That’s good news. There’s some some FUD over the years about GL going away, but all the tablets seem to have guaranteed that it will keep going: in some form.
So, the Component/Parent structure would become some sort of Scene Graph? It already is in a way. Cool.
)
projects on the side, unbelievable!..
