Supporting Projucer

Like seen in that other post a lot of people move from projucer to cmake. I don’t wanna hijack that post because my post’s perspective is a different one. I wanna give you arguments for why it’s worth it to support projucer instead of cmake.

I’d like to point out that audio dev seems vastly underdeveloped compared to game dev. you’ll see why this is important. i mean when you start up unity there is a program that manages your projects as well as each project individually and each project is opened in a dedicated editor with a 3d environment and everything where you can place prefabs without programming experience. even c++ environments like unreal have things that make setting up logic easier. i don’t wanna talk about all this here, and game dev is certainly not the holy grail of how every programming environment should be but i’d say audio dev can learn a lot from it workflow-wise because lots of people make games, obviously because it’s easy to do so, and that’s just cool.

So coming back to juce: i’m still more of a musician than a programmer after around 3 years of programming and using projucer is a major reason for why juce is not gatekeeping us musicians from participating in this wonderful craft, because we can easily set up projects.

But some people argue projucer is only for the newbs and everyone should move to cmake once things get serious, which is a sentiment that doesn’t exist in game dev or only in special cases i guess, and i think that shows that projucer has the potential to change our collective perception about this topic. In order to do we’d just have to eliminate the reasons for people to move to cmake.

The most major reason to switch to cmake seems to me when people try to make their own project templates and libraries on top of juce, cause rn if you do that with a projucer-based project you have to manually copy files, change the plugin id, and visual studio constantly warns you about using files from another project even though you clearly copied everything. that is not impossible or hard, but it feels rather sketchy and unprofessional. if the projucer could just have user-made templates that would basically solve this entirely.

Another reason that often appears is that people wanna make entire plugin suites, so they use cmake to handle updates in the code of shared files so that every project then gets rebuilt. But if the projucer had a new highlevel area for managing all projects then that area could also be in charge of updating these changes.

There are probably lots more ideas that could be added to make cmake obsolete and you are all invited to discuss them on this post, but these are the 2 aspects i’d consider most relevant.

You are also invited to discuss my initial theory: wether it is in fact good to support projucer in an attempt to make the gap between musician and programmer smaller, or if you think it’s just not worth it to try that for some reason.

4 Likes

I love Projucer. Didn’t know it needed supporting

idk if it needs support, but i feel like a lot of people tend to talk against it rather than for it, so that could lead to the perception that it’s bad. i just wanted to point out that it’s actually great even if it needs improvement

More time spent on Projucer is less time for Juce itself.
Hence my vote again Projucer.

Even if you are a newbie, you can copy/paste clean cmake example (which juce lacks currently AFAIK)
and be ready in 1 min where it would take more time in Projucer.

5 Likes

i think it might be true that a perfectly setup cmake file has the potential to accomplish some tasks a bit faster than projucer. but even getting to the point where your cmake file is good enough to do all the things remotely as elegantly as projucer does already you’ve spent weeks or months researching a weird new language. and that is exactly what keeps people from trying at all. i once had a cmake file that was sorta nice, but smth was missing. i think it was that functionality of automatically adding things to binary data, that projucer offers. and cmake is also missing automatic code creation as far as i know

1 Like

Sorry, I may be an exception, but I never really felt comfortable with Cmake. Projucer on the other hand provided a very clear UI to customize everything and generate flawless projects across multiple platforms. Don’t see what’s not to like about it.

5 Likes

If you are a newbie then a perfectly setup cmake file is just a copy/paste from different example will do the job just fine. Even for binary data.
Currently juce documentation lacks such examples but this is a one day job while maintaining ProJucer takes way longer than that.

3 Likes

What is this automatic code creation ?

what projucer does. you make a new plugin project and it automatically sets up names of classes that correspond to that project’s name and stuff like that, which is more than simple copying

a little additional thought to think of: having a dedicated application for project management, especially when it comes to handling all projects together, has the potential to keep on adding features over time that would make it even more ridiculous, in a good way. i could for instance imagine a future, that is arguably not around the corner but imaginable, in which the projucer has a connection to the internet, informs about and handles juce updates or lets programmers buy prefabs of plugin designers lookAndFeels and stuff like that. that would levitate audio dev to something that truly has a futuristic workflow, because you could make complex things way easier. and people would suddenly make cheap plugins with other reverbs than juce’ default reverb, because that prefab store would have some passionate dsp programmers selling their stuff as well. and ofc a graphical editor for basically everything, no matter if visual or abstract logic. so you can see that is just way beyond what cmake will ever be able to do

2 Likes

This is a completely different app you are talking about…
One that probably shouldn’t do any project creation or code management.
What you have in mind is Synthedit

1 Like

I’ve never used cmake, it just seems like another thing to learn. I have an extremely complicated project under development for several years, mac and windows, and the Projucer really does a great job of keeping everything organized and cross-platform for me. I’m not sure what cmake would improve for me… I would vote to see Projucer received continued support. :slightly_smiling_face:

3 Likes

i’m in the synthedit facebook group and a lot of things people complain about there is that when some module doesn’t perfectly fits their needs they can not do anything about it. the entire array of possibilities is dominated by the few ones who make these modules. this would be different with juce, because juce is based on coding and not on the visual stuff. the visual stuff would just be added on top and that’s why it’s a better approach. people can always go into their stuff and make it fit. you don’t rely on the visuals.

in synthedit’s defense: people typically make huge synthesizers with synthedit, like ones with 100s of knobs. while juce projects tend to be really small plugins. i think that shows that small plugins are at least as cool as big ones ofc. but it also shows that juce has something to it that discourages programmers from making the projects too ridiculously large a lot of times. and it might not be something that we do consciously, but whenever we think “oh no, that’s kinda annoying” we should just stop, take a breath and remember that we might accidently make a decision not based on what the product needs in order to be the best, but just because it’s more complicated than a different solution.

and i think it could be the same app… in a much later iteration of it. i mean, why not?

When you have a big project under development each change in your environment is a painfull process you really want to avoid in the middle of your work. Specially if your are not paid for that. JUCE is friendly with GPL and students and amateurs, not just PRO users.

1 Like

I disagree with this. Game development has a visual environment like Unity because that’s what’s necessary for creating an immersive 3D world. Something like this simply isn’t necessary for audio plugin development.

is it? :thinking:

I don’t disagree with your suggestions for improving the Projucer, like project templates or higher level multi-project management, but consider: if Projucer becomes sufficiently advanced, it will eventually become just as complex as CMake.

I think one of the best things the Projucer could do is get rid of .jucer files and replace “save and open in IDE” with a button that exports the project as CMake code, and runs CMake configure on the generated CMakeLists.txt.

We already see many instances of critical bugs and valuable feature requests taking weeks or months to get addressed by the JUCE team. They clearly have their hands full maintaining the JUCE modules codebase without writing and maintaining a bespoke build system. From a business perspective, I think it would be very foolish for them to sink most of their time into the Projucer, because that’s a secondary product to the actual C++ codebase.

I don’t disagree that the Projucer can make the entry barrier to learning JUCE for the first time a bit lower. However, when you get right down to it, JUCE is not really intended for use by non-programmers. For musicians that aren’t interested in learning programming, there are many other tools available, like SynthEdit or Max/MSP. No matter how easy the Projucer makes project setup, once you’ve got your IDE open, you need to know how to program in C++ in order to be able to use JUCE.

This is just simply not true. There are plenty of huge products built with JUCE. Everyone from Antares to Izotope builds their plugins in JUCE.

I don’t think this is true. But if anything, I think maintaining a .jucer file would be the limiting factor here. In my experience, maintaining a large plugin project is much more difficult with the Projucer than with CMake.

One big reason for using CMake that is not mentioned in your post is that it is a C++ industry standard. If a C++ developer with no JUCE experience comes across a repo with a CMakeLists.txt, they already know how to build it and have some bearings on how the repo is set up; if they encounter a .jucer file, they will be thinking, “what the hell is this XML file”, because no one outside of the JUCE community uses the Projucer or even knows what it is – why would they?

One very common sentiment I see/hear from JUCE devs resistant to adopting CMake is that it’s either too complicated or they don’t want to spend the time, it’s something else to learn, etc. This is true. However, I don’t understand the resistance to investing some effort in build system setup. If you are a professional programmer, your build system is a critical part of your codebase, and it greatly affects your productivity. If you’ve got multiple plugins to maintain and you’re using the Projucer, I would argue that you have some pretty significant technical debt that will only continue to grow the longer you wait to switch to CMake.

3 Likes

cool to have you here as well. you had some interesting points.

i disagree partially. while most games are just completely impossible to play without graphics audio plugins also depend on the graphics a lot. you can try to make certain things accessible, like knobs, textboxes and faders but the language that is spoken through the layout of the whole plugin interface is what makes or breaks its intended workflow. imagine soothe without that pro-q-style pre-eq, but with lots of filter knobs instead like on an analog console. almost no one would use or be excited about it. a lot of great plugins nowadays depend on visual properties and utilize them virtuosly.

i think it is. try unity. it takes you less than a day to learn how to make a simple sidescroller game. that’s what a juce gain plugin is to the game world.

*more complex

or maybe just have both buttons there. i like your idea but it’s nice to open the IDE from the projucer. it also ties into my concept to have the visual programming environment closely tied to the coding programming environment.

i know. it feels kinda silly to make any FR at this point. but maybe i’d consider this more of a roadmap request than a FR. nothing that should be solved right now.

this is where i clearly disagree. and this is an important point of my concept: imagine a projucer that becomes so powerful that it has its own prefab store one day and stuff like that. that would essentially mean that the juce team can stop its entire efforts in making good filters, reverbs or even components, because it is all outsourced to the community to make these things. and the community will make the things, because it is not only a passionate community but also one where a lot of financial interest is in. so now with the newly gained time on their hands the juce team can put more effort into the basis of the framework, which would then be to make and maintain this super powerful projucer and the core of the audio engine ofc.

i know but i’m thinking about free plugins. i’m testing a lot of them and i can always clearly see when something was made with juce. looking at free plugins is a great way to determine how large-project-friendly a framework is, because when projects become too large without financial motivations people often give up to go deeper it seems.

may you explain how you came to this conclusion?

oh yeah that’s true. i give you that. so that’s basically the same accessibility argument i made, but not from a musician perspective but a programmer one.

i’d say atm you’re right, and if one doesn’t learn cmake at some point that can slow you down in the long run. but i just wanted to make this post so people see that the conclusion from this should not be that cmake is better than projucer, but that projucer could be way more than what it is right now and then it would have the potential to exceed cmake in the context of audio software, for the given reasons… features that are just not possible in cmake, but only in a software that was specifically designed for the stuff we do

A kind of “prefab store” doesn’t really need to be tied to the Projucer. Look-and-feels, components, or audio processing classes are just C++ code, so they could be added to a project just as easily with CMake.

I don’t think a store like this is necessarily a bad idea, but I doubt it will happen any time soon because it sounds like a licensing nightmare, for both the JUCE team and the programmers using these assets.

I’ve worked for several companies that have some shared code and multiple plugins that each have their own .jucer file. If you want to add a file to the shared code, you have to manually open each plugin’s .jucer file and drag it in. Plus, with the Projucer, you can’t create an IDE project that has all your plugins in it, you have to open them one at a time – so for any change you make to the shared code, you have to open each plugin’s .jucer one by one. Changing anything in the shared code, even something small and trivial, becomes a 30 minute job instead of 5 mins with CMake. With CMake, it’s changing 1 line of CMake code to add the new filename, and you can open 1 IDE project that contains everything you’re maintaining and build it all at once to check that you didn’t break anything. It is not an exaggeration to say that being forced to use the Projucer instead of CMake makes my development process take 5 or 6 times as long.

I haven’t heard you describe anything so far that isn’t possible in CMake…

1 Like

+1

5 Likes

yeah totally. lots of problems to solve. but still. if it was done one day then that would cause less responsibilities for juce when it comes to all these lower level things.

yeah that sucks. that’s why a projucer that manages all projects together rather than 1 project at a time could be very helpful in the future. you could make these kinds of multi-project projects and share stuff from templates to newly made projects flexibly… just like you can with cmake, but with an interface that doesn’t give you cognitive load before you even started coding. using cmake feels like using commandline tools to me. it’s all super abstract and it looks cool and techy, but it’s not the best way to represent project management. i wanna grab modules and drag them onto a project and these things should have little rectangles with thumbnails just like sample packs, but less cheesy. so that the thing we do actually fits more to how we feel about the things we do. it’s just a ux-thing.
you say just change one line in cmake to change one of the project properties and you’re right but there’s always the possibility to make lots of mistakes when the changes you make don’t do what you expected them to do. and then you suddenly did damage to the project or something. it always feels a bit scary to me and projucer doesn’t feel like that because every one of its functions was curated by the juce team to make sense in the context of audio development projects and you can be pretty sure that it works as intended.

i mean why do we care so much about ui/ux in the things we create for others, yet pretend like we don’t want ui/ux for ourselves too?

1 Like

Maybe you could give this companies a tip and tell them to put shared files in a juce module :wink:

Am neither on one side nor the other, but currently the jucer files work well for me as a multi platform abstraction layer, I don’t see any necessary to switch to cmake soon (as long I not being forced to do so)

5 Likes