New Beginners' Tutorials

Getting Started
21

I don’t think the Juce Plugin Host can reproduce host Transport behavior used in the final LFO-example. At least I could not find it.

EDIT: Sorry, this was already mentioned.

22

I haven’t read the tutorial, but this is an invalid simplification. You can perfectly use auto in headers.
You can always use auto, if the compiler can deduce the type from the initial assignment. I think auto as return type also works.

23

Please don’t make quotes from other’s so it looks like they are my words. I can make it more obvious I’m quoting the tutorial, but it’s marked as a quote so it should be obvious I’m not saying the section you’re commenting.

Anyway, if auto can be used in header’s then my remark is even more valid. The code mentioned is passing the buffer on to other functions so it’s implementing functionality and therefore is not a matter of declaration. I believe this section in the tutorial needs to get a better wording since processBlock is one of the most fundamental aspects of the audio processing.

24

What does it mean?
The only hit I get if searching The Internet (with DuckduckGo) is this page… :upside_down_face:

25

Apologies, that was just prefilled by the browser. It wasn’t my intention to throw shade at you. I corrected it above.

26

Great! :smiley:

27

Hi Guys, Thanks, oortone, for the feedback :slight_smile: I’ve corrected the typos and am considering your layout suggestions.

As for: auto myBlock = juce::dsp::AudioBlock<float>(buffer); This seems to be the right way to do it, but what is the actual reason not to declare myBlock in PluginProcessor.h? Is it to do with memory allocation?

Please remember that I’m only trying to explain to beginners why we don’t follow the basic C++ approach of declaring myBlock in PluginProcessor.h

cheers, Ollie

28
  1. you don’t need to worry about dsp::AudioBlock. It was invented so you can create and throw them away as you like it. It is a view on sample data, it doesn’t ever allocate.
  2. the reason not to use dsp::AudioBlock in the header (using it synonym as member variable, technically it doesn’t matter if something appears in a header or cpp file):
    since it is just a view and not owning the sample data, you would need to ensure that the underlying sample data is still valid.
    So it is easier and safer to create a fresh throwaway dsp::AudioBlock each time.

N.B. there is one exception, if you create an dsp::AudioBlock with a juce::HeapBlock, it will allocate in the HeapBlock.

29

Hi daniel,

How’s this wording?: “We use the auto variable type which lets the computer decide what data type we need. By declaring here, the computer can create a new myBlock each time it receives a block of audio from the Host.”

cheers, Ollie

30

The technical term for auto is type deduction, so I would stick with that:
“Using auto as type lets the compiler deduce the actual type by whatever is assigned to it. This means you cannot create a variable using auto without assigning anything to it.”

31

Thnx :slight_smile:

32

Here it is Filter Plugin GUI – JUCE Step by step
As usual, feedback is greatly appreciated - anything from typos, to broken links to fatal errors :slight_smile:

1 Like
33

Hello there, I am trying this out with Xcode, and I get the following error when I try and build

No viable conversion from returned value of type ‘std::atomic *’ to function return type ‘std::atomic<float *>’

std::atomic<float*> AudioProcessorValueTreeState::getRawParameterValue (StringRef paramID) const noexcept
{
    if (auto* p = getParameterAdapter (paramID))
        return &p->getRawDenormalisedValue();

    return nullptr;
}
34

Seems that you accidentally edited some juce code…? It should read

std::atomic<float>* AudioProcessorValueTreeState::getRawParameterValue (StringRef paramID) const noexcept

The difference is std::atomic<float*> vs std::atomic<float>*

35

Many thanks, that work, a stupid mistake:)

Appreciate you taking the time to help!

Regards.

36

hi Ollie,

I’m enjoying your tutorial!

It looks like there’s a typo on step 2d:

myFilter.setType(juce::dsp::StateVariableTPTFilter::bandpass);

should be:

myFilter.setType(juce::dsp::StateVariableTPTFilterType::bandpass);

37

Hi jumpseven,
Oh wow! You’re absolutely correct. Fixed now, sorry for any confusion.
You’re the first person to notice this; so perhaps most people don’t get this far? Thanks for your persistence and help :slight_smile:

38

hi Ollie,

I just finished your tutorial. I wanted to thank you for creating it and I was really impressed how you organized everything. Much appreciated!

39

You’re welcome :slight_smile:

40

Thank you so much for this!
Im having great time following you tutorial!