This was brilliant and so well taught! I'd love a video about sample-by-sample vs block processing in regards to audio DSP. It's something rarely mentioned in text and videos and it's so important from an implementation and optimization perspective.
Thank you, Amber! I completely agree that block processing is an important topic and I am planning to cover it in my videos, especially the advantage of SIMD instructions :)
Another really great tutorial, thank you so much! I'm an audio programmer in game development and I pretty much fell in to the role from engine programming - as such don't have a solid background in low level audio. I'm finding your videos really easy to follow and understand. One note - it's probably better to add files to your solution (i.e. WaveTableSynth.h/.cpp) from the Projucer application; the .vcproj files get regenerated whenever you save & open the solution from Projucer, and any files that aren't registered in the file explorer don't get included.
Wow, thanks for the feedback and the great comment! My newest video with JUCE also has that flaw, but from now on, I will import the files in the Projucer, thanks :)
I really love your tutorial! I love the attention to detail. Can't wait for the voice allocation version... ADSR envelopes etc... I have a question about the MIDI event sample. At 48k sample rate each sample is 20.8us apart. A 128 sample buffer is 2.6ms long. At typical MIDI transmit rates a 3 byte MIDI message takes ~1ms. So why not just process all the MIDI events at the beginning before processing the audio data. Are humans capable of detecting anything faster than ~15ms (even in the best of situations)? I'm not trying to be snarky! I'm just curious about the added complexity of the inter-buffer offsets for MIDI events.
Hi legosteveb, thanks for the question! What you wrote is completely sound to me; if we have a 128 samples long buffer at 48 kHz, it wouldn't make much difference if we processed the messages at the beginning of the buffer. The problem is that... we don't know what the block length or sample rate the user will set :) At 22.05 kHz with 1024 block length (not uncommon), 1 block lasts for 46 ms: sufficiently long for a human listener to notice that the parameter changes don't happen continuously. So we typically write a more generic code to make sure we are on the safe side. Thanks again for asking!
I created both classes as "components" in juce. Turns out that the constructor will be "deleted" by the JUCE_LEAK_DETECTOR so, had to reimplemented again now as single files.
![Wavetable Synthesis in Rust?? Rust Basics Tutorial [Synth #004]](http://i.ytimg.com/vi/v0Qp7eWVyes/mqdefault.jpg)
![Wavetable Synthesis in Rust?? Rust Basics Tutorial [Synth #004]](/img/tr.png)
![Wavetable Synthesis Algorithm Explained [Synth #001]](http://i.ytimg.com/vi/ssIJ8kFG7qs/mqdefault.jpg)
![Chino Pacas - Modo Capone (with Drake & Fuerza Regida) [Video Oficial]](http://i.ytimg.com/vi/zjv8TQ0gBkg/mqdefault.jpg)
Have I helped you with this video? If yes, please, consider buying me a ☕ coffee at www.buymeacoffee.com/janwilczek
Thanks! 🙂
This was brilliant and so well taught! I'd love a video about sample-by-sample vs block processing in regards to audio DSP. It's something rarely mentioned in text and videos and it's so important from an implementation and optimization perspective.
Thank you, Amber! I completely agree that block processing is an important topic and I am planning to cover it in my videos, especially the advantage of SIMD instructions :)
This video is still the bible to me as someone just starting out, thank you so much for this! I've been coming back to it on and off for a while now
Aww, thanks!
Another really great tutorial, thank you so much! I'm an audio programmer in game development and I pretty much fell in to the role from engine programming - as such don't have a solid background in low level audio. I'm finding your videos really easy to follow and understand.
One note - it's probably better to add files to your solution (i.e. WaveTableSynth.h/.cpp) from the Projucer application; the .vcproj files get regenerated whenever you save & open the solution from Projucer, and any files that aren't registered in the file explorer don't get included.
Wow, thanks for the feedback and the great comment! My newest video with JUCE also has that flaw, but from now on, I will import the files in the Projucer, thanks :)
this is awesome!! made my own. also added a adsr for each osc and different waveshapes. thank you!
Damn, seems like i found a great source for learning some dsp etc. Big Ups man! Keep up the good work. Pozdro ;D
Thanks a lot for the feedback! Is there anything in particular that interests you from the domain of DSP? Również pozdrawiam ;]
Great tutorial! Thank you for your job
Thank you very much for the feedback!
I really love your tutorial! I love the attention to detail. Can't wait for the voice allocation version... ADSR envelopes etc...
I have a question about the MIDI event sample. At 48k sample rate each sample is 20.8us apart. A 128 sample buffer is 2.6ms long. At typical MIDI transmit rates a 3 byte MIDI message takes ~1ms. So why not just process all the MIDI events at the beginning before processing the audio data. Are humans capable of detecting anything faster than ~15ms (even in the best of situations)? I'm not trying to be snarky! I'm just curious about the added complexity of the inter-buffer offsets for MIDI events.
Hi legosteveb, thanks for the question!
What you wrote is completely sound to me; if we have a 128 samples long buffer at 48 kHz, it wouldn't make much difference if we processed the messages at the beginning of the buffer. The problem is that... we don't know what the block length or sample rate the user will set :) At 22.05 kHz with 1024 block length (not uncommon), 1 block lasts for 46 ms: sufficiently long for a human listener to notice that the parameter changes don't happen continuously. So we typically write a more generic code to make sure we are on the safe side.
Thanks again for asking!
@@WolfSoundAudio Thanks for the reply. It makes total sense for longer buffers and slower sample rates.
Great, thank you too! :)
wow, very informativ...helps me a lot
Hello , thanks. A technical question please: does atanf(), sinf() specific to c++ microsoft (do not exist in linux for example)?
Thanks for the question. These functions are part of the C++ standard so they are available on all C++ compilers.
i see what's happening. the ide tells you the type behind the colon. how did you get it to do that? it's a very useful feature
THANKYOU SO MUCH BRO!
Always a pleasure :)
thanks!! very good tutroal video
How can I choose CLion from the projucer menu?
midiMessages is not defined. i assume it's meant to be one of the funtion parameters
made it! sounds awful but I cannot be happier for first synth! thank you
I created both classes as "components" in juce. Turns out that the constructor will be "deleted" by the JUCE_LEAK_DETECTOR so, had to reimplemented again now as single files.
const auto midiEvent:MidiMessage = midiMessage.getMessage();
annot deduce 'auto' type (initializer required)
i simply removed the midievent: problem solved.
Woooow
im having such a hard time figuring out how to open audio host plugin :(
I noticed visual studio showing actual type of auto variables. How is it possible?
It works by default on my side... Are you using Visual Studio 2019?
I am currently using visual studio 2022. I've also used visual studio 2019 in the past and this feature wasn't there either by default.
@@mohitraj5615 alt+F1
If possible improve your Keyboard Typing sound - too loud and too much bass.
Doesnt build.