Tutorial Issues

Running JUCE “Build Now” on the Tutorial: Create a basic Audio/MIDI plugin, Part 2: Coding your plug-in

results in the following error :
/Users/nicholascraftisiii/JUCE/tutorials/TutorialPlugin/Source/PluginProcessor.cpp: only virtual member functions can be marked ‘override’

and also :
error: /Users/nicholascraftisiii/JUCE/tutorials/TutorialPlugin_02/Source/PluginEditor.cpp: cannot initialize a parameter of type ‘juce::Slider::Listener *’ with an rvalue of type ‘TutorialPluginAudioProcessorEditor *’

I could be wrong, but these both seem like legit c++ syntax errors on the provided code from the tutorial. AFAIK you can’t override a function unless its declared virtual. Did I miss something or is this tutorial broken?

I propose the possibility of reworking the first tutorial(s) to make use of some of the nice things provided in JUCE, like the UI generator and internal building / jit compiler to get people excited about the benefits of the tool. Just a thought.

I also thought there were new tutorials but thus far they have been the same as I recall from prior versions. Am I missing something?

1 Like

Also just checked to see if it would somehow compile in Xcode and I get the same 2 errors.

Ok this brings up a good point of the structure of this tutorial… I just finally uncovered that I was missing one line defining the prototype of the private Slider::Listener at the top of the class, but none of the lines in the tutorial are really explaining anything… its mostly meant to be “copy paste this here” . but in my efforts to try and actually take something away from the tutorial this time through I was manually copying the lines that appeared different… This is a very poor way to learn something.

If you would like to check out something I think is a quality tutorial learning experience : thebookofshaders.com is rather awesome, it has inline code editors and explains in an interactive way that encourages exploration and real understanding of the concepts at hand.

The easy fix for the current tutorial would be to simply highlight the difference lines.

1 Like

I want to go ahead and stick my neck out here as well and give support to Nico’s criticisms of the tutorials. I’ve been at JUCE for 3 weeks coming from a web development background and minimal C++. I find it very hard to determine both the goal and flow for the tutorials. While some of the tutorials do seem to gently guide you through the creation of the project from start to finish, the majority I’ve encountered basically just toss a bunch of information on the page without any logical flow from start to finish. Additionally, there’s no progression present within the tutorials, they don’t appear to get harder or necessarily build in any kind of logical manner. The tutorials strike me as a hodgepodge of feature demos rather than true tutorials or walk throughs.

I think an easy way to immediately improve the usefulness and quality of the tutorials is to create a roadmap from start to finish through the tutorials so that strict newbies have a more manageable learning path to follow. Second, anywhere there appears to be gaps in this road map I would add additional tutorials or add additional information within the given tutorials to bridge the gap. Finally, I’d make the tutorials true walkthroughs, adding specific steps explaining what files to start from (the specific header in case of pips), where in the tutorial you reach checkmark headers (v2 or v3 of the pips). Generally highlighting the changes or steps would also be helpful, but there appears to be lots of handwaving going on in the tutorials.

Also, I think adding more obvious information to the docs and tutorials would be useful. For example, no where does the Logger class state that by default it goes to standard output/console of your IDE. This may be obvious to more experienced developers but it was not apparent to me the difference between Logger and LoggerFile. My initial instinct was Logger by default doesn’t work unless you pass it a LoggerFile or some other specific Logger. Only by asking a completely obvious question and more or less embarrassing myself did I manage to figure out that Logger by default goes to the terminal the ide.

I truly believe in and appreciate the JUCE community so I’d like to offer assistance to the criticisms. If the tutorial creation team needs testers or feedback or anything they think would help create better tutorials I volunteer to assist.


First of all, we appreciate the feedback on the structure of the tutorials and we understand how it can be frustrating to follow a tutorial only to have some information missing.

However, in the case of “Create a basic Audio/MIDI plugin, Part 2: Coding your plug-in”, the tutorial clearly states to add the inheritance and even suggests to follow the Listeners and Broadcasters tutorial to learn more about this concept. If inheritance is something new to you, then this is a core C++ feature that should be brushed up on elsewhere prior to learning JUCE.

As you can see, the approach we’ve taken is of a non-linear structure where we encourage learners to jump around different tutorials without a strict linear roadmap. The reason we’ve chosen this approach is because very few JUCE concepts are prerequisites to others, one can choose to learn one feature before another.

That being said, within tutorials we strive to have a clear progression from start to finish through different checkpoints and maybe this is something we would need to make clearer by referring to the corresponding version of the code at the beginning of each section.

If the linear roadmap structure of tutorials is something that would better facilitate the learning of JUCE compared to the existing non-linear approach, we would be happy to try that out.


This implies, that there is a finish.
I personally consider learning as drinking from an infinite sea of wisdom, there is always something left to learn. A list of tutorials, where the last one says “Now you are the master of Audio DSP and JUCE” doesn’t sound realistic… This is something institutes do, that sell certificates.


@jules @daniel How does moving from tutorials requiring less overall knowledge of JUCE to more overall knowledge of juce imply your imparting mastery? It’s just suppose to minimize struggling, that’s like saying you should start with calculus before algebra so you “drinking from an infinite sea of wisdom”. That’s a none sense perspective on education. Guiding people from 0 knowledge to some level of competence by building on skills is the basis of all education outside of programming, this is literally the only field where people think drowning in unstructured knowledge is wise or beneficial. The stated purpose of JUCE 5.3 was to onboard new JUCE users and when people new to learning JUCE have criticisms of the methods their told they are essentially approaching it wrong.

1 Like

I completely understand your wish for a guided tour through the quite big framework. I just objected the view, that there might be a path that is strictly linear and covers everything.
Maybe we can take from your feedback to have a list of tutorials “Before you try this, please do tutorials x, Y and Z”. But I guess, that’s putting people off in a different way.

IMHO the current approach of “what do I want to do” and choosing the tutorial, that sounds like it could cover that problem, would be a natural approach.

Maybe my analogy was a bit too bloomy, sorry if it sounded like bullshit to you… But in reality, there will always be something left, that wasn’t explained. And since the framework is also evolving at the same time, there cannot be one path. That’s all I wanted to say.

This structure has the benefit, that if a new way of doing things is introduced, people can look directly into that tutorial. And even tutorials with different approaches to the same problem can exist, like some prefer AudioParameterFloat, others the AudioProcessorValueTreeState approach. Would that educational path cover both?

I am not working on JUCE but other projects here at Roli, so it is not my say. But I can say, that your feedback will feed into the continuous process to improve things.

You can provide a linear-roadmap without structuring the tutorials. You can leave the tutorial page completely as is with one of the first tutorials being “Suggestions for How To Approach Tutorials” with basically a tutorial for the tutorials. I’m not even saying they have to be strictly ordered but gentle suggestions. An example based on my experience with the tutorials so would:

Getting Started -> Audio Plugin Pt. 1 -> Audio Plugin Pt. 2 -> Build a White Noise Generator -> Build An Audio Player.

but also

Getting Started -> Audio Plugin Pt. 1 -> Audio Plugin Pt.2 -> Graphics Tutorials -> User Interface Tutorials.

A roadmap like you might see in a textbook for multiple topic paths might be a good suggestion for presentation.


The fact remains that a sufficiently experienced developer doesn’t need as much hand holding so are less likely to be beholden to or follow a roadmap through a framework where as a novice more than likely will. Additionally, I can’t see how giving a suggestion of ordering going from least complex, least amount of api calls to most complex, most amount of api calls deprives the user of “drinking from an infinite sea of wisdom”.

I can only imagine that we simply don’t understand the others perspective entirely. I honestly can’t see where your concern is coming from because I don’t understand how providing a roadmap through (even if only through the first 50% easiest, also maybe tree instead of road would have been a better suggestion) otherwise unstructured tutorials would create this conflict in learning or catching new/advanced tutorials. In my post after yours I mentioned how I saw this happening, a tutorial for the tutorials with a suggestion for how to approach the tutorials and a roadmap. In this way very little has to change about the tutorials made and it shouldn’t affect anyone really.

I think the idea of “What do I want to do” and going to a tutorial is great and that’s how I tried to start. But I found myself having an idea somewhere in between, trying to figure out how to do it, and failing miserably… so I go to another tutorial so on and so forth. I’ve asked questions on the forum to get through some problems and have gone through about 11 of the tutorials. I haven’t so far been able to logically pick and choose stuff from tutorials to combine together successfully and I’ve even struggled through some of tutorials trying to figure out what each thing does. I’ve honestly spent way more time struggling through tutorials than I care to admit and literally only my burning desire to create audio software keeps me at it. I’ve messed with vstgui so I understand the alternatives but I was under the understanding JUCE was trying to remove the misery of audio programming.

As to your last point, I think again we just misunderstand what each person might be suggesting. I don’t think the structure of the tutorials needs to change, just make a tutorial at the beginning with a roadmap for noobs. I honestly think we can make every perspective in this thread heard and represented in the tutorials and their structure.

1 Like

To be honest, I am completely not qualified to comment on your suggestions, since
a) the tutorials were written after I learned JUCE, so I can’t know if they help a beginner plus
b) I already used three other C++ GUI frameworks, so for me many thoughts are just natural

I just repeat, the only thing I was commenting on was an attitude, that there is a path after which “now I know it all”. Some people in the chat ask “which course should I book” and things like that, suggesting, that this set would be enough to “be a professional” or whatever the goal is.
I say, be curious and try to pick up as much as you can. Some will focus on more DSP heavy stuff and leave the GUI to either the generic editor or let others do it, others are into creating awesome widgets. We cannot know, so I said, IMHO it makes no sense to have a single path and pretending, now you know all, or even enough for XYZ.

But sure, I support all your points, we want to give as much guidance as possible, and I am sure, the JUCE team will pick some of your ideas and bring them into the upcoming things. They are great suggestions, please keep that spirit.

I have not spent much time in C++ GUI frameworks or JUCE, but more importantly, I have not spent any time as any kind of admin or major contributor to a large software project. I know you are serious about helping others as you’ve helped me already and I’ve seen you help many others in other threads.

I could see how the worst examples of new users could spoil the rest, and I may have taken the comments more personally than appropriate. I can imagine there are many people who come and expect to learn JUCE in a week and demand of others to help them achieve that. I’ve wondered since my first CS class if programming was organized to keep out the lazy and uncommitted, I could see that being a useful filter, especially to those already committed to the craft.

I can at best say that I am a serious student and learner and my suggestions perhaps selfishly implore for changes that would suit my learning style, and speed me up to more advanced topics sooner. I hope it might be possible to find a compromise in making JUCE more approachable and easier to learn without encouraging lazy elements in the community.

Additionally, I will readily admit that any perceived deficiencies in the tutorials are more than compensated by the efforts and help of the JUCE developers, other people at ROLI and the community in general.


I am glad we could sort this out, like I said before, I think your suggestions are very good, and I didn’t answer to defend anything or to devalue what you suggested. I hope some of it will be picked up, you helped us a lot improving.

I was rather answering to a general attitude I found recently in the chats as well (not from you, lets not start that again :wink: ), that there existed something like a point when you are done learning. When thinking about it tonight I found the source of my thinking, which was a book I read a long time ago called “Siddhartha” by Herman Hesse. Quite a good read.

And on a personal note, I think there is no reason to worry too much about lazy newbees. I hope that people (me included), when they lose patience simply don’t answer instead of writing “you are in the wrong place, learn C++ first”. I think that is not helping anybody, but I understand when it happens, we are all human.


@daniel I have approached JUCE before once, and tried going through the tutorials and was able to successfully get this same tutorial completed. I am not sure what has changed since that prior version. I do see that there are a couple words in a small one line sentence above that block of code that mentions the inheritance. as I mentioned in one of my responses to my own post, I think a simple solution could be to HIGHLIGHT with a color text background the changes that you want to draw attention to… much like DIFF Checking, its hard to sometimes see with the naked eye immediately what is different in a block of code, especially when you provide the whole block again with one obvious new line… and in the prior section of the tutorial the changes were supplied as “add this line” and a … where the prior code would be and just the new line to draw focus to it… so there is a clear lack of uniformity to the way information is presented.

because everyone has different varying levels of understanding, styles and techniques they use in programming, they may draw different conclusions from the errors presented. I had no idea that the lack of those two words at the top of the class could be the source for the error that I received, and so my natural assumption to form based on my knowledge was to follow the error’s implication that the function should require a Virtual Void since it said “only virtual member functions can be marked ‘override’”

JUCE is overall impressive and full featured, and a clear route toward cross platform audio and visual application development, but since it’s so feature rich and making use of newer C++ features, it’s hard to know where to start other than the tutorials.

The obvious place to start as a new user is from the first tutorial, and the non-linearity can actually function as a potentially huge distraction from getting anything completed. When the tutorials tell me mid way through to go to another tutorial, and I am almost done with this one, what do I do? Go start up another tutorial and then go down each tutorial it suggests and end up with 5 half finished tutorials? I can’t imagine that ever panning out. What I think makes more sense is instead of branching off tutorials falling through a giant wormhole and never getting anything working, to add link to bits of relevant API Documentation, where the API doc has small examples of working code.

This is something I think works extremely well in the structure of learning MAX/MSP and how they allow non-linear learning. In MAX, at any time I wonder what a node does, I can option click it and get a full working example patch or patches that document the ways to use that node. this way you can fill in your gaps in understanding of that specific object and immediately chose to return to the main patch or tutorial… and you are never at a loss for immediate filling in of gaps in knowledge.

What I propose as a possibility, is that if the JUCE code editor featured a right click dropdown option that linked to the API doc for that object, with example of its use and what it needs to work, that would be pretty helpful. Possibly also links in the API doc to relevant tutorials.

In general I think non-linear learning is the way to go, but not as much non-linear tutorials. The reward of completing a tutorial that validates the learning process is the completion of a functional working example. I also think it is worth referencing that thebookofshaders.com site, they introduce the most bare bones simple example in the beginning and every concept is introduced in a way that encourages experimentation and exploration. The same is true of MAX. These methods give a bit more of a guided understanding of how to make use of the concepts provided beyond their scope, rather than blocks of code that risk not working if you manually copy them… based on my re-examination of these first tutorials, I feel even more encouraged to copy paste the blocks of text than to explore or do anything that would remotely help with direct retention of information. The current style of learning may work ok for wrote memorization, but not for understanding and creativity.

@daniel Nice book, I also like the Tibetan Book of the Dead translated by my dads friend Robert Thurman https://www.amazon.com/Tibetan-Book-Dead-Liberation-Understanding/dp/0553370901

1 Like

I should mention none of this is meant to bash or shed this in negative light, I want the best for JUCE newcomers and Roli and the brilliant minds involved in creating and providing JUCE.

One other criticism I have specifically relating to this tutorial is that it was pretty misleading in it’s title and as a person who wants to create Audio Plugins, which implies synthesis or DSP effects, and came away with a MIDI velocity adjustment slider… that is not what I would consider to be any type of audio plugin, nor anything useful to the majority of JUCE users. This tutorial should be called “Create a MIDI velocity adjustment plugin” cause thats what is made. Then when I need to figure out something like that I could actually track it back down and go through it when its relevant.

@almaclaine branching and start points could be a great structure to presenting the tutorials, there could be start points that would be “intro: build a basic …” and instead of branching off to other pages mid tutorial, you could encapsulate the blocks of learning information in a way that allows them to grow in a linear way toward a specific goal and present them in a visual branching path hierarchy at the beginning, so they could be followed in a linear way that you end up learning the process relevant to your desires.

This could actually work alot like the Projuicer project startup in a certain respect, and possibly could even be included within it. You could have a tutorial page with “What do you want to learn how to make” and then the options for Audio Effect Plugin, Audio Synthesizer, Audio File Player, Video Player, Standalone application for X, etc… Then these could load up the pip start point or relevant example with a guided “always on top” modal window with a forward and back button that show blocks of the text teaching and telling what to do in that step and could even jump to where the edit needs to occur. This is how Unreal engine does things and how Unity is beginning to do things, and it works great and you end up with a great on-boarding experience.

I think as a structure for a first audio effect tutorial that would both get me excited about JUCE and immediately introduce its possibilities, are “a basic audio effect tutorial” where step one is to use the GUI builder to make a slider, and step 2 is to connect it to a multiplication of the audio buffer for gain. Then from there that could branch into multiple options for more advanced effects/DSP tutorials like the distortion example, filters and delay lines, reverbs etc… and those could link to resources to learn more about DSP development, things like FAUST, PureData/Heavy compiler, Gen~ and C++ DSP

Then there could be a starting point for “build a basic midi controllable plugin synthesizer” that uses the synthesizer class and sets up a monophonic sine oscillator vst playable by midi and in part 2 extrapolates that into polyphonic with voice control. part 3 could be adding an adsr envelope that responds to midi velocity, part 4 could be extending the synthesis with different wavetables or even samples from audio files and basic waveforms, part 5 could be adding a filter, part 6 could be adding dropdown with multiple types for filter, part 7 could be adding an LFO that can be applied to the frequency of the oscillator or filter etc…

These are just thoughts from a relative JUCE n00b that hasn’t gone through all of the available tutorials yet, because I have been put off by them once and even though this time they would have still put me off despite the fact that they are marketed as being better in that regard, but this time I am more determined to help improve and advance as best I can.

1 Like

In general though, I think all of the initial tutorials should take full advantage of the awesome capabilities unique to JUCE, like the built in JIT compiler and GUI builder. I shouldn’t have to go through any other tool to get up and running and developing initially, those things should be separated into the final stage like “Tutorial: bulid project in Xcode” or visual studio or codeblocks etc…, and those can be presented at the end rather than at the beginning. I am trying to learn JUCE, not Xcode or android studio… at least in the on-boarding and evaluation phase.

Side note on that topic of mobile, as my main interest is in creating iOS AUv3/apps. I see a tutorial on android studio, but none on iOS despite the fact that the tutorials thus far I have encountered Xcode.

Personally I think that a linear interactive tutorial walkthrough in a modal window like the ones offered by Unreal/Unity are probably best for on-boarding of new users and the most exciting to run though. However, this would take up a chunk of our development time in order to implement such infrastructure for tutorials which we currently don’t have.

Considering that features like the GUI builder are legacy products that we don’t maintain anymore and the JIT compiler presents constraints such as default constructors and such, we suggest people to edit their code in their favourite IDE, whether it be Xcode or any other of your choice. In addition, these IDEs provide code completion and quick reference to documentation, which the Projucer currently doesn’t provide.

As for the highlighting, it would be difficult to implement that with the current tutorial structure as the code highlighting is done automatically for C++ between code snippets. The point of the tutorials is not to blindly copy the missing code but rather to understand what to add and why. However, I’d be happy to add comments to lines that are modified, just like some of the newer tutorials provide.

The suggestion given for a “basic audio effect tutorial” is without a doubt, on paper very exciting. However in practice, implementing a complete working plugin as described with all the parts mentioned is a steep curve in my experience and would go way beyond the “basics”. The current introduction tutorial starts with a MIDI velocity plugin because it teaches the very basic JUCE setup needed to expand on and as the title suggests, can work as a basis for an Audio and/or MIDI plugin.

Since DSP seems like something that a lot of new users are excited about, I’ll be adding more shortly and will be thinking about a “tutorial for the tutorials”.

Thanks for the feedback!

I just found this while searching the API doc : https://docs.juce.com/master/lesson_roadmap.html
Is that new?

That’s understandable, I realize Unity and Unreal are major players in the AAA multi billion dollar game industry and with their core engines so tight they have substantial resources to dedicate to on-boarding. They also have some pretty stiff competition with each other, whereas AFAIK JUCE kinda stands alone in being the go-to for the plugin market.

I have an idea / potential variations on that idea which could be more simple to manifest. One would be to make just one or a couple decent starter video tutorials. I was watching through the Cabbage / Csound tutorial videos the other day and just seeing someone else who really knows what they are doing explaining a few key core concepts in the most simplified basic way can be comforting in the early stages, making something feel more approachable. There are a couple people who have done video tutorials on Youtube that I have watched, and I have watched all the JUCE posted videos from the conferences as well. Some of these are great, but most of them aren’t geared toward on-boarding.

Yes! I am going through the DSP introduction tutorial now and I noticed a couple things I like, there are comments with steps like // [2] etc… drawing attention to those lines and linking them with more explanation in the text above. I also noticed some of the API was hyperlinked to more information which is really cool and in general I love that, though the “Type” link brought me to a Littlefoot enum which was a bit confusing until I figured out that littlefoot is a roli blocks scripting language (I think?)

Seems like you have most of the things I was suggesting in the new tutorials I am going through, just that they are segmented. I just think it would be a goal oriented slight reformatting of what is there into a cohesive learning narrative.

Yes I am finally getting that, I think that was a topic of confusion for a long time for me with JUCE, I made an assumption based on some comment text I read in one of the files that any changes outside the projucer would get overwritten, but I think that was my own misunderstanding. Also this brings up something else I was going to ask/mention. I have been LOVING visual studio and the way they do this. In general I am NOT a fan of xcode, and now Visual Studio works pretty great on mac, and even comes with the new unity installer. I was trying to figure out if I could use VS with JUCE on my mac, but it seems like currently JUCE only supports exporting to Visual Studio for windows. Would rock to work in one solid IDE on both platforms.

Seems like the JUCE audience really. We’re finding JUCE mostly through Audio Plugin Development and MAX / Roli, FAUST etc…

Thank you for reading it and considering :smiley:

This is a great thread, thank you @Nico_Raftis and @almaclaine for the passion you’re putting into learning JUCE and your in-depth feedback.

While we aim at being the best place to start learning JUCE, there are external resources that some may find better suited to a learning style, such as Romain Michon’s online course at Stanford.

Please do keep the feedback coming and if you document your own journey into JUCE, please post on this forum for others to learn from it!