The dsp-G1 Analog Modeling Synth source code

The documentation for the dsp-Gplug/G1 synth is now available here:

If it’s ok by you Oliver?


Pity that it isn’t released under an open-source license.

You can use it anyway you like except make your own profit on the exact code.

I don’t mind if anyone rip parts of the code for their own ideas but you can’t sell it as is.

The schematic design is free of use.

There’s some progress here… What about using a proper open-source licence (or at least creative commons with a - nc - clause)?

Having a quick look at the code, here’s how you could improve your synth:

  • You should be careful with the terminology: Your DCOs are not DCOs at all, they are digital oscillators.
  • You should be careful with the terminology: There’s no “analog modelling” going on. Your oscillators do not emulate the kinky waveforms and aliasing-free behaviour of analog oscillators. Your filter does not emulate the non-linearity and the correct F/Q coupling of an analog filter.
  • You should really, really consider using a proper scale for the filter cutoff control. That’s the #1 thing you should fix. Please. People used to playing real synths will find it weird if your filter has a linear cutoff control. HackMe Rockit had the same issue and I’m pretty sure this is the #1 reason people got rid of it after having built the kit.
  • Your filter code is using superfluous operations. a = a * (1 - x) + b * x can be rewritten as a += x *(b - a). That’s exactly how an OTA-integrator filter works by the way - using the differential input of the OTA to compute the difference, the current-controlled gain of the OTA to do the multiplication, and the cap to do the sum.
  • When we say a filter is a “24dB” filter, we don’t mean that it has a gain of -24dB at cutoff, but we mean that its slope is 24dB per octave. Your filter has 8 stages, hence it is an 8-pole / 48dB.
  • An efficient implementation of MIDI CC control, is to have a table mapping a CC number into the offset of a struct containing the parameters. switch(CC) is not a very good idea. The result is probably more compact than a big blob of code with switch/case.
  • Code without an IDE project or makefile is useless. There are function calls (uart0Init, sct_fsm_init that are not defined in the file).
  • If division is software-emulated (I think it is), the code of the division/modulo routine is going to take much more space than having a 128 note frequency table with a direct lookup.

It’s good to select a proper license so your intentions are clear. CC is great in case you want to restrict commercial use, but the GPL could be fine for that as well.

You too know that the terminology DCO here is ok vs. using VCO which it is not.

Analog modeling here stands for the subtractive synth structure modeled in code.

A DCO is an analog integrator discharged by a reset pulse coming from a digital timer. It’s not even obscure knowledge.

Calling your synth a “subtractive synth” is more informative and honest. Trying to fool and confuse people doesn’t work in the long term.

That’s not what I ment.

Lots of synths name their digital oscillators as DCO’s even though they are NCO’s.

What do you call yours?
OSC? Its not an oscillator so what should you call it?

“Lots of synths name their digital oscillators as DCO’s”?

Which ones?

I call them “digital oscillators”.

Quote from Wikipedia:
"“The term “digitally controlled oscillator” has been used to describe the combination of a voltage-controlled oscillator driven by a control signal from a digital-to-analog converter, and is also sometimes used to describe numerically controlled oscillators.”"

There is no such thing as a Digital oscillator.
That would be a squarewave osc?

As soon as you go through a DAC it’s an algorithm?

See this Wiki artilce under Confusion over terminology

I agree that “digital oscillator” and “analogue oscillator” are far better and less confusing terms. In fact, I think we should put all oscillators in to three categories: Non Aliasing Oscillators, Anti Aliasing Oscillators, and Aliasing Oscillators.

All “analogue” means to me is that the oscillator will display no aliasing artifacts.

I get the feeling you don’t want me here.

And lot’s of people recommended me to post here?

If it’s so, I out of here.

> This article refers specifically to the DCOs used in many synthesizers of the 1980s

And also happens to describe the tech used in recent products like the Elektron A4, most of the DSI products, the MFB triple DCO module.

Now give me a list of synths advertised as using “DCOs” - while they are in fact implemented with phase accumulators running at a fixed sample rate…

> There is no such thing as a Digital oscillator.

Digital refers to the implementation. “Digital filter” is correct terminology - a filter with a discrete-time implementation. By extension, “digital oscillator”…

Ok, fine by me.

I could just rename them OSC’s?

I’m not cheating on anyone.

It’s not a question about being wanted here or not.

You’ve shown a lot of sarcasm and attitude so far, and made bold claims about your product. If tt turns out that there are weaknesses in your product or the way you communicate about it, you have the choice of fixing them and raising your standards so that it conforms better to what DIYers/synth players are familiar with - or argue about them…

Ok, but it seems your the only one arguing?

You only wanted the code out in the open so that you could pick it apart and tell how bad it is?

But you were right about one thing, people don’t give a shit how it’s coded as long as it sounds good.

I’m not charging $200 for my synth and it still sounds pretty good.

>advertised as using “DCOs”
That is what I was trying to say with my link. It is the users who confused what DCO meant, not the manufacturers.

@janost: I think that your work is unique and full of potential. No one else is making units in the form factor you are, so I really want to see you succeed. I also think that you should take some of the coding advice provided by Oliver. He tends to be correct. In fact, that is the main reason for a developer to make their code available, so that they can get advice on it and improve their final product and user experience.

I don’t see why we are talking about the meaning of “DCO” or even oscillator at the moment. It would seem that you are trying to avoid the word “digital” as it is carrying a negative connotation in the current zietgiest of synthesizers. I suppose the best way to word these types of oscillators are filtered PWM. PWM and filter are two synthesis buzzwords that everybody loves. So oscillators produces via filtered PWM sounds quite nice and accurate to me. I guess this could be called an FPO?

Right, let’s try to break up the fight before it all goes down the shitter.
People usually don’t give a shit about the code, but a lot of DIYers do, it’s something I’ve seen around the forums, whether you choose to make neat code is up to you, like you said, as long as it sounds good, who really cares?
There is some sarcasm here and there, but pichenettes has a lot of experience coding this stuff, so any improvements he’s suggesting, should at least be considered. I’m not saying anything about him picking your code apart, but I for one would be delighted to have my synths’ code optimized by him, without having to learn the hard way myself.
Then again, I know I’m shit at coding, so I don’t have a synth I’m releasing upon the world, so take it with a solid bucket sized serving of salt :wink:

1 Like

@Janost: do a bit of background on what happened to the PreenFM when Olivier made a few suggestions about the codebase (hint: polyphony was doubled). He knows his stuff. And coming onto another manufacturer’s forum and getting into fights with them doesn’t dignify you. There are plenty of other builders who’ve managed to play nicely on this forum and enrich the discussion (Preen, Meeblip, TubeOhm, MidiSizer…) Over to you…

> You only wanted the code out in the open so that you could pick it apart and tell how bad it is?

You have a good product concept, and there’s a lot of scope for it.

It pains me that it won’t have the success it deserves because you are making what I believe are important mistakes in “project management” (obfuscating it) and coding/implementation.

> people don’t give a shit how it’s coded as long as it sounds good.

Actually: as along as it sounds good and “feels” good (the way parameters react/sweep when you change them). A linear cutoff knob does not feel good. If you have a frequency knob with 10Hz on one end and 10kHz on the other end, you’ll need to have 1k Hz in the middle. Not 5kHz.

There’s nothing wrong in itself with bad coding style/practices (usually they are “compiled out”) - but they are a sign that things are not understood; and on embedded targets, they are also a sign that things cannot be done as efficiently as they could be. Writing the code in a more concise/elegant style might allow the compiler to spot an optimization, or might remove superfluous operations, and this might free enough CPU to add another voice of paraphony or another synthesis block. Isn’t that good for the end-user - even if they won’t bother reading the source code?