KVR Audio

bibamann · Post by **bibamann** » Wed Oct 31, 2012 12:22 am

Hi,
I'm just getting started in developing audio and C++.

So some short introduction:
I'm a professional coder (at least people want to pay me) and doing this for 10 years now, but in other languages than C++ and I'm a musician, too (currently without getting paid for this

). And I like to create some own plugins for my DAW as the winters evenings are cold and boring in Berlin, I quitted my girlfriend 2 weeks ago and I really like getting into this stuff.

So I started downloading the VST3 DSK and the VST3PluginTestHost tool of Steinberg. I'm trying to start with a simple delay as I thought, it's one of the most easiest one plugins to create (just replay the signal you get after some time) and enhance it step by step with panning options, gain, filters and so on... A friend of mine knows C++ quite well and also has some knowledge about dsp and likes to help me, as he finds it interesting, too.

But now I've got some questions I think you can better answer as we try out until it's spring again.

1. How do you debug?
I'm using a mac with xcode to code and the plugintesthost to check, if the 8bit / chiptune sound stills exists or if it already sounds like a delay

. But i have no idea how to use breakpoints and watch, what's really going on. And as I'm sure you all know, watching the values of variables makes a great efford in coding. Is there an other way than writing them into a log file and watch by tail on them?

2. Is there an other documentation of the steinberg sdk out there beside this poor piece of doxygene (or however they created the 5 sites)? Didn't find any...

3. Are there alternatives you would really recommend beside the steinberg sdk?
I've read your (or better: I'm still ready reading) beginners help topics here and I'm very glad you collected all this. But some are 10 years old, some links don't work anymore and I don't want to try out every tool you recommend.
So I want to begin and learn it from low level as I think it's the best way to learn it "really", but I'm not very confident with the steinberg sdk because of the lack of documentation, test tools which offer to debug and examples which are not well written and explained.

Thank you for your answers*.

(*just the nice and helpful ones

)

LemonLime · Post by **LemonLime** » Wed Oct 31, 2012 1:51 am

1. Well, you named one of the possibilities. Writing to a log file is good for certain things like seeing when certain methods/functions are called, printing out values, etc. It may give you a better idea of how a host handles the plug-in, which can be helpful. Alternatively you could just use the standard output (I use clog) and of course it will just get dumped to Console as the plug-in is running so you can see it in real time.

You can also attach a custom executable to your Xcode project (your test host or other host program for example) that will launch when the debugger is run.

But might I suggest building your plug-in as a command-line program first to test out all the audio processing code. This will enable you to more easily debug using breakpoints, and once this is working correctly it's a matter of placing the appropriate bits of code into the plug-in interface.

2. As far as any official documentation, no. Not that I'm aware of. Same with VST 2.x SDK, it's a little sparse and far from being complete.

3. If you're on Mac and using Xcode, Audio Units. Apple removed the AU template from Xcode 4, but you can still set one up and add it to Xcode, and the documentation on AU and related frameworks are much better than Steinberg's VST.

mystran · Post by **mystran** » Wed Oct 31, 2012 2:54 am

Debugging tip for anything that looks even superficially like a signal: just output it as audio. Don't feed it to speakers, but you can record it and examine it in a wave-editor, or even feed it to a plugin oscilloscope. It's often easier to just look at a wave-form (even if it's not proper audio) than to try to figure out what the 44100 (or more) log-entries per second actually mean.

AdmiralQuality · Post by **AdmiralQuality** » Wed Oct 31, 2012 5:11 am

Recommend you do yourself (and your customers) a favor and use VST 2.4.

Ichad.c · Post by **Ichad.c** » Wed Oct 31, 2012 8:05 am

mystran wrote: Don't feed it to speakers

I learn't that the hard way

camsr · Post by **camsr** » Wed Oct 31, 2012 8:50 am

mystran wrote:Debugging tip for anything that looks even superficially like a signal: just output it as audio. Don't feed it to speakers, but you can record it and examine it in a wave-editor, or even feed it to a plugin oscilloscope. It's often easier to just look at a wave-form (even if it's not proper audio) than to try to figure out what the 44100 (or more) log-entries per second actually mean.

I will add to this.

Always test the host buffer and change it's size while the plugin is running. Maybe you had some great idea for data management that will not work correctly for AUDIO.

Almost all important debugging is done either with a wave recording of the plugin, or in a specialized host/plugin-based host (to track function calls). Eventually you will find the need for both methods as you utilize more of the SDK.

If you do not know exactly what it does, don't use it. This also applies to host implementation of specific SDK features. Most hosts will not have a call to some esoteric functions of the SDK, such as getSpeakerArrangement or whatever. This is in reference to VST 2.4, which is compatible with almost everything.

On that note, VST3 has not been gracefully accepted as the desired progression of VST2.4. Only a handful of host programs support it. Almost every DAW on the market uses 2.4.

Make sure to respect the audio thread. No one will want to use your plugin if the audio thread is idling. If you must multithread, the audio thread is real time priority.

bibamann · Post by **bibamann** » Thu Nov 08, 2012 5:34 am

Hi guys,
thanks for the answers. For the beginning I writing stuff into a logfile and tailing it, which is working ok as I coded it the way that a output is only written if a var has changed. So I can use it in progress() and loops as well without getting spammed on it.

But I'm currently getting stuck in some kind of evil sorcery I don't understand. I still use the VST 3 SDK (but I will change to 2.4 or AU, I swear

. I'm just unsure to which one - do Logic and ProTools support VST on Mac?) and took from there the adelay example to enhance.

The code from there uses a float** pointer for buffer (channel, sampleIndex) to store the samples which are written back to the outputStream.

from the .h

Code: Select all

protected:
	float** buffer;
	int32 bufferPos;

from the .cpp

Code: Select all

tresult PLUGIN_API ADelayProcessor::process (ProcessData& data)
{
        ...

        int32 delayInSamples = 88200; // 2 seconds at 44100
        
        writeDelayed(data, numChannels, delayInSamples, 5);
        
        bufferPos += data.numSamples;
        
        while (delayInSamples && bufferPos >= delayInSamples)
        {
            bufferPos -= delayInSamples;
        }
	
       ...
}


void ADelayProcessor::writeDelayed(ProcessData &data, int32 numChannels, int32 delayInSamples, int32 gain)
{
    for (int32 channelIndex = 0; channelIndex < numChannels; channelIndex++)
    {
        float *inputChannel = data.inputs[0].channelBuffers32[channelIndex];
        float *outputChannel = data.outputs[0].channelBuffers32[channelIndex];
        
        int32 tempBufferPos = bufferPos;
              
        for (int32 sampleIndex = 0; sampleIndex < data.numSamples; sampleIndex++)
        {            
            float inputSample = inputChannel[sampleIndex];
            
            outputChannel[sampleIndex] = buffer[channelIndex][tempBufferPos];
            
            buffer[channelIndex][tempBufferPos] = inputSample;
            
            tempBufferPos++;
            
            if (tempBufferPos >= delayInSamples)
            {
                tempBufferPos = 0;
            }
           
        }
    }
}

It works fine along delayInSamples <= 45500 (somewhere there, at 45500 strange noises start, at 46000 the program crashes - maybe it's beginning at 44100 and I just don't hear the distortions there ).

The crash message says:

Code: Select all

Crashed Thread:  8  Baios Processing Thread

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000108fe9000

VM Regions Near 0x108fe9000:
    MALLOC_LARGE           0000000108fbd000-0000000108fe9000 [  176K] rw-/rwx SM=PRV  
--> 
    VM_ALLOCATE            0000000108ffc000-0000000108ffd000 [    4K] rw-/rwx SM=PRV

The lines of code which cause the crash are:

Code: Select all

outputChannel[sampleIndex] = buffer[channelIndex][tempBufferPos];
buffer[channelIndex][tempBufferPos] = inputSample;

And that doesn't make any sense to me.
I mean I'm not really into pointers and far away to be really comfortable pointers on pointers as I'm learning C++ with this stuff, too. But as far as I understand - shouldn't the value of tempBufferPos that is passed to the buffer don't care what is in it as long it's smaller than int32? And why does it getting instable at the value nearby the sampleRate? I can't see any relations between them.

What I only see is, that buffer[channelIndex][tempBufferPos]; will point at the beginning into nowhere. But as long it works till 44100 - why not greater?

I would be glad if you can help me.

arakula · Post by **arakula** » Thu Nov 08, 2012 9:27 am

Who allocated buffer, and in which size?

bibamann · Post by **bibamann** » Thu Nov 08, 2012 5:58 pm

Well, I found it. They allocated it just a little bit over samples size and it was hidden in a block of spaghetti code (really great written and documented example :-/).

It works now as I increased it.

3 beginners questions