@@TheAudioProgrammer So for each algorithm we have to make sure that we do not exceed the +1 and -1 values with our output data? What if I wanted to make a plugin that increases the volume, like a slider that increases the volume? If 1 is the maximum output value then my gain factor can be maximum 1 but this doesn't leave the volume as it is already?
Really appreciate this, thank you. One question: At the end of the video, you mentioned you shouldn't do any memory allocation-like things in the audio thread which makes sense, but one thing I haven't seen anywhere is how you would get around this? Does JUCE provide a method in the AudioProcessor class that allows you to execute something of a lower priority in-between the audio callback, similar to how the GUI update works? I know you're supposed to do memory allocation stuff in the constructor if you can, but surely there's a very simple way to get around this that I'm not seeing lol? Thanks again and congratulations for hitting 10K, that's a huge number for such a niche community; wish you the best!
My question would be why would you want to do that on the audio processor? I would simply make a class e.g. DataModel or similar and have it interact with the UI and create data-containers on the fly if you want etc on the message-thread. You can then have a reference to that DataModel object in your processor loop if necessary. And what you can do then is have all code where the processor is accessing that object (for example to use freshly memory-allocated data on that object on the fly) be surrounded with a ScopedTryLock. This way whenever the UI is accessing/setting/changing stuff on your data-structures on the DataModel instance, the processor loop will just ignore that code-block and keep on running without ever blocking. Then maybe in the next loop iteration (when the UI is finished) it will pick up the new data and use it in the processor loop.
Thank you. Just getting started in Juce.. I have no experience in this realm, you're Tut's are making it much more approachable.
Thank you for the kind words!
Super helpful!
Very interesting and useful !! thanks !!!
Awesome! learnt so much from your channel. Can you also share stuff like making and storing presets as a file (xml data) and recall. Thanks
Great video. Always love to see your videos :D
is it true that a sample goes from -1 to 1? what happens when I do channelData[sample] * 4 ?
@@TheAudioProgrammer So for each algorithm we have to make sure that we do not exceed the +1 and -1 values with our output data? What if I wanted to make a plugin that increases the volume, like a slider that increases the volume? If 1 is the maximum output value then my gain factor can be maximum 1 but this doesn't leave the volume as it is already?
just found this channel, really interesting !
But I think I should start from the first video. XD
Hope I'll come here after months.
great tutorial! 👨🏾🎨🍞🐶
Sorry, and what to do if, for example, I need a different block size for my algorithm. Say, I need a second of audio for an algo to work correctly?
Really appreciate this, thank you. One question: At the end of the video, you mentioned you shouldn't do any memory allocation-like things in the audio thread which makes sense, but one thing I haven't seen anywhere is how you would get around this? Does JUCE provide a method in the AudioProcessor class that allows you to execute something of a lower priority in-between the audio callback, similar to how the GUI update works? I know you're supposed to do memory allocation stuff in the constructor if you can, but surely there's a very simple way to get around this that I'm not seeing lol? Thanks again and congratulations for hitting 10K, that's a huge number for such a niche community; wish you the best!
My question would be why would you want to do that on the audio processor? I would simply make a class e.g. DataModel or similar and have it interact with the UI and create data-containers on the fly if you want etc on the message-thread. You can then have a reference to that DataModel object in your processor loop if necessary. And what you can do then is have all code where the processor is accessing that object (for example to use freshly memory-allocated data on that object on the fly) be surrounded with a ScopedTryLock. This way whenever the UI is accessing/setting/changing stuff on your data-structures on the DataModel instance, the processor loop will just ignore that code-block and keep on running without ever blocking. Then maybe in the next loop iteration (when the UI is finished) it will pick up the new data and use it in the processor loop.