Improving JUCE docs with wiki?

I was having a really hard time figuring out how to use juce for what I want just based on the class index. Would anyone be interested in throwing some money my way to start working on a wiki to supplement the documentation on the website?

Please don’t take offense to any questions here. Seems helpful, but odd that you are looking for compensation. While I consider myself a ‘pro’ juce user, I rely heavily on the docs to help me get work done, so if there were more useful info available, that would be good. otoh, documentation is only as good as it’s accuracy, so it always needs attention. I am not sure I would feel comfortable investing in a persons time to create something that then requires upkeep. and since anyone can create a wiki for free, what value are you bringing to the equation the brings value to the wiki? As well, you did not describe how the wiki would improve upon the existing docs. along with all of the free content on YT… Kudus for the effort. :slight_smile:

I hope to consolidate a lot of information to be more clear. I found personally trying to reference the tutorials and class index alone to be lacking in examples and a more clear link between how some classes are dependent on one another.Tell you what; I will get to work on writing something for my own personal use, and put it out there for people to look at.


What about adding Patreon or other funding options to your documentation/site?


1 Like

So many people think about money before thinking about their own education, the real value they get by just learning the work of others, frustrating.

Sorry if it sounds a bit ‘hippie’ here: but what about starting contributing and sending pull requests?
JUCE is free up to 50K/year if you earn more than this thanks to the toolkit it would not feel as if you would be giving too much of your time for people that made you win by adding an extra payback making the doc better ?


I’ll get to work.

1 Like

What I look for most is examples. Perhaps this website could have a new category where users can post short example code for the benefit of everyone. The gurus can do code review.

Food for thought…

The darn message mgr alone is pretty important.

How about the Tutorials documentation ?
Not enough examples there?

Those examples are tied directly to prebuilt projects that don’t tell you anything about how to roll your own JUCE projects from scratch, or anything more clear about the dependency between the classes listed.

I’d argue that if you are clean developer you don’t actually don’t want rely on a low level knowledge of dependencies that may change on the next major release…

Also obviously, Projucer makes it very easy to start with JUCE and is in the first section of the tutorials, then what other dependency you need?

Are you working on a DAW development that requires a simple ASIO folder and use JUCE_ASIO=1 dependency?

Because it seems to me that pretty much everything else can be learned from the the Projucer wizards build outputs.

What I found lacking the most is not examples, but structured descriptions of how the systems work. There are many parts of Juce that form pretty related webs with known usage patterns, and the examples are usually too simple and concrete to involve all the parts that you have to connect. I learn these things by navigating the source with many files open and tracing the paths of related operations until I have a mental map of the whole thing. It took me about a year to learn maybe 20% of the framework this way, and I keep finding missing pieces where I reinvented the wheel because I didn’t know some class existed.


Taking one year learning 20% of about 340K+ lines of well written, compact code is not shameful.

And I think we all do reinvent the wheel from time to time, but there are great search tools with regex search you could use for finding classes candidates to reuse and also the modules classification in doxygen should help navigating through it?

All that helps, of course. I just say that, if I were to put some effort into making the docs better, I’d start with “big picture” guides of the main parts. Except for some functions, the specifics are very well covered by the class reference. The difficult part is starting. The tutorials leave you with snippets -parts of the whole that you more or less understand but don’t make complete sense together. It takes a while of being a bit lost in a sea of code to connect the pieces.

The Tutorials are great! But they do not cover everything.

Everyone learns in their own way. For me, if I can study an example, a code snippet, which illustrates how something is used in working code, I am well on my way to being able to incorporate it into my own code. Then, tracing through the juce module source can expand on that knowledge.

At least that is what works for me.

Just adding here:

There were many attempts, none consolidated up to now.
I think the best bet is to start writing a good fundament and collect all the people who offered help in previous posts.
It is not the lack of information, and it is not the lack of willingness to help, it is to start and keep going, get it over the first few iterations, so it becomes interesting to contribute.

Too many efforts that were started and left to rot.


First of all I think I can understand the wish for such kind of documentation/tutorial/wiki/whatever. I would have wished for something like that when I started with it all a while ago. Today, I personally don’t really find this necessary anymore for me as I learned a lot about programming in general and specifically C++ and JUCE over time. This also applies to learning to use and understand new other (much worse documented) libraries which might have seemed super complicated to me when I had fewer C++ experience but are relatively easy to understand today, just because I got used to read C++ fluently.

Now if I had written a Wiki like that after e.g. my second year working with JUCE I guess that today I would not be happy with the quality of the result anymore – the same applies to code written by me back then :flushed:

This should really not be an offence to you @Willogical, but I think that’s one of the reasons why paying you to do something like that won’t convince too much people round here. Without having seen any piece of code written by you, I honestly don’t expect someone who considers themselves in the need of such a wiki for their own work to deliver e.g. best practice coding examples that explain how things work or should be done.

Still I don’t want to demotivate you, I really like your idea. I guess if you started a project like that with community contribution in mind, there are chances that other experienced and not so experienced juce users might join you and that a this community would create a great project together. Experienced users out there might not even remember some struggles we all had as newcomers and would not even have the idea to write an page on certain topics. Now if you write a wiki page on that and some more experienced contributor finds something in your explanation that’s not completely right they might correct it and so a great knowledge base can grow, answering newcomer questions with knowledge of more experienced users – do you get what I mean?



IMO The fairly large piece (even if way smaller than JUCE) of code that needs to be more documented is probably the tracktion code, which Dave would certainly confirm has room for improvement.

Earlier, I proposed to contribute to tracktion engine doc in another thread, even if I’m not new to development ; I am still new to audio app development and still learning a lot more that I already know there, so if you are interested to help we can certainly combine our efforts and propose more pull requests which I started to do.

Accessorily, I am currently starting to develop my own GPLv3 DAW that will be starting to be small, ridiculously simple and almost a copy / paste of the midi recording demo and it will be probably available very soon on my git hub pages …

I know it may take me at least a year to get something people start to be using but if I get interesting pull requests from other devs, it may be a quite nice experience or not but in all cases, we will learn a lot …