#1 most common programming mistake that we see on the forum

Ok great yes I’ve done a tutorial on a gain slider, and think that maybe a general rule of thumb is that when the calculation starts becoming multi-line, it’s probably better suited in its own class- would that be a fair statement?

If the calculation needs any kind of past history (like filters and obviously delays will need), it’s an immediate candidate to be put into its own class.

Ok understood! Thanks for all your help.

I agree with the second post, but without going too far in the default code generated by the Projucer :slight_smile: I guess that if some comment and some additional two instructions code about that specific issue are put in the Projucer generated default AudioProcessor code, it might solve the problem once and for all !

Unfortunately I am not so optimistic :wink:

But what I gather from this thread is, that the forum is the wrong communication form to put out educational pieces, because even with this trivial case, where @jules wanted to provide a generic explanation, we have a discussion about the forum.

IMHO there should be another resource (suggested several times), which is a WIKI with pages like this one. It can also be community driven. Unfortunately I don’t enjoy web services at all, otherwise I would have started it already, but I see many people (including myself) here eager to contribute JUCE and DSP related knowledge…

To prevent newbies from making this bug, comments could be added the plugin template process method right where the dsp code goes. Right now if you create a new plugin you have:

// This is the place where you'd normally do the guts of your plugin's
// audio processing...
for (int channel = 0; channel < totalNumInputChannels; ++channel)
{
    float* channelData = buffer.getWritePointer (channel);

    // ..do something to the data...
}

I would write it where you have “…do something to the data”. This would increase the chances of newbies learning about this issue a lot because that’s where they have to add code in order to get the problem.

Or as stated… add an empty struct “ChannelState” to the template with a comment on the fact that seperate states are needed for each channel. Pros can easily remove it.

2 Likes

Third option: create a page about this issue on the webpage and instead of answering the same question over and over, just post a link to the page if it comes up again. That will make sure that searches end up showing the relevant info over time as there’s probably only so many ways to ask the same underlying question and all these will point to the same env page.

Here is a tutorial I’ve made on some options for correcting this issue- I hope it can help prevent this issue from coming up as much in the future!

2 Likes

well, i am an expert on that matter, thats the matter of being a beginner, and i think that what @pixelpacker says is great for beginners.

the default AudioProcessor could have the more efficient solution for the most common case of 2 channels. a beginner would look at the code and understand the trickyness of the multiple channel samples situation and the proposed solution without bothering anyone by asking.

Haha, I love that…

But the more you lose your talent being a beginner, the more the auto generated code you have to remove before you can start will annoy you :wink:
A pointer to an example would work better, but I think I repeat myself…

1 Like

yes, well, a tick box in projucer, when you make a new project,
a choice between “default” project (filled with auto generated stuff)
and “empty” project (containing only minimal code),
would solve that i think.