Seeking Assistance for Creating a Drum VST with JUCE

[DL1]

Hello JUCE Community,

I hope everyone is doing well. I am in the process of creating a drum VST using the JUCE library and would like to seek guidance from the community to ensure I am on the right track.

So far, I have:

1. Configured the plugin characteristics, including Plugin MIDI input, Plugin MIDI output, and MIDI Effect Plugin.
2. Set the plugin format to VST3.
3. Successfully compiled the project.

Now, I am looking for guidance on the next steps and best practices when developing a drum VST. Any tips on project structure, MIDI event handling, or recommendations for additional libraries would be greatly appreciated.

If anyone in the community has worked on similar projects or has experience with drum plugins, I would be very grateful for any advice or direction.

Thank you!

As I couldn’t take a photo of the PluginProcessor.cpp, I decided to send it in writing. /*

This file contains the basic framework code for a JUCE plugin processor.

==============================================================================
*/

#include “PluginProcessor.h”
#include “PluginEditor.h”

//==============================================================================
DLBacinAudioProcessor::DLBacinAudioProcessor()
#ifndef JucePlugin_PreferredChannelConfigurations
: AudioProcessor (BusesProperties()
#if ! JucePlugin_IsMidiEffect
#if ! JucePlugin_IsSynth
.withInput (“Input”, juce::AudioChannelSet::stereo(), true)
#endif
.withOutput (“Output”, juce::AudioChannelSet::stereo(), true)
#endif
)
#endif
{
}

DLBacinAudioProcessor::~DLBacinAudioProcessor()
{
}

//==============================================================================
const juce::String DLBacinAudioProcessor::getName() const
{
return JucePlugin_Name;
}

bool DLBacinAudioProcessor::acceptsMidi() const
{
#if JucePlugin_WantsMidiInput
return true;
#else
return false;
#endif
}

bool DLBacinAudioProcessor::producesMidi() const
{
#if JucePlugin_ProducesMidiOutput
return true;
#else
return false;
#endif
}

bool DLBacinAudioProcessor::isMidiEffect() const
{
#if JucePlugin_IsMidiEffect
return true;
#else
return false;
#endif
}

double DLBacinAudioProcessor::getTailLengthSeconds() const
{
return 0.0;
}

int DLBacinAudioProcessor::getNumPrograms()
{
return 1; // NB: some hosts don’t cope very well if you tell them there are 0 programs,
// so this should be at least 1, even if you’re not really implementing programs.
}

int DLBacinAudioProcessor::getCurrentProgram()
{
return 0;
}

void DLBacinAudioProcessor::setCurrentProgram (int index)
{
}

const juce::String DLBacinAudioProcessor::getProgramName (int index)
{
return {};
}

void DLBacinAudioProcessor::changeProgramName (int index, const juce::String& newName)
{
}

//==============================================================================
void DLBacinAudioProcessor::prepareToPlay (double sampleRate, int samplesPerBlock)
{
// Use this method as the place to do any pre-playback
// initialisation that you need..
}

void DLBacinAudioProcessor::releaseResources()
{
// When playback stops, you can use this as an opportunity to free up any
// spare memory, etc.
}

#ifndef JucePlugin_PreferredChannelConfigurations
bool DLBacinAudioProcessor::isBusesLayoutSupported (const BusesLayout& layouts) const
{
#if JucePlugin_IsMidiEffect
juce::ignoreUnused (layouts);
return true;
#else
// This is the place where you check if the layout is supported.
// In this template code we only support mono or stereo.
// Some plugin hosts, such as certain GarageBand versions, will only
// load plugins that support stereo bus layouts.
if (layouts.getMainOutputChannelSet() != juce::AudioChannelSet::mono()
&& layouts.getMainOutputChannelSet() != juce::AudioChannelSet::stereo())
return false;

// This checks if the input layout matches the output layout

#if ! JucePlugin_IsSynth
if (layouts.getMainOutputChannelSet() != layouts.getMainInputChannelSet())
return false;
#endif

return true;

#endif
}
#endif

void DLBacinAudioProcessor::processBlock (juce::AudioBuffer& buffer, juce::MidiBuffer& midiMessages)
{
juce::ScopedNoDenormals noDenormals;
auto totalNumInputChannels = getTotalNumInputChannels();
auto totalNumOutputChannels = getTotalNumOutputChannels();

// In case we have more outputs than inputs, this code clears any output
// channels that didn't contain input data, (because these aren't
// guaranteed to be empty - they may contain garbage).
// This is here to avoid people getting screaming feedback
// when they first compile a plugin, but obviously you don't need to keep
// this code if your algorithm always overwrites all the output channels.
for (auto i = totalNumInputChannels; i < totalNumOutputChannels; ++i)
    buffer.clear (i, 0, buffer.getNumSamples());

// This is the place where you'd normally do the guts of your plugin's
// audio processing...
// Make sure to reset the state if your inner loop is processing
// the samples and the outer loop is handling the channels.
// Alternatively, you can process the samples with the channels
// interleaved by keeping the same state.
for (int channel = 0; channel < totalNumInputChannels; ++channel)
{
    auto* channelData = buffer.getWritePointer (channel);

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

}

//==============================================================================
bool DLBacinAudioProcessor::hasEditor() const
{
return true; // (change this to false if you choose to not supply an editor)
}

juce::AudioProcessorEditor* DLBacinAudioProcessor::createEditor()
{
return new DLBacinAudioProcessorEditor (*this);
}

//==============================================================================
void DLBacinAudioProcessor::getStateInformation (juce::MemoryBlock& destData)
{
// You should use this method to store your parameters in the memory block.
// You could do that either as raw data, or use the XML or ValueTree classes
// as intermediaries to make it easy to save and load complex data.
}

void DLBacinAudioProcessor::setStateInformation (const void* data, int sizeInBytes)
{
// You should use this method to restore your parameters from this memory block,
// whose contents will have been created by the getStateInformation() call.
}

//==============================================================================
// This creates new instances of the plugin..
juce::AudioProcessor* JUCE_CALLTYPE createPluginFilter()
{
return new DLBacinAudioProcessor();
}

[Mrugalla]

MIDI event handling basically works like this:
You loop over all MIDI events of the MIDI buffer in processBlock and when something happens that matters in your plugin (like a noteOn event) then you do stuff.

for(const auto it: midiBuffer)
{
    const auto msg = it.getMessage();
    if(msg.isNoteOn())
        ...
}

every MIDI message has a timestamp which describe where it is in terms of sample indexes of the audio sample buffer. so say your MIDI buffer only has a noteOff message at sample index 48, that would mean you let your audio processes run to 48, then update them with the noteOff message and then let them run until numSamples. beware of edgecases like empty MIDI buffers or multiple significant events on a single sample index.

Then about the audio processes. I’d keep it simple to begin with and just let it monophonically turn on and off a sample. you can add a sample via BinaryData with the projucer to skip writing the logic for dynamically importing and loading samples from memory right away.

Polyphony can be implemented in different ways. One approach would be to give each note number its own voice. But that would mean you have to run 128 voices all the time. Another approach is to limit the number of available voices but distribute the incoming midi notes to the ones that are currently free, because the last sound has already stopped playing. In that case you’d have to decide how to do that. I personally like to just use a ring buffer, which gives note priority to the newest notes.

Also consider voice steal mechanisms so that there are no discontinuities when playing the same sample twice really fast

[Qfactor]

You probably want to use the tracktion engine to handle the samples. If it’s your first plugin you will find this task very challenging otherwise (some problematic bits: streaming from disk, thread safety of memory allocation).

[DL1]

yeah man, this makes sense, there is another question i want to do also, is how to add a keyboard in the screen when i start building i wnat this.

for this

[Mrugalla]

https://docs.juce.com/master/classKeyboardComponentBase.html

[DL1]

i think i will give up, i didnt get nothing how to make this work

[baramgb]

In my opinion, the hardest part is setting up your development environment. You have managed this part. It’s not easy, and it shows that you can handle such tasks. The next step is to continue. In your case, I would first create the GUI. Make sketches with pen and paper. Learn how the juce::Component class works. There are tutorials on the website. Once your GUI looks cool, you can add functionality to it.

Keep on working, it’s not that difficult.

[stephenk]

@DL1

i think i will give up, i didnt get nothing how to make this work

You really need to do ALL the tutorials on the website to gain any understanding of how to proceed. There are several that have keyboard components in them like the one you want.

[Mrugalla]

don’t give up! just take the smallest imaginable achievement from your todo list and achieve it, for motivation

[DL1]

thanks man