Soft synth idea - am I crazy?

[hellfire]

What do you mean by "proper tuning" please?

Let's assume you have two oscillators and each is able to generate some frequency.
But you can only specify a single base frequency by pressing a note on your keyboard.
So each oscillator must have some kind of detuning parameter to specify it's actual frequency.

If your oscis produce sines at the frequencies m and c, the modulated output will contain the frequencies m-c and m+c.
So you have to pick m and c carefully to make this sound musically useful, especially if you're using waveform with rich harmonics like saw or pulse.

[Raizor]

What do you mean by "proper tuning" please?

Let's assume you have two oscillators and each is able to generate some frequency.
But you can only specify a single base frequency by pressing a note on your keyboard.
So each oscillator must have some kind of detuning parameter to specify it's actual frequency.

If your oscis produce sines at the frequencies m and c, the modulated output will contain the frequencies m-c and m+c.
So you have to pick m and c carefully to make this sound musically useful, especially if you're using waveform with rich harmonics like saw or pulse.

Ah, that makes sense now. Thanks Hellfire.

[Raizor]

On the subject of GUIs, what do these big companies use to make their nice interfaces? I mean in terms of graphics libraries, I assume it's not all done by hand. I've never done any GUI work in C++ before, save for a few Win32 dialogs.

[ferris]

I'd actually be willing to bet it IS done by hand; I think each of the big guys use an internal library maintained in house.

GUI systems are a bitch to make mainly because they're tedious (simply a lot they need to do to be properly functional) but their actual design is pretty straightforward, given you use a typical event-driven system (if this event happens in this widget's area, call widget's event handler where widget gets focused and captures input etc etc).

[Raizor]

I'd actually be willing to bet it IS done by hand; I think each of the big guys use an internal library maintained in house.

GUI systems are a bitch to make mainly because they're tedious (simply a lot they need to do to be properly functional) but their actual design is pretty straightforward, given you use a typical event-driven system (if this event happens in this widget's area, call widget's event handler where widget gets focused and captures input etc etc).

Ouch. Sounds like a real time sink.

[Raizor]

I'm now putting together my modulation matrix design, which I've based on the modulation matrix in Z3TA (I love Z3TA).

I just wanted to check that my idea of how modulations should affect parameters are along the right lines. I couldn't find any relevant info, so I've made a lot of assumptions, which could well be very wrong.

When my LFO is modulating the frequency of an oscillator, I use the LFO value to alter the input frequency of the oscillator. My LFO produces values in the -1 to +1 range and I use this value to alter frequency like so:

Freq = Freq + (Freq * LFO_VALUE)

As the LFO value is in the range -1 to +1, this seems to work quite well. 

If I'm using a depth/strength setting on the LFO, this becomes:

Freq = Freq + (Freq * LFO_VALUE * DEPTH)

Is this a sensible way to handle things?

I haven't yet got envelopes modulating anything except oscillator volume/amplitude, but I'd like them to be able to modulate pretty much anything an LFO can. To this effect, I was thinking of approaching this in a similar way to the LFO method above, and having ENV_VALUE replace LFO_VALUE in the above equation. Would that also be sensible?

I also plan to have both unipolar (0 to +1) as well as bipolar (-1 to +1) modes for the modulators.

Many thanks,

Raizor

[ferris]

Seems like you're on the right track. The only important things I've really noticed when working with LFO's in synths is that 1. You're adding the lfo's value to the preexisting parameter value (as you're doing here; even though the range is modified by the preexisting value), and 2. If you at all have high and low bounds for the parameter, these are enforced AFTER the lfo has been applied.

[Raizor]

Thanks Ferris

[hellfire]

Freq = Freq + (Freq * LFO_VALUE)

I don't think this will work really well.
If your lfo is oscillating between -0.5..+0.5 your frequency will change between 0.5..1.5 - which is one octave down but only 7 semitones up...

[Raizor]

Freq = Freq + (Freq * LFO_VALUE)

I don't think this will work really well.
If your lfo is oscillating between -0.5..+0.5 your frequency will change between 0.5..1.5 - which is one octave down but only 7 semitones up...

Hmm, any suggestions on a better way Hellfire?

[hellfire]

Simply apply the modulation on the "note":
frequency = note2freq( note + tune + modulations );

[Raizor]

I'll give that a try, thanks Hellfire.

[Raizor]

I've decided to do everything in C++ now.

Initially I had the synth in a C# DLL wrapped up in a C# VST and planned to rewrite the synth in C++ for the replayer. This was crazy...

I then decided to write the core synth in C++ and have it referenced as a lib by a managed C++ DLL that the C# VST referenced. This was also crazy...

Now I've bitten the bullet and am using VSTGUI from the VST SDK (2.4 atm) to create a single DLL VST. The synth core is still in a C++ lib in a separate project. It's going to be a bit more fiddly this way, but cleaner. Setting up the VST SDK project was a bit of a nightmare. Thankfully, after a bit of hunting I came across this nice Vibrato plugin, which I've used as a template. Bear in mind that this plugin is an Effect plugin, rather than an Instrument plugin. The VST SDK does come with a Synth plugin template that you can use to see how an Instrument plugin is put together. I studied this and modified the vibrato template to come up with a working solution. You can find the Synth sample in the SDK: vstsdk2.4\public.sdk\samples\vst2.x\vstxsynth\

You need to register on the Steinberg site to download the SDK. However, it's included (v2.4) in the Vibrato plugin download link above.

The default stuff in VSTGUI looks a bit crap. I found something that looks very promising called KnobMan (hehe). This looks really useful for making nice controls for your synth. There are some great sample knobs on the site too.

Once I've got something halfway decent up and running, I'll post my project here as it might be useful for others getting started with this stuff.

I'm using v2.4 of the VST SDK as opposed to v3.x as it sounds like there are a number of changes in architecture, that while very neat make compatibility with old VST hosts a problem. I may have the wrong end of the stick here, but that's the impression I've got from reading so far...

[Kirl]

Excellent, I love this thread as you do a great job explaining your decisions throughout the process. I enjoyed following your progress and it should be a really usefull source of info if I'll ever venture this far into it.

Good luck!


Meanwhile I've rephrased my own wild plans from "writing a simple synth" to a somewhat more realistic "fiddling with pitch and distortions and such"... 

[Raizor]

Thanks Kirl

Meanwhile I've rephrased my own wild plans from "writing a simple synth" to a somewhat more realistic "fiddling with pitch and distortions and such"... 

That sounds like a synth to me, just need to fiddle with the pitch according to note input What language are you using?

[Raizor]

After some time playing with VstGUI, I've canned that idea and taken a few steps back. Making nice, usable GUI controls with it proved to be quite a pain, so I've gone back to using a C# front-end for the GUI of the VST plugin with a simple managed C++ layer that lets the GUI talk to the underlying synth (which still lives in an unmanaged C/C++ lib).

A quck question for you C/C++ gurus, if you don't mind. I started converting the core synth from C++ to C with the thinking that it would likely produce smaller code that I would have more control over. The C++ version uses some template classes, which I feel (from reading) may introduce some bloat in terms of eventual filesize. Is this likely to be the case? I also figured that with things in C, it would be easier to optimize at a later date if I choose to convert part of all of the underlying code to ASM. Coding it in C is certainly slower in terms of development, so if the advantages to this approach are minimal (or non-existent), I'll stick with C++.

I've also given up on the idea of making the synth stack based and have changed to having a fixed set of components per patch (which can be turned on or off). Seeing as this is my first attempt at a soft synth, this should make the project a lot less complex in terms of development and keep the interface simple for any musicians.

In terms of new functionality, there hasn't been a lot of progress due to all the chopping and changing. I've got some ideas for features that should make the synth unique though. I'm going to add the ability to use samples from GM.DLS, which should provide some half decent percussion sounds that can be jazzed up by the synth.

That's about it for now

[hellfire]

I started converting the core synth from C++ to C with the thinking that it would likely produce smaller code that I would have more control over. The C++ version uses some template classes, which I feel (from reading) may introduce some bloat in terms of eventual filesize.

Every instance of a new template type leads to duplicated code.
It doesn't make sense to avoid all C++ features, though.
Actually you can avoid most templating by using a clever class hierarchy.
Eg. you can use a common interface for all generators and filters.
Recreating such structures in plain C is pretty annoying.

I'm going to add the ability to use samples from GM.DLS, which should provide some half decent percussion sounds that can be jazzed up by the synth.

You can also use the loopable part of each sample as an oscilator waveform.

[Raizor]

Thanks for the input Hellfire, much appreciated.

I've been deep in the land of annoying structure recreation, so I probably will go with a mix of C++ and C. All my components and parameters contain an instance of a base parameter or component structure, which should keep things a little smaller. I've written out all the template stuff too, so most of the painful refactoring is out of the way for now.

The loopable gm.dls sample portion as a waveform sounds like a great idea. I still need to dig into the gm.dls format to get up to speed. Do you know if the loopable sections are marked in the file? Hopefully I can parse that information if so.

Thanks again.

[hellfire]

Do you know if the loopable sections are marked in the file?

Sure. Parsing dls is very simple:

Code: [Select]

for each sample
  find "fmt "
  find "wsmp"
   - 5th dword tells if the instrument has looping
   - 8th dword tells how many samples the loop range has (from the end of the sample data)
  find "data"
   - sample data starts here


[ferris]

I also have a question about vsti's. How are non-automatable param's set up, and how does midi-interaction work? What sort of methods do you implement for these? (sure this stuff is probably easy to find but it's even easier to ask )