# Alternative juce docs **URL:** \ **Category:** Audio Plugins\ **Created:** [April 24, 2025, 6:35am UTC](https://forum.juce.com/t/alternative-juce-docs/65903 "2025-04-24T06:35:10Z")\ **Posts on this page:** 17\ **Page:** 2
**Author:** ![asimilon](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/asimilon/32/4235_2.png) [@asimilon](https://forum.juce.com/u/asimilon)\ **Post date:** [April 25, 2025, 3:43pm UTC](https://forum.juce.com/t/alternative-juce-docs/65903/22 "2025-04-25T15:43:04Z")
> [@arcathrax](#): > > very fast but you would need to compile the Projucer app and this is likely not very suited for a complete beginner. Also you need to keep in mind, that beginners are often afraid of the terminal If you can’t even compile the Projucer then you probably shouldn’t even be trying to learn the rest of the framework yet, because at some point you’re going to have to compile the Projucer (and it was endlessly having to do that which pushed me into CMake). And again if you’re afraid of the terminal, perhaps learning C++ and JUCE isn’t the right initial step on the journey. These are of course just my opinions and can be safely and roundly ignored! 😂 ![image](https://us1.discourse-cdn.com/flex026/uploads/juce/original/3X/e/f/ef08c2f5544448b1ae3ff09d7be844921c3758a2.jpeg) My main point is that I’ve learned plenty of times from “beginners” guides very bad habits. The trick would be to explain the good habits to beginners in a way they can understand. Perhaps easier said than done though. ---
**Author:** ![arcathrax](https://avatars.discourse-cdn.com/v4/letter/a/c37758/32.png) [@arcathrax](https://forum.juce.com/u/arcathrax)\ **Post date:** [April 25, 2025, 5:12pm UTC](https://forum.juce.com/t/alternative-juce-docs/65903/23 "2025-04-25T17:12:57Z")
Don’t get me wrong, it would make sence to create such a tutorial, but it’s not very suitable for a beginner. I don’t assume, that the reader has any knowledge about CMake and just wants to do stuff like the framework wants to. CMake is very powerful and so is git but in my opinion, it would not make sence to throw CMake, Git, JUCE, maybe even C++ at a beginner. I get your point but I think, this is the reason why so few tutorials are actually great. They assume, that there is a huge amount of pre-knowledge and not just let the reader decide, what he already knows. Maybe he wants to know everything from ground and maybe he just wants a code snippet. Either way, its better to explain everything for the first example since someone who wants a code snippet maybe doesn’t really know whats happening and wants to learn about it too. ---
**Author:** ![ibisum](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/ibisum/32/21288_2.png) [@ibisum](https://forum.juce.com/u/ibisum)\ **Post date:** [April 25, 2025, 10:31pm UTC](https://forum.juce.com/t/alternative-juce-docs/65903/24 "2025-04-25T22:31:40Z")
I see it more like this. There can be a tutorial for C++ development in JUCE. There can be a tutorial for how to maintain a build infrastructure to really exploit JUCE’ crazy multiplatform and multihost capabilities. There can be a tutorial to focus on only GUI, only DSP. Well, you get the point. But, if the standard were set for all ‘next-gen tutorials’ that are part of this effort, please just make a spec for the tutorial whereby, git usage is encouraged, if not required. The reason for this is, JUCE with CMake and git make for a _very_ interesting constellation of tooling and methodology practices, which - in the right balance, produce amazing stuff. You can’t just throw C++ into the JUCE context (but of course must), and not cover the rest of the pieces, which are actually also related to why C++ is being so well and effectively applied in this project. Learning to tame CMake will actually make you a better C++ programmer, because C++ programmers must, by necessity, understand tooling, architecture, and execution environments rather well, in order to write effective code. Also, there can be beginner and advanced tutorials. CMake is not advanced, imho, its also good for beginners. As long as the tutorials follow similar principles, I’m sure its going to be great to see. ---
**Author:** ![ImJimmi](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/imjimmi/32/10843_2.png) [@ImJimmi](https://forum.juce.com/u/ImJimmi)\ **Post date:** [April 25, 2025, 11:03pm UTC](https://forum.juce.com/t/alternative-juce-docs/65903/25 "2025-04-25T23:03:14Z")
It’s worth considering that a lot of people come to JUCE because they’re musicians/producers who just want to have a go at making their own plugin - not because they’re wanting to start a career as an audio programmer. Sure best practices are good to impart if that’s what the person wants to learn, but if they just want to learn how to write some basic code to make weird sounds then there should be a tutorial for that too. ---
**Author:** ![sudara](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/sudara/32/8071_2.png) [@sudara](https://forum.juce.com/u/sudara)\ **Post date:** [April 26, 2025, 4:13pm UTC](https://forum.juce.com/t/alternative-juce-docs/65903/26 "2025-04-26T16:13:21Z")
Wanting to lower barriers is definitely a big driving force for why I bother writing or blogging anything. Even selfishly, it could also be future-me in 6 or 12 months wondering wtf hurdles I jumped through and why. C++, JUCE, git, CMake — all very “deep” worlds, but each of those barriers can still be lowered and best practices communicated to save everyone time. Doing so might be the difference between someone sticking with learning things vs. giving up because they feel everything is esoteric, crusty, or just not clear enough. That being said, I agree that learning 10 basic git commands in 2025 is a good idea, otherwise you’ll be locked out of a lot of third-party stuff, collaboration options, and basically all modern development best practices. In other words, there could be a “Getting started with git” section it the API docs which shows a few basics for anyone wanting to level up. Grateful for this discussion! ---
**Author:** ![sudara](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/sudara/32/8071_2.png) [@sudara](https://forum.juce.com/u/sudara)\ **Post date:** [April 26, 2025, 4:25pm UTC](https://forum.juce.com/t/alternative-juce-docs/65903/27 "2025-04-26T16:25:52Z")
> [@ImJimmi](#): > > Also allows people to contribute to updating the tutorials with newer best practices as the framework changes The markdown version of the tutorials themselves are published but the goal was to make them public, thanks for the reminder! Re: more API docs like we’ve been talking about in this thread, for ease of getting them done I’ve been writing them in JUCE’s CMS (wordpress, which I’m very familiar with) but they could be transitioned to the same markdown-\>wordpress flow that I set up for the official tutorials. ---
**Author:** ![Qfactor](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/qfactor/32/14921_2.png) [@Qfactor](https://forum.juce.com/u/Qfactor)\ **Post date:** [May 8, 2025, 10:23am UTC](https://forum.juce.com/t/alternative-juce-docs/65903/28 "2025-05-08T10:23:23Z")
Imho git and cmake should be optional and tutorials should teach beginners the benefits of using them instead of imposing them as a mantra. In fact, I don’t get the point of using Cmake if you don’t have dependencies outside JUCE modules. I love the freedom of using any scripting language to preprocess data and later, handle permissions, generate installers, sign and test. Can somebody sell Cmake to me considering how expensive it is in terms of learning its syntax and adding yet another layer to install and maintain? ---
**Author:** ![sudara](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/sudara/32/8071_2.png) [@sudara](https://forum.juce.com/u/sudara)\ **Post date:** [May 8, 2025, 1:06pm UTC](https://forum.juce.com/t/alternative-juce-docs/65903/29 "2025-05-08T13:06:12Z")
> [@Qfactor](#): > > sell Cmake to me If Projucer works you, you are happy building individual projects locally and don’t have clear pain points with dependencies, IMO there’s no reason to feel any FOMO with CMake. I wrote the points I like about it here: > [@New docs for Pamplejuce](https://forum.juce.com/t/new-docs-for-pamplejuce/63676/10): > > For many, especially those starting from 0, it improves things because you don’t need to write all those manual build scripts in CI — everything is standardized. In your case, you’re already setup and running. So what is it that Cmake gives me? Other nice things are: Standardization across projects/teams and flexibility within a large maintained ecosystem. It’s build configuration vs. spaghetti code (build scripts). Scripts tend to be brittle across compilers/operating systems/versi… ---
**Author:** ![ImJimmi](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/imjimmi/32/10843_2.png) [@ImJimmi](https://forum.juce.com/u/ImJimmi)\ **Post date:** [May 8, 2025, 2:10pm UTC](https://forum.juce.com/t/alternative-juce-docs/65903/30 "2025-05-08T14:10:12Z")
> [@Qfactor](#): > > sell Cmake to me `-DCMAKE_UNITY_BUILD=ON` to save yourself thousands a year in CI costs with a single command line option. ---
**Author:** ![caustik](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/caustik/32/22449_2.png) [@caustik](https://forum.juce.com/u/caustik)\ **Post date:** [May 8, 2025, 5:30pm UTC](https://forum.juce.com/t/alternative-juce-docs/65903/31 "2025-05-08T17:30:21Z")
Is this any different than the JUCE module approach of a single cpp file which includes all the other cpp files? ---
**Author:** ![benvining](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/benvining/32/9922_2.png) [@benvining](https://forum.juce.com/u/benvining)\ **Post date:** [May 8, 2025, 6:01pm UTC](https://forum.juce.com/t/alternative-juce-docs/65903/32 "2025-05-08T18:01:11Z")
> [@Qfactor](#): > > don’t have dependencies outside JUCE Perhaps this is a style thing, but in my codebase, _most_ of the code is outside of JUCE/the module system. We only use JUCE for the UI and the plugin wrappers, but all the DSP/model/file handling code is “regular” C++. This might be more of a point for this project architecture than CMake per se, but adopting this structure of moving code into “regular” C++ libraries where possible has vastly reduced build times, especially for test executables. > [@Qfactor](#): > > sell Cmake to me CMake makes it easier to do testing, you can configure a test executable in the same project as your product, and the ctest program makes it easy to run all your tests & get a report. If you have any kind of “superbuild” with multiple plugins/apps in a single project, you can do this just fine with cmake, but AFAIK this isn’t supported by the Projucer. If you do have dependencies, cmake makes finding & managing them easier than Projucer. Any kind of options that may parameterize the build, cmake makes it easier to work with them. This is because cmake is actually a scripting langauge, whereas a Projucer project file is a static XML data file. > [@Qfactor](#): > > handle permissions, generate installers, sign and test All these things of course are possible within cmake. If you already have custom scripts for these tasks, it should be pretty easy to set up cmake commands to run those scripts. ---
**Author:** ![benvining](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/benvining/32/9922_2.png) [@benvining](https://forum.juce.com/u/benvining)\ **Post date:** [May 8, 2025, 6:05pm UTC](https://forum.juce.com/t/alternative-juce-docs/65903/33 "2025-05-08T18:05:35Z")
In theory it’s a very similar technique, but the CMake logic to create a unity build is a bit intelligent, it can do things like batch the translation units so that they’re all about the same size, or none is larger than some maximum size, etc. > CMake provides different algorithms for selecting which sources are grouped together into a _bucket_. You can read in depth here: [UNITY\_BUILD — CMake 4.0.2 Documentation](https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html#prop_tgt:UNITY_BUILD) ---
**Author:** ![Qfactor](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/qfactor/32/14921_2.png) [@Qfactor](https://forum.juce.com/u/Qfactor)\ **Post date:** [May 8, 2025, 6:49pm UTC](https://forum.juce.com/t/alternative-juce-docs/65903/34 "2025-05-08T18:49:33Z")
Interesting. It’s cool to hear how people are using CMake. Thanks! > [@benvining](#): > > If you do have dependencies, cmake makes finding & managing them easier than Projucer. I totally subscribe to that. > [@benvining](#): > > CMake makes it easier to do testing, you can configure a test executable in the same project as your product, and the ctest program makes it easy to run all your tests & get a report. > > If you have any kind of “superbuild” with multiple plugins/apps in a single project, you can do this just fine with cmake, but AFAIK this isn’t supported by the Projucer. I still think though that the other things that you mention can be handled in standard scripts (and python/bash/bat are more powerful imho if you need to do something ‘special’). Parametrizing builds with macro variables is not an issue, you can call multiple time Projucer in your scripts. Some things I like about Projucer are: dragging and dropping a bunch of resource files as binary data, having them indexed in a visual file tree where you can collapse folders and having theme-grouped dropdown menus + info tooltips about each option that can be configured in JUCE as opposed to having to memorize all those options (or having them commented in a huge linear configuration file) and having to navigate the CMAKE documentation. ---
**Author:** ![benvining](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/benvining/32/9922_2.png) [@benvining](https://forum.juce.com/u/benvining)\ **Post date:** [May 8, 2025, 9:17pm UTC](https://forum.juce.com/t/alternative-juce-docs/65903/35 "2025-05-08T21:17:58Z")
> [@Qfactor](#): > > python/bash/bat are more powerful That’s true, and if you have custom build steps that need to run a script, you can have cmake do that. You can also have arbitrary test commands to be run by ctest, such as invoking a Python script, etc. > [@Qfactor](#): > > you can call multiple time Projucer in your scripts Sure, but it’s still clumsy to actually get different data/options into the Projucer file, since the PJ file format is just static XML that doesn’t support any kind of variable expansion AFAIK. So I’ve seen multiple people doing things like writing scripts to auto-generate or edit Projucer files and then invoke the Projucer… IMHO that’s hacky and more complicated than just migrating to a proper build system that is designed for these kinds of more complex use cases. > [@Qfactor](#): > > indexed in a visual file tree Many IDEs have great CMake integration, personally I use CLion. > [@Qfactor](#): > > info tooltips about each option that can be configured in JUCE Are you referring to the various preprocessor flags that can be set for each JUCE module? That is a handy feature of the Projucer. CMake has no integration for preprocessor flags themselves, but for CMake variables/options, there is a TUI cache editor & GUI app available that will provide doc strings for each option. ---
**Author:** ![Toddler-Boy](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/toddler-boy/32/2007_2.png) [@Toddler-Boy](https://forum.juce.com/u/Toddler-Boy)\ **Post date:** [May 8, 2025, 10:07pm UTC](https://forum.juce.com/t/alternative-juce-docs/65903/37 "2025-05-08T22:07:55Z")
Sounds amazing. Would you mind sharing that script? ---
**Author:** ![Toddler-Boy](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/toddler-boy/32/2007_2.png) [@Toddler-Boy](https://forum.juce.com/u/Toddler-Boy)\ **Post date:** [May 9, 2025, 2:51am UTC](https://forum.juce.com/t/alternative-juce-docs/65903/39 "2025-05-09T02:51:40Z")
Can you share the part that creates the project files for MSVC and Xcode? ---
**Author:** ![nicolasdanet](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/nicolasdanet/32/56_2.png) [@nicolasdanet](https://forum.juce.com/u/nicolasdanet)\ **Post date:** [May 9, 2025, 4:56am UTC](https://forum.juce.com/t/alternative-juce-docs/65903/40 "2025-05-09T04:56:17Z")
Another topic hijacked by a CMake fight. 😆 [Previous page](https://forum.juce.com/t/alternative-juce-docs/65903.md?page=1)