Yes, I was thinking about having some kind of version range syntax. Haven’t quite got down to that level of detail yet though!
This is exactly how I work currently, and how I wish to continue working in the future. I keep my own private repo of the juce source tree. I like being able to view the juce source structure as individual .cpp files in my Visual Studio project. I like being able to double click to open those files, and I like being able to not only step in with the debugger, but if necessary make inline changes to juce source files.
I would not like it if I had to include a juce .cpp file in my project that consisted of many #include of other .cpp files. I prefer the static library approach. I prefer being able to see the juce source tree in its own Visual Studio project.
All of that will be just as easy with this new system, but it eliminates the extra step of recompiling the library when you make a change. But I know some people just like their static libs, so of course you’ll still be able to do it however you like.
I’m not entering the question regarding building the static lib over the include files approach.
What I have to say about this has been said before in this thread, but I feel like emphasizing that just to make it clear:
-
possibility to edit single JUCE source code files (meant to be more or less in 1:1 matching with the classes in most cases) is key for an easy debugging of things. Putting everything in single long cpp files, even one per “module” (enclosing tenths of classes or so) would make IDE too slow on loading/changing/and even scrolling those files. I’ve read that the single files will survive, so this part is OK for me as long as it remains this way.
-
possibility to use the JUCE library without Introjucer: I’m not currently using it, I’ve made myself some pre-cooked option sets both for XCode and Visual Studio by mean of .vsprops and .xcconfig files. Having to revert to changing them manually is just an horrific idea I can’t even stand
-
to me, it’s ok not having juce as an actual static library, but rather as a list of cpp files added to the project. also, the idea of having a module that does the part of interfacing to the files as a static “old style” library is a good idea.
-
modularity is a good idea, and also including third party code into this system is a good idea to me but please, Jules, let it be YOU the sole moderator that decides what goes through and what does not. You can become a very good reviewer as Linus Torvalds has been years ago for its Linux. Also, I’m convinced that the internal coherence of the whole JUCE lib is mainly due to the fact that it’s mainly written by a single person only, and also contributed code had to go through the same developer to get into the library. I think this is the most important of the points I wanted to list: I trust all the other developers that write in this forum, but think that only one should be in charge for deciding how to extend the library, otherwise letting free posting of juce modules would soon lead to anarchy.
Well, none of your points sound at odds with my plans, so that’s good.
Single files are the ONLY thing that will survive. The big amalgamated ones are gone.
I’m not proposing that any 3rd party code will make it into the juce library itself, but rather that other people will be able to offer their own libraries (with the author’s name clearly marked!) via the same delivery/install mechanism. But I’m not going to claim any kind of ownership of their code, and it’ll be up to each library’s owner to maintain it and to convince you that it’s good quality!
As I’ll be in charge of the master list of libraries, I will moderate it to avoid any junk getting in there, but what people choose to offer would be up to them.
[quote=“jules”]I’m not proposing that any 3rd party code will make it into the juce library itself, but rather that other people will be able to offer their own libraries (with the author’s name clearly marked!) via the same delivery/install mechanism. But I’m not going to claim any kind of ownership of their code, and it’ll be up to each library’s owner to maintain it and to convince you that it’s good quality!
As I’ll be in charge of the master list of libraries, I will moderate it to avoid any junk getting in there, but what people choose to offer would be up to them.[/quote]
That’s just great ! Will libraries which need 3rd party compoents (like boost) be allowed ?
Are they going to declare the exact version of JUCE they rely upon? Otherwise, they may stop working the moment that the tip introduces one of the (luckily few) changes that break some code
Hmm…thats a shame. It was really nice that I could just add a couple of amalgamated files to a simple project and voila, cross platform app!
It’s still that simple. The only difference is that behind-the-scenes, there are a bunch of other files being referenced.
The only advantage I can see to the amalgamated files is that if you’re adding a copy of them into your project, you only have to deal with two individual files rather than a folder of files. But really, that’s not a big deal. Adding a folder or adding a file… it’s not really much different. (Not to mention the fact that we’ll also have tools to automatically manage this process)
I don’t know if this is the right place to suggest this (not really a library structure thing), but, WIBNI the (new) Jucer/Introjucer had a couple of extra settings: Under XCode and VS (others?) build sections a few extras like Default location of libraries/SDK (drawn from an external, XML settings file)
I know it may seem a minor thing, but whenever I revisit old .jucer projects, I often find I have to fiddle with the projects produced afterwards to get it it build reliably on whatever target I’m using. Bits like the Pre-post build actions, locations of SDKs etc) - some of which could be drawn from a Jucer or Jucer-project Defaults settings file (for instance, rather than defaulting to “c:\SDKs\vstsdk2.4” and “c:\SDKs\PT_80_SDK” …)
- OR, perhaps reading the previous project file (if about to be re-written)and only merging updates in to parts that have changed.
This may sound pretty tricky, but in reality it might just be as easy as running a separate XML diff/merge action, where the user could manually nod-across updates… The user could skip changes or, pehaps repeat last action.
Am I just being too lazy? Just an idea.
… but aren’t there any more important things to do first? Like VST3 wrapper support (including all the nasty details such as sample-accurate automation and its involvements) or bugs to fix (like plugins crashing JUCE that do not crash any other host), increasing rendering speed, etc…?
I have the feeling that JUCE is getting more and more bloated, but the very things that make it unique (plugin support, good component system/graphics) are being put in the background more and more. Why not spend this time on making it better instead of making it bigger?
[quote=“zamrate”]
I have the feeling that JUCE is getting more and more bloated, but the very things that make it unique (plugin support, good component system/graphics) are being put in the background more and more. Why not spend this time on making it better instead of making it bigger?[/quote]
I think that Jules may be feeling JUCE reaching a critical mass, such that it makes it hard to be mantained “as a whole”.
Thus, I think that he is planning to re-structure the library to reduce internal coupling, so to have different smaller modules that have the minimum needed interactions among each others.
These such modules would be easier to mantain and also easier to extend by mean of contributed code. I wouldn’t be surprised to see the support for VST3 coming as an external contribution. Again, this reminds me of the evolution of the linux kernel source code… no surprise we ended up using the same source versioning tool that Linus itself wrote for the kernel
[quote=“zamrate”]… but aren’t there any more important things to do first? Like VST3 wrapper support (including all the nasty details such as sample-accurate automation and its involvements) or bugs to fix (like plugins crashing JUCE that do not crash any other host), increasing rendering speed, etc…?
I have the feeling that JUCE is getting more and more bloated, but the very things that make it unique (plugin support, good component system/graphics) are being put in the background more and more. Why not spend this time on making it better instead of making it bigger?[/quote]
Everyone has a different opinion about what’s important! For you, plugins are important, but some people never use any audio classes at all, and have other requests that are deal-breakers for them.
The bottom line is that I don’t have enough time to develop all the things that people are asking for, and the bigger the project gets, the more people will come along, asking for even more things… So I need to find a way to make it easy for other people to help out. VST3 is a good example, because at the moment that would be something that I’d have to write myself, because I’m probably the only person who understands all the complex twists and turns in the plugin classes. By cunningly modularising the codebase, I’d be aiming for a situation where VST3 support could be added as a standalone module (perhaps written and maintained by someone other than me!) without affecting anything else in the library.
Sounds good in principle… I’m only a little bit afraid of a possibly extended period of time where the new JUCE will be in a rather unfinished state, with obscure bugs etc. But well, sounds like in the end the hassle could be worth it.
I wonder if it’s time for a tea party? Should we arrange a meeting in London and discuss JUCE directions over a weekend?
Well, I’m always happy to have a beer and ramble on about stuff like this!
Sorry to interrupt there, especially as a no previous post guy, but this idea in my eyes is problematic at least.
Seperation of concerns in the library is a good idea, but the way you plan it effectively leads to a major rewrite.
Wouldn’t it be nicer to define a set of interfaces to adhere to, and effectively create a plugin system for the library subsystems
you can refactor components into one at a time?
This makes it less hard for you to re-structure the library, and enables others to write their own extensions with the guarantee
that it won’t break so easily?
[quote=“lucem”]Sorry to interrupt there, especially as a no previous post guy, but this idea in my eyes is problematic at least.
Seperation of concerns in the library is a good idea, but the way you plan it effectively leads to a major rewrite.
Wouldn’t it be nicer to define a set of interfaces to adhere to, and effectively create a plugin system for the library subsystems
you can refactor components into one at a time?
This makes it less hard for you to re-structure the library, and enables others to write their own extensions with the guarantee
that it won’t break so easily?[/quote]
I don’t really know exactly what you mean by interfaces/plugins in this context, but it sounds significantly more complex than what I’m planning to do! I’ve actually already done most of the work, and to modularise the code should now just involve me shuffling all the files into a new directory layout, without actually re-writing anything…
Okay, an example…
the audio system is a good thing to demonstrate this.
An interface would be something like the AudioProcessor class, which defines a generic audioprocessor without saying anything about it’s implementation (VST, AU, RTAS, LV2, etc.).
This would be a suitable candidate to go into a generic audio system component, into which you inject a plugin that provides the actual implementation, e.g. VST.
This way, you can leave out AU, LV2, RTAS, whatever, by not compiling the plugins providing these at all.
Right now, this is done via compile switches - doing this as plugins means you don’t have it in the juce core library at all, but inject it from the outside.
This would, to continue the example, enable people interested in, say, VST3, to implement an AudioProcessor implementation for VST3, by implementing an AudioProcessor interface.
The same thing would be true for the LookAndFeel stuff, or the platform specific functionality available to the application (registry access for windows, e.g.).
It would be clear what the extension points are, and how to inject one’s own extensions into the system. And it would mean that much of the actual implementation code for stuff that isn’t needed
for everyone, in every circumstance, in every application can be moved outside the core library.