I'd like to finish my synthesizer but it's hard

DSP, Plugin and Host development discussion.
RELATED
PRODUCTS

Post

Hi, suppose you want to create a software synthesizer and you know roughly what kind of music it is for and what the core ideas are, how do you go on?

Take a sheet of paper and write down what you want to achieve? List possible and impossible things? Or is it more like prototyping and having fun?

I'm stuck. I have this synthesizer that can do a few basic things and I want it to become like Novation Peak or something that sounds fascinating.

Post

For me, creativity is an evolutionary process. I need to iterate many ideas before something settles down, and it usually doesn’t go in expected ways. So I probably can’t advise apart from saying ‘just experiment.’ + Program quickly! 😁

Post

...
Last edited by codec_spurt on Fri Feb 28, 2020 4:57 am, edited 1 time in total.

Post

Thanks so much to both of you. I've now tried to be serious about it and wrote this text, please take it with a big grain of salt, I sometimes tend to overthink simple things and need an improved emotional state for some reason.

My algorithm for synth design version 0.0.0

1) Make a list of synths I like
2) Separate the matter "DSP component quality" from the matter "DSP component type" in my mind. Though, that's unfortunately debatable. But what way to start is there?
3) Go into a modular environment like Reaktor, Bitwig 3 or so
4) Design a non-modular synthesizer that can, by changing parameters only, do the beloved presets of all fav synths from the list, minus ~20% goodness of the fitting "components quality"

4b) That's hell of analysing things work. Like.. in that video with the amazing Novation Peak sound, what's going on at all? Mr. Heckmanns advice on KVR is seemingly, if I may quote him, to own the synth that you want to model. Now thats a point where buying Bazille instead of Novation Peak (whatever) would be cheaper.

Is it frowned upon to model software synth designs? Does it relate to my appearance and how I talk and what license (GPL?) I would like to make it? I actually just wanted to make music and drifted away. And I would never in my life do something that someone (admired, even non-admired) dislikes, publicly, implicitly.

5) Take 5 months time to design that little monster
6) Convert it by hand to fast programming language, it's christmas by now
7) add the 20% components quality by tuning DSP constants and doing typical improvement work
7b) asking here a lot for help to get the needed components quality + their symbiosis (constants etc) into it

Though, wavetable synthesis like e.g. earlevel does it, could I find that quality+flexibility in Reaktor or Bitwig? Synthedit oscillators e.g. had a bit of their own sound,
just...saying. If I force myself I could do it. I must not get dragged away by Reaktor presets (I've never used any such software).

Cost: Reaktor license + life time
Result: Best DSP topology to my knowledge

Sigh. I'm being serious. That's my first idea for it. "code paths" in an modular environment could be hard. I guess it will feel like "oh I just want to program it myself in a programming language". And I might have constant doubts whether point 2) separation of two (arbitrary?) matters is just an illusion to make myself go on. But it could be the whole point of modular environments? Or is that just that a lot of musicians or so don't like C++?

One point of all this is that recompiling different DSP things is not as much fun as I thought. I thought, after having chosen Golang as language for everything, it's so great. But it has turned to "still a lot of text", being able to (still) do programming errors. Awful feeling sitting there and thinking I know nothing about design, and I need a good synth quickly. ;) It feels a bit too low level, and I'm also not sure how much GUI redoing I can handle. I'm doing it just with TextOut on Windows to stay in time at all.

Ugh.

Alternative:

Buy $2000 hardware synth and record it. Plus maybe another one that does something certain better. Ouch.


-----------

Not so important Post Scriptum:

Another way: I could stick to the fact that synthesizers are self-explanatory by removing components from the end of the chain to the beginning of the chain, and adding them back together.

If I was sure there is this thing I would love to have a "copy" (sorry) of, I could start on the "left" side, the oscillator. There's quite a lot work there but analog synths sound so good to me, it would be not that hard for me personally. My thought sounds basic, and the problem is, is that the better way to approach it? I could stay in the programming language, save some money and time instead of investing it in Reaktor, and model closed source components or hardware components by turning of other components that mask them. Though, I don't really know where good sounding software synths are.

The hardware instruments shine with imperfections and saturation or something, and some U-he synths do that too (?), and there's FM8, and then there's just a lot of things with a lot of EQing in it? Looks not like a way to get me the Novation Peak or DSI experience from my software. At some point it's how do you want to make music instead of what DSP do you need, and I'm sorry for having posted that part of my story.

It's late and TBH I wish I could just give someone money to make the synth I love, but I'm afraid if I give them a list of things it should do, they will ask for a 6 digit number. Anyone about to sell their DSP topology, semi-modular or non-modular? Novation, DSI or Linplug sound, the "aww analog" sound, plus piano and orchestra. ;) Sorry.


This is the thing that it's about. No warranty, just for demonstration of problem: https://pastebin.com/7vUmAyc5

Post

You could do a lot of planning, procrastination, and thinking. BUT if this is your first synth, then perhaps you should probably make a few prototypes first, just to see the direction it's going in? Not thinking about coding but actually doing it like a sketch board. It'll probably also be a massive AND enjoyable learning curve. It'll be beneficial in the long run, and, you never know, you might reach your goal quicker than you thought.
Just start Puffin! Just start!
One benefit of buying hardware synths is that you can learn where there is more control over the sweet-spots areas. Also, audio comparisons are always fun. :)

Post

suppose you want to create a software synthesizer and you know roughly what kind of music it is for
Look up the history of the Roland TB-303, what style of music it was made for. And help god what have they done to it....

Regarding the way of working, are you familiar with IT projects? Back in the day, some architect would come up with a system sketch that could handle the administrative tasks of an organisation. Analysts then made detailed plans of what infomation flows where. Technical designers would make detailed designs, programmers then implement it, and finally it got tested. Months and years went by, several handovers, every detail thought out up front. The Waterfall method it's called.

Nowadays we do things differently. A rough direction to go is appreciated, but details are only thought out as needed, not up front. So we start to build a MVP: the Minimal Viable Product. Something actually usable. Then go from there. What is most important to improve? Or have we maybe made some mistakes and start all over? That's cheaper to do after a month than after some years. Still, throwing away months or years of work sometimes is the best thing to do.
We are the KVR collective. Resistance is futile. You will be assimilated. Image
My MusicCalc is served over https!!

Post

puffin wrote: Sat Jan 18, 2020 1:12 am Alternative:

Buy $2000 hardware synth and record it. Plus maybe another one that does something certain better. Ouch.
This just has to be said: that $2000 hardware synth is going to do absolutely nothing for you until you're already capable of developing a decent sounding software synth. It only really becomes useful when you're already approaching the state of the art and really want to model a particular piece of hardware as accurately as possible, but you are seriously wasting your money if you try to start from the deep end.

Start from the basics: write the most basic synth that will let you make some music. Then you can improve every part of it one by one. Eventually (after a couple of years) if you stick to it, you might find yourself poking an oscillator probe into some hardware synth with it's case removed, but that seriously is not where you should start.

Post

Find a synth example and pick it apart to see what does what. If you're a programmer at heart, you'll see a dozen or more things to do different or better. Replace bits of code, a method at a time, until it's all your own code, doing what you want it to do. Pencil and paper help, but use them in congress with looking at code. Save backups of your code often since you'll make changes you hate and need to go back.

Mostly, get some code in front of your eyes and start working! It's not going to program itself!
I started on Logic 5 with a PowerBook G4 550Mhz. I now have a MacBook Air M1 and it's ~165x faster! So, why is my music not proportionally better? :(

Post

Save backups of your code often
In other words:

Code: Select all

$ git init
$ git add *.*
$ git commit -m "work in progress"
We are the KVR collective. Resistance is futile. You will be assimilated. Image
My MusicCalc is served over https!!

Post

Thanks so much.

I know I could be stressing it, but may I ask another question? Do you experience the "urge" to write closed source software just for the sake of not getting into conflict with implications of open source, licenses and different laws in different countries?

I think .. I know closed source software also has licenses and agreements and is no different from open source when it comes to laws. But it's more with open source, isn't it? I want to do my best with attribution of works, and looking what things mean and how you have to behave.

Some things seem even to be in favor to the programmer, e.g. that "some math cannot be protected by copyright", something like math terms. I took this information from here where I basically asked what would happen if I include 17 tunings that are taken from a big collection that someone has made from probably expensive books. https://music.stackexchange.com/questio ... al-tunings

I have doubts that people will accept what I do when I might have just combined things, and merely just memorized things that I did not fully understand. On the one side I'm so much interested in having everything open source, on the other hand the implications seem overwhelming. The more open you are, the more you could be criticized.

Post

puffin wrote: Sat Jan 18, 2020 9:26 pmDo you experience the "urge" to write closed source software just for the sake of not getting into conflict with implications of open source, licenses and different laws in different countries?
For writing code: open-source is easier. You'll need a license either way (the unwritten "implicit" license is a very fuzzy concept which only exists in some countries).

With open-source, you have a bank of off-the-shelf options, each one designed and reviewed by a host of lawyers over the years to make sure that they work well everywhere.

For using other people's code: open-source can sometimes be easier here too. There will be plain-language summaries/guides for what you need to do for all the common licenses - including which other (standard) open-source licenses are compatible. (e.g. JUCE and the VST3 SDK, are licensed as GPL unless you sign a commercial license, so it's simplest if your code is also licensed the same way.)

So (in my view) open-source is actually the simple and easy option. The main reason not to is if you might want to make it commercial in future.

Post

Thanks for the explanation, signalsmith. I appreciate it.

Post

Hi, again, ..., I did not like the feeling that someone might think I try to be a puffin. I found them so cute. But had to register a different name, or to be honest, at first I deleted puffin, now I'm back with "beginzone".

I tried to go on with the tracker. Gave it a name, "keegu", and tried to add things. Many are as accessible as easter eggs, sigh, even if I don't want to, it needs time. If anyone is interested in a collection of Go interfacing and retro GUI code, you can download it, it's pre-alpha or alpha or prototype. The filter goes NaN because I tried experiments.

I just tell you so that if you have too much spare time, you might want to tell me how you like Go as language, or what's wrong with the project, or how .. now I don't know anything more.

When I want something to be open-source and get some "boost", should I upload it to Github?
Thanks for reading.
Last edited by beginzone on Mon Jul 13, 2020 1:30 pm, edited 1 time in total.

Post

beginzone wrote: Fri Jul 10, 2020 10:49 pm I just tell you so that if you have too much spare time, you might want to tell me how you like Go as language, or what's wrong with the project, or how .. now I don't know anything more.
How does Go handle it's garbage collection?

Usually the big problem with most managed garbage collected languages is that they need to stop all threads (at least briefly) at some point during the collection. This in turn means that in order to actually do anything real-time (where stopping the real-time threads is a no-go) you can't really allocate anything in ANY thread (that the run-time knows about, but usually you can't safely touch the GC heap at all from threads that the run-time doesn't know about) or you risk a GC pause glitching your real-time threads.

Post

mystran wrote: Sat Jul 11, 2020 12:01 am
beginzone wrote: Fri Jul 10, 2020 10:49 pm I just tell you so that if you have too much spare time, you might want to tell me how you like Go as language, or what's wrong with the project, or how .. now I don't know anything more.
How does Go handle it's garbage collection?

Usually the big problem with most managed garbage collected languages is that they need to stop all threads (at least briefly) at some point during the collection. This in turn means that in order to actually do anything real-time (where stopping the real-time threads is a no-go) you can't really allocate anything in ANY thread (that the run-time knows about, but usually you can't safely touch the GC heap at all from threads that the run-time doesn't know about) or you risk a GC pause glitching your real-time threads.
To be honest, I don't really know. What I know is loose facts, which I don't know how to combine to a real answer.

1) The garbage collector runs in a "separate" thread. Like, a thread where the chance is zero that you don't end up in a crash, when you write a OpenGL game with Go. It crashes at releasing textures, because the finalizer runs from the garbage collector thread, I believe. I forgot whether I got this fixed, stopped trying to make a game.

I have read that it could be the same situation with Java, which is said to have long stop the world pauses.

2) I need to call a certain "don't do bad things to my app" function named runtime.LockOSThread(), otherwise any app that uses OS calls itself is horribly unstable and seemingly race-conditions happen. I don't know what the function call actually fixes, or I have forgotten how it makes any sense.

3) The Go team claims to have garbage collection that has very, very short stop-the-world pauses.

I just tried to get along with it until it stopped crashing my synthesizer. Then it was slow. There's no SIMD available in the language itself like intrinsics, and normal loops run like 70% slower in general, I measured.

And then I put voice rendering into goroutines, and it became really fast. I can connect the MIDI keyboard and jam around, and it can go up to 50 or 100 (?) voices without buffer underruns at 32 samples latency with ASIO. On my I3-7320 2 core desktop the synth runs just fine. Well, it depends. At some time I had problems. And later I tried it on a I5-8250U 4 core mobile processor, and it performed really bad, crackles immediately.

I'm not sure how it will turn out, but I'm just afraid of C++ code at the high level or the C++ multi-threading. I exaggerate, but it takes only like 1 or 2 days until I have given it a dead reference, and when it crashes, I need to be good at the debugger, but sometimes the app simply does undefined behaviour. So I will try to use Go no matter what.

Post Reply

Return to “DSP and Plugin Development”