# Creating YOUR OWN DIY amp sim plugin



## Gmork (Apr 3, 2020)

Surprisingly ive never thought of it before, but id absolutely love to learn how to start making my own plugins.
I dont even know where to start and know it would be a long and arduous path, but never the less i really want to look into it.

Anyone out there work on their own plugins and can help point me in the right direction with DIY amp sims?


----------



## TedEH (Apr 3, 2020)

This sounds like a similar question to "how do I make my own video game?" - as in you probably couldn't sum it up in a forum post. I've never made a plugin, and I have no idea what your skill sets are, or what tools you might be starting with, but I think a good start might be to look up the vst sdk.

This might be it:
https://www.steinberg.net/en/company/developers.html


----------



## odibrom (Apr 3, 2020)

Programming and audio analysis, lots of math. then, you will also need a User Interface or someone who can draw it for you. Those that are appealing have lots of design there. Every software have a huge team working together. I say that you'd need at least a team of 2, one for the graphic design / User interface and another for the programming stuff. Both in one person is an almost impossible mission to do in a useful time frame. Then, there's the testing and marketing and debugging and...

Don't get me wrong, I think it's wonderful for one to think about it and get hands on the subject. If you can handle this, just go for it.


----------



## Gmork (Apr 4, 2020)

Oh for sure, never thought itd be an easy thing but as theres Unity for those interested in game design 
which is even free! i wondered if perhaps theres some base program available for vst audi plugins.
Its pretty interesting and id just genuinely like to know how theyre made lol.


----------



## Mvotre (Apr 6, 2020)

I believe the easiest way would be building something from a Arduino at first:

https://create.arduino.cc/projecthub/electrosmash/arduino-uno-guitar-pedal-b2ba96

sound is a bit lame, but at least you can start figuring out how everything works. The next step would find what language most plugins where written and learn that. But it should be a long journey if you never programmed before


----------



## TedEH (Apr 6, 2020)

The arduino advice seems a little backwards to me - that's just tacking on additional skillsets that aren't needed to write audio plugins.

I linked the VST sdk in the first reply I made. It looks like you just need that kit, some C++ knowledge, some signal processing knowledge probably, and the time to invest in the project. Probably a lot of time.


----------



## Splenetic (Apr 6, 2020)

Gmork said:


> Oh for sure, never thought itd be an easy thing but as theres Unity for those interested in game design
> which is even free! i wondered if perhaps theres some base program available for vst audi plugins.
> Its pretty interesting and id just genuinely like to know how theyre made lol.



There is. It's called RackAFX, and the dude has a book out with it. http://www.willpirkle.com/

That said, better brush up on your math, and I'm talking HEAVY math. Oh and know/learn C++ or you're not going anywhere with it.


----------



## nickgray (Apr 6, 2020)

I imagine you need a fair bit of knowledge in DSP programming and electrical engineering, both will be pretty heavy on the applied math side of things. Probably a good way of starting would be to look up intro-level college books and figure out what's lacking in your math background, as well as looking up syllabus for EE degree, and you'd likely need some basic CS background as well.

Of course, all of that is for serious shit. For just dicking around, there's probably something like SynthEdit that could be used for modeling valve preamps and power amps, which should be a tiny little bit easier.


----------



## fcv (Apr 6, 2020)

I'm just taking a complete shot in the dark here, but I'd tend to guess you chunk up the audio data, apply some sort of window like a hamming window, do a Fourier transform to get frequency information, boost the frequency levels, but cap them to certain thresholds for gain, further adjust the frequency levels for eq, then run it through an inverse Fourier transform, probably use another windowing function, and reassemble.

Not sure why so many of you are focusing on stuff like interfaces. Don't need to look pretty to work.


----------



## TedEH (Apr 6, 2020)

I would wonder if it might make sense to start even smaller than that. Step one -> just clip your sample to get some really bad sounding fuzz. Step two or three is probably what's recommended above.


----------



## R34CH (Apr 6, 2020)

Interesting topic. I guess I always just assumed people would model the amp they are trying to recreate (i.e. resistor of this value goes here, such and such capacitor there) in something like Mathworks Simulink and then wrap a fancy UI around it.

I'm sure I'm simplifying it way too much, but it doesn't seem that hard if the amp you're trying to model has a schematic freely available. 

Doing it well, however, heh...


----------



## TedEH (Apr 6, 2020)

I'm not familiar with simulink, but if it can spit out C / C++ implementations of your model, then I don't see why that wouldn't work, outside of maybe performance concerns.

I've not really done any proper audio programming, but my understanding is that it has to be _fast_. The odd time I've had to do anything audio related for games, any performance hiccups in your audio was very audible.

I'm curious whether this is not far off from the process used to create some plugins.


----------



## astrocreep (Apr 6, 2020)

https://www.amazon.co.uk/Lets-build-plugins-Saturator-programming-ebook/dp/B07V1XJ1RH/ ?


----------



## fcv (Apr 6, 2020)

R34CH said:


> Interesting topic. I guess I always just assumed people would model the amp they are trying to recreate (i.e. resistor of this value goes here, such and such capacitor there) in something like Mathworks Simulink and then wrap a fancy UI around it.
> 
> I'm sure I'm simplifying it way too much, but it doesn't seem that hard if the amp you're trying to model has a schematic freely available.
> 
> Doing it well, however, heh...


That's also a valid approach, however accurately modelling how real components actually behave in real life conditions can be incredibly difficult, and performance intensive.


----------



## Chebax (Apr 6, 2020)

Funny enough, I also started doing some research on my own on the topic today.
(I'm a software engineer with some background on signal processing so I thought this would be an interesting project)

I found a few posts that look interesting, but I haven't had time to start playing with them yet. Look at this one:

http://www.martin-finke.de/blog/articles/audio-plugins-001-introduction/

Also, I'm interested in the idea of black-box profiling of amps with deep learning. This is hardcore nerdy stuff:
https://www.mdpi.com/2076-3417/10/3/766

Is this how the Neural DSP plugins work?

Let us know if you end up building anything!


----------



## Gmork (Apr 6, 2020)

Chebax said:


> Funny enough, I also started doing some research on my own on the topic today.
> (I'm a software engineer with some background on signal processing so I thought this would be an interesting project)
> 
> I found a few posts that look interesting, but I haven't had time to start playing with them yet. Look at this one:
> ...


Probably safer to say, YOU let us know when YOU build something. Im dumb as a bag of bricks lol. Its probably more likely ill build an actual amp as its more hands on, follow the instructions type work. As much as i love diving into the audio side of things like frequencies and all that i just cant see myself learning c++, but i guess we'll see.

Kind of wish i could just work WITH someone and sit in the passanger seat and make suggestions etc.

But like others have said, definitely an interesting subject!


----------



## bostjan (Apr 6, 2020)

Gmork said:


> Probably safer to say, YOU let us know when YOU build something. Im dumb as a bag of bricks lol. Its probably more likely ill build an actual amp as its more hands on, follow the instructions type work. As much as i love diving into the audio side of things like frequencies and all that i just cant see myself learning c++, but i guess we'll see.
> 
> Kind of wish i could just work WITH someone and sit in the passanger seat and make suggestions etc.
> 
> But like others have said, definitely an interesting subject!



Heh, well, building an amp is a totally different skills set than designing an amp.

C++ isn't really that difficult at all, but honestly, is that what you'd use to make a plug-in for a DAW?

I'm pretty good at mathematics, or at least I took a lot of classes and got good marks, but I really think that the bottle-neck stopping people from doing this sort of thing on their own is *time*. I can crank out code to do all sorts of stupid stuff, and I can play with numbers and circuits and all of that jazz, but I don't have the time nor the patience to take on a task like this.


----------



## Chebax (Apr 6, 2020)

As a father of 3 young kids and working for a startup I guess I'd be fooling myself if I think I can find time for this. 

But well, I'll play a bit with it and let you guys know if the idea ever goes anywhere. At least I'm sure it'd be easy to find beta testers here.


----------



## Sumsar (Apr 6, 2020)

Tbh I don't think you need that much math knowlegde. You need to get an intuition for what the math means and does (like convolution filters etc), but you don't need to prove it, assume some math guy/girl already did that for you and you just have to implement it - can you tell I have a masters in physics and not in math  ?

I also thought about this a couple of years ago, but quickly realized it is a black whole to get stuck into to learn all that is needed.
I guess it does depend on your approach as was mentioned earlier. Do you try to model every component and how they play together or do you just do a lot of analysis of an actualy amp with sine curves, white noise etc to measure EQ, time, harmonics, compression, input volume dependency of the aforemention etc.
In the later case I guess you should start by modelling an idealized guitar sound, as in what comes out of the pickups, since that is the input signal that your amp will mathematically speaking transform to the output signal and you seek the function that does that transformation given not any input signal, just the guitar input signal.
Anyway ranting, but you can see how you can quite easily spend an eternety on this


----------



## TedEH (Apr 7, 2020)

bostjan said:


> C++ isn't really that difficult at all


I dunno that I'd say that. The basics are as "easy" as any programming, but audio isn't a beginners topic, IMO, and it needs to be performant, which can lead you down some potentially deep and complicated rabbit holes of optimization. Writing performant C++ has a lot of pitfalls. Arguably, writing _any_ C++ has a lot of pitfalls. It's not a "become good at in it a weekend" kind of skill. I say this as someone who uses C++ pretty regularly, started learning it a decade ago, and still haven't really put a dent in getting good at it.

I made a really basic synthesizer in C++ for midi playback in a game about a year ago, using WASAPI, and it was a significant challenge. Building an amp sim from scratch without existing programming knowledge, math knowledge, etc., is going to be a huge uphill battle. I won't call it impossible, but it's a huge undertaking IMO. It's like saying "I want to build my own car, but I've never so much as changed a tire before".


----------



## bostjan (Apr 7, 2020)

TedEH said:


> I dunno that I'd say that. The basics are as "easy" as any programming, but audio isn't a beginners topic, IMO, and it needs to be performant, which can lead you down some potentially deep and complicated rabbit holes of optimization. Writing performant C++ has a lot of pitfalls. Arguably, writing _any_ C++ has a lot of pitfalls. It's not a "become good at in it a weekend" kind of skill. I say this as someone who uses C++ pretty regularly, started learning it a decade ago, and still haven't really put a dent in getting good at it.
> 
> I made a really basic synthesizer in C++ for midi playback in a game about a year ago, using WASAPI, and it was a significant challenge. Building an amp sim from scratch without existing programming knowledge, math knowledge, etc., is going to be a huge uphill battle. I won't call it impossible, but it's a huge undertaking IMO. It's like saying "I want to build my own car, but I've never so much as changed a tire before".



I stand by my statement under that context. As difficult as audio is to handle with a high-level programming language, it's easier with C++ than it would be with virtually any other language- mainly because someone else has probably already made a library for what you want to do. Building a C++ library for handling audio would probably not even be something you'd dream of doing in C++ itself, rather where I feel like low level code would do a much better job, although coding in ASM or whatever has always been a nightmare for me, personally...

For midi playback, I made my own utility in ASM once (probably before half the people on this forum were even born), to run in C or Pascal, it worked most of the time, but by the time I finished it, a bunch of other people on the message boards had already made better ones. Plus, the rare occasions when it didn't work, it crashed catastrophically. But I digress.

I agree 100% with the analogy. I technically could build my own car from scratch, if I either had the tools or made the tools myself to do it, and if I invested the tremendous amount of time into it that it required. I'd guess ten million dollars worth of tools could do it, and maybe ten to fifteen years of fiddling around to figure out how things worked in practice. Or I could just buy a car for a tiny fraction of that cost, and it'd not only be much more convenient, but it'd almost definitely work better.


----------



## TedEH (Apr 7, 2020)

bostjan said:


> I'd guess ten million dollars worth of tools could do it, and maybe ten to fifteen years of fiddling around to figure out how things worked in practice.


I feel like this part is as good an analogy in itself. Want some software made? Either spend a ton of time or a ton of money. And no guarantee it'll be any good after that.


----------



## bostjan (Apr 7, 2020)

Yes, and you know that, at some point, someone is going to develop some sort of open source VST amp sim that is so flexible and customizable that no one will care about the topic of this thread anymore. Probably some group of university students who won't make a dime off of it.


----------



## astrocreep (Apr 8, 2020)

As well as the book linked previously you might want to pick a framework like JUCE which does some of the interface work for you, and has some beginner tutorials on youtube. 

(I'm not a pro, I've studied Acoustics at uni about 12 years ago including looking at amp sims a bit. Then I was doing off line experimentation in Matlab with Dynamic Convolution. 
My broad conclusion at the time was that decent speaker emulation was probably 70% of the battle soundwise rather than the saturation component)


----------



## fantom (Apr 9, 2020)

I definitely would not advise taking on a VST without building up to it. Most college classes do not even discuss interacting with hardware or GUIs for good reason.

If your goal is to tinker and learn programming and audio processing, you are talking about learning a skill that fails about 70% of college students and upper level college math at the same time. Lower your expectations and don't expect a working product and it could be fun. If you want to save money and use the end product... Well it might not be a good experience.



bostjan said:


> C++ isn't really that difficult at all, but honestly, is that what you'd use to make a plug-in for a DAW?



The SDK is in C++. Unless you want to learn cross language programming (hint: you don't), C++ is kind of required.



Sumsar said:


> Tbh I don't think you need that much math knowlegde. You need to get an intuition for what the math means and does (like convolution filters etc), but you don't need to prove it, assume some math guy/girl already did that for you and you just have to implement it - can you tell I have a masters in physics and not in math  ?



As a professional programmer who works with a lot of brilliant people, this is a big reason that projects are buggy and take far longer to complete than estimated. People underestimate what they do not deeply understand and make critical flaws because they don't take time to truly learn how things work.



TedEH said:


> I dunno that I'd say that. The basics are as "easy" as any programming, but audio isn't a beginners topic, IMO, and it needs to be performant, which can lead you down some potentially deep and complicated rabbit holes of optimization. Writing performant C++ has a lot of pitfalls. Arguably, writing _any_ C++ has a lot of pitfalls. It's not a "become good at in it a weekend" kind of skill. I say this as someone who uses C++ pretty regularly, started learning it a decade ago, and still haven't really put a dent in getting good at it.



This. Performance audio programming is considerably harder than graphics programming. The output rates are much higher and 99% of people don't have any hardware acceleration (equivalent of a GPU).



bostjan said:


> I agree 100% with the analogy. I technically could build my own car from scratch, if I either had the tools or made the tools myself to do it, and if I invested the tremendous amount of time into it that it required. I'd guess ten million dollars worth of tools could do it, and maybe ten to fifteen years of fiddling around to figure out how things worked in practice. Or I could just buy a car for a tiny fraction of that cost, and it'd not only be much more convenient, but it'd almost definitely work better.



I think the programming joke hear is most students think they can build a MMORPG on their own. Then they can't even write a Unity script for a single boss fight in an entire semester and make it do what they wanted.



bostjan said:


> ...it's easier with C++ than it would be with virtually any other language- mainly because someone else has probably already made a library for what you want to do.



I would say, at best, most "already made" code for nontrivial things is garbage unless you are paying for it. Either you will have unexpected bugs and no support or a convoluted API that is more difficult to figure out than the math to write it yourself. Every commercial library I have used has been unequivocally better and easier to use than open source variants. This was by far one of the most shocking things for me to learn when I got a real job and realized I was being trained that hobby code was "good". If you want a nice piece of gear, you go to a reputable builder, not someone who tinkers on weekends. Code is much easier to screw up.


----------



## c7spheres (Apr 9, 2020)

If you look at the Fractal audio website under careers, they give a list of qualifications for what they're looking for. I'd imagine writing a plu gin is similar levels of knowledge. But as mentioned, yes C++ and all that stuff already mentioned is listed.


----------



## TedEH (Apr 9, 2020)

fantom said:


> Performance audio programming is considerably harder than graphics programming.


I don't know that I'd go that far. Having a GPU available doesn't magically make graphics programming easier. Someone still needs to setup that pipeline and write those shaders, etc. Deep diving into either is gonna get complicated, one way or another. Really depends on what you're doing. There are smaller, beginner steps that can be taken in either one of those, and there are advance, complicated topics to take on.

The trick isn't to give up on the goal of (making an amp sim / making a game / getting in better shape / improving career / anything) it's to keep your expectations reasonable and take things a step at a time. Can one person make an amp sim? Sure. There's just a ton to do before you get there, and it's not realistic for everyone.


----------



## Nicki (Apr 9, 2020)

I'm going to chime in here since I'm a programmer.

C++ is one of the hardest languages to work with. As @TedEH mentioned, there's lots of pitfalls, especially if you've never written code before and have no idea what you're doing. Big C++ is arguably the best book for learning to code C++. That being said, C++ will be your best bet because of its speed when code is properly optimized.

Moving away from compiled languages, you get into the realm of scripting languages. Ruby is another option that you could learn to code your own VST with. It's easier to code than C++ but it's less forgiving than other scripting languages. I haven't touched Ruby in years so I can't fully speak to what the process would be like.

Personally, I would go with Python, another scripting language. Python is very easy to develop, it's a very forgiving language (in terms of code not being all that optimized), it's fast, and it has superior GUI (Graphical User Interface) support than both C++ and Ruby. Python would be a good tool to create a prototype VST. Python Crash Course from No Starch Press is a very good book to go through to learn the language.

Reaper also apparently has a built in scripting tool that you can use to create your own VSTs, so you could look into that as well.

I would caution against coding a VST without any prior knowledge of programming. If you don't know standard OOP (Object Oriented Programming), you're going to have a very difficult time understanding how to code a VST. With programming, I tell people that you can't walk before you run, because you need to crawl before you walk.


----------



## TedEH (Apr 9, 2020)

Nicki said:


> Reaper also apparently has a built in scripting tool that you can use to create your own VSTs, so you could look into that as well.


Correct me if I'm wrong, but it's a javascript-style thing right? The end result isn't really a vst though. Vst is a specific type of plugin using Steinbergs standard, I think. That being said, it might be a much easier way to sort of dabble in how to process some audio without having to deep dive into C++.


----------



## TedEH (Apr 9, 2020)

Nicki said:


> since I'm a programmer


I suppose it's not too surprising that there's a lot of programmers on this forum.


----------



## Nicki (Apr 9, 2020)

TedEH said:


> Correct me if I'm wrong, but it's a javascript-style thing right? The end result isn't really a vst though. Vst is a specific type of plugin using Steinbergs standard, I think. That being said, it might be a much easier way to sort of dabble in how to process some audio without having to deep dive into C++.



I don't know. I've never used it, but it would at least be a way to get your feet wet, I suppose. But I agree, it's probably easier than getting into full blown C++ programming.



TedEH said:


> I suppose it's not too surprising that there's a lot of programmers on this forum.


STEM fields are the most popular fields of study these days so I guess not!


----------



## fcv (Apr 9, 2020)

IMO what you can make VSTs with or integrate into reaper shouldn't even be a concern at this point. Should use whatever you think you can get an uncompressed wav loaded up in with the least amount of effort. That way you can try some stuff out and see if you end up with anything worth persuing. If you like the results, then go back and figure out how to integrate it. I also think performance concerns are a long way off regardless of what you use when you're at this stage of trying to learn what you're doing. Premature optimizations and wasting too much time figuring out tooling you want to use instead of just doing it are deadly to projects.


----------



## TedEH (Apr 9, 2020)

^ Realistically, Reaper's js plugins are a good way to do just that. It's a way to skip all the setup and just jump right into messing with with audio via scripts. The source for all the packed-in ones are right there for you to mess with or change or use as a reference.


----------



## fantom (Apr 9, 2020)

fcv said:


> IMO what you can make VSTs with or integrate into reaper shouldn't even be a concern at this point. Should use whatever you think you can get an uncompressed wav loaded up in with the least amount of effort. That way you can try some stuff out and see if you end up with anything worth persuing. If you like the results, then go back and figure out how to integrate it. I also think performance concerns are a long way off regardless of what you use when you're at this stage of trying to learn what you're doing. Premature optimizations and wasting too much time figuring out tooling you want to use instead of just doing it are deadly to projects.



Pet peeves... But you are stating a common fallacy here. Optimization in C++ would be converting code profiled to be slow into assembly or making it more convoluted to shave off time or I/O. Premature optimization would be doing that before you even know if it matters. It has nothing to do with making sure the software requirements can be met. Read
https://ubiquity.acm.org/article.cfm?id=1513451

A vst needs to be performant. It should be able to process in real time so a user doesn't have to render the audio. Planning for that early is called design, not optimization.

This is getting a bit off topic for the OP. If the OP wants to try audio processing without a DAW or real time controls, which would help prototype to understand the core logic, then Matlab or other languages would be super useful. But he asked about a vst.


----------



## fantom (Apr 9, 2020)

TedEH said:


> I don't know that I'd go that far. Having a GPU available doesn't magically make graphics programming easier. Someone still needs to setup that pipeline and write those shaders, etc. Deep diving into either is gonna get complicated, one way or another. Really depends on what you're doing. There are smaller, beginner steps that can be taken in either one of those, and there are advance, complicated topics to take on.
> 
> The trick isn't to give up on the goal of (making an amp sim / making a game / getting in better shape / improving career / anything) it's to keep your expectations reasonable and take things a step at a time. Can one person make an amp sim? Sure. There's just a ton to do before you get there, and it's not realistic for everyone.



As someone who has had to work in both domains, I stand by my statement.

I completely agree with the sentiment here though. I'm not trying to discourage the OP, just setting expectations that this isn't soldering together a di box or boost pedal. It will have a much higher learning curve and fewer instructions.

I would suggest to the OP to pick an area that is interesting, such as making a GUI or processing audio, and do that in isolation. In other words, if you are interested in audio processing. Write a simple command line tool to take a pcm wav file, transform it, and output a pcm wav file. For the GUI, try to make the UI without knobs or buttons doing anything. It isn't advised to take on the entire project at the same time.


----------



## fantom (Apr 9, 2020)

TedEH said:


> I suppose it's not too surprising that there's a lot of programmers on this forum.



Professional musician sounds like a better idea until you need to pay your bills.


----------



## bostjan (Apr 9, 2020)

I think, as usual, we are laser-focusing in on a topic that isn't really the OP's question.

"Can you develop your own amp sim to tool around in your own studio without 20 years of programming experience, thousands of dollars in C++ libraries, and a Ph.D. in applied mathematics?" _or_ "Can you develop your own amp sim that is a perfectly flawless commercial product with a spanner and a pre-used strip of duct tape?"

I've developed commercial software on my own that worked as a backend piece of a bigger commercial package. I've never made a commercial GUI or anything even remotely front-end. If I was a company and wanted to make an amp sim, I would hire people to do that. I'd probably hire at least half a dozen people just for this project. But that's not really what we were trying to discuss here in the first place.

But! - Even if I just wanted to make an amp sim that I could use myself for my own projects, I wouldn't expect that, working by myself with limited tools, I would be able to do so, say, in a summer. Maybe in a year if I was lucky.



Nicki said:


> I'm going to chime in here since I'm a programmer.
> 
> C++ is one of the hardest languages to work with. As @TedEH mentioned, there's lots of pitfalls, especially if you've never written code before and have no idea what you're doing. Big C++ is arguably the best book for learning to code C++. That being said, C++ will be your best bet because of its speed when code is properly optimized.



Different perspective, but I diagree. Compiling languages are more difficult than scripting languages, as a rule of thumb. There's a lot more that can go wrong. But, for a compiling language, C++ is loads easier to use than, say, Fortran, which is a nightmare to use, from a debugging standpoint. C++ is quite a bit easier to use than C or even Pascal (not Turbo Pascal, which is probably a little easier but less powerful). I mean, machine language is much more difficult than assembly languages, which is more difficult than compiler languages, and so on. More power = more difficultly executing the same sort of task.



Nicki said:


> Moving away from compiled languages, you get into the realm of scripting languages. Ruby is another option that you could learn to code your own VST with. It's easier to code than C++ but it's less forgiving than other scripting languages. I haven't touched Ruby in years so I can't fully speak to what the process would be like.
> 
> Personally, I would go with Python, another scripting language. Python is very easy to develop, it's a very forgiving language (in terms of code not being all that optimized), it's fast, and it has superior GUI (Graphical User Interface) support than both C++ and Ruby. Python would be a good tool to create a prototype VST. Python Crash Course from No Starch Press is a very good book to go through to learn the language.



If Python has any decent audio tools ready to rock, then that'd be great, but does it? If not, I think trying to create pro audio tools in any scripting language would be a bit of a nightmare. But it seems that Python has utilities for everything these days.



Nicki said:


> Reaper also apparently has a built in scripting tool that you can use to create your own VSTs, so you could look into that as well.
> 
> I would caution against coding a VST without any prior knowledge of programming. If you don't know standard OOP (Object Oriented Programming), you're going to have a very difficult time understanding how to code a VST. With programming, I tell people that you can't walk before you run, because you need to crawl before you walk.



I'd go one step further and say that even if you have years of experience as a hobbyist with OOP, making a VST from scratch will likely drive you mad, unless you have some good software tools specifically for that task. If reaper has a scripting tool to create VST's, that'd be the only thing I would recommend for a beginner.


----------



## TedEH (Apr 9, 2020)

bostjan said:


> C++ is loads easier to use than, say, Fortran, which is a nightmare to use, from a debugging standpoint.


I have a feeling the bunch of us all come from very different software backgrounds, since I wouldn't have even thought of fortran as an option. I legitimately don't know if people even still use fortran.  I mean, I'm sure it's still used, but I don't know for what.


----------



## fcv (Apr 9, 2020)

fantom said:


> Pet peeves... But you are stating a common fallacy here. Optimization in C++ would be converting code profiled to be slow into assembly or making it more convoluted to shave off time or I/O. Premature optimization would be doing that before you even know if it matters. It has nothing to do with making sure the software requirements can be met. Read
> https://ubiquity.acm.org/article.cfm?id=1513451


https://ubiquity.acm.org/article.cfm?id=1513451

Using a particular tool purely because you think it will perform better is an attempt at optimizing. There is nothing that has anything to do with whether requirements can be met here. Your prized carefully designed C++ implementation is going to have a negligible performance difference from some janky hacked together tech demo in an interpretted language when the complexity of the simulation is at the level of OP's first attempt at processing something, because neither of them is going to be remotely taxing on a modern computer.


----------



## Nicki (Apr 9, 2020)

bostjan said:


> ...
> 
> Different perspective, but I diagree. Compiling languages are more difficult than scripting languages, as a rule of thumb. There's a lot more that can go wrong. But, for a compiling language, C++ is loads easier to use than, say, Fortran, which is a nightmare to use, from a debugging standpoint. C++ is quite a bit easier to use than C or even Pascal (not Turbo Pascal, which is probably a little easier but less powerful). I mean, machine language is much more difficult than assembly languages, which is more difficult than compiler languages, and so on. More power = more difficultly executing the same sort of task.
> 
> ...



I think it all depends on the tools you're working with. As someone who spends 90% of my life in C#, I prefer that as my compiled language of choice over C++ any day of the week. I hated C++ in college and I hate it even more now because C# has spoiled me to death with how easy it is to develop.



bostjan said:


> ...
> 
> If Python has any decent audio tools ready to rock, then that'd be great, but does it? If not, I think trying to create pro audio tools in any scripting language would be a bit of a nightmare. But it seems that Python has utilities for everything these days.
> 
> ...



PYO



bostjan said:


> ...
> 
> I'd go one step further and say that even if you have years of experience as a hobbyist with OOP, making a VST from scratch will likely drive you mad, unless you have some good software tools specifically for that task. If reaper has a scripting tool to create VST's, that'd be the only thing I would recommend for a beginner.



Same. It's probably the easiest route for dabbling.


----------



## TedEH (Apr 9, 2020)

Nicki said:


> As someone who spends 90% of my life in C#, I prefer that as my compiled language of choice over C++ any day of the week


I'm exactly the opposite -> I also spend 90% of my life in C# land right now, and I wish it was C++ instead. 



Nicki said:


> PYO


Cool.


----------



## fantom (Apr 9, 2020)

fcv said:


> Using a particular tool purely because you think it will perform better is an attempt at optimizing. There is nothing that has anything to do with whether requirements can be met here. Your prized carefully designed C++ implementation is going to have a negligible performance difference from some janky hacked together tech demo in an interpretted language when the complexity of the simulation is at the level of OP's first attempt at processing something, because neither of them is going to be remotely taxing on a modern computer.



Did you even read the link? The article is written by very well respected computer scientists regarding how the quote has been misused in modern times to make poor decisions. Picking an appropriate language is part of design, not optimization.

Observation #2: Many software engineers believe that optimization is the act of ensuring an application has adequate performance. As a result, those engineers do not consider application performance during the design of the software, when it is critical to do so.​
It is absolutely critical to pick an appropriate language for the task. In this case, C++ is appropriate. Not because I prefer it or any other junk. Because it will interoperate with the given SDK with least hassle.

​


----------



## fantom (Apr 9, 2020)

To be super clear, it is perfectly fine to use reaper scripts, C#, fortran, etc. I am not saying C++ is the best choice to learn. My comment is 100% targeted at the use of "premature optimization" as a reason not to use C++. The phrase is completely out of context with what the experts mean. Choosing scripting tools within reaper or direct use of the sdk is a *design* choice. It's like choosing to build your house out of bricks instead of wood. That isn't an optimization.


----------



## fcv (Apr 9, 2020)

fantom said:


> Did you even read the link? The article is written by very well respected computer scientists regarding how the quote has been misused in modern times to make poor decisions. Picking an appropriate language is part of design, not optimization.



Of course not. I didn't see any reason to follow a random unlabelled link which seemed to exist for the sole purpose of justifying yourself for nitpicking my terminology.

Glad I didn't, now that I know more about it. I definitely have no interest in a bunch of self proclaimed experts whining about how they don't like people's phasing. I use words I think adequately describe what I mean, and don't care about whether they would approve.


----------



## fantom (Apr 9, 2020)

fcv said:


> Of course not. I didn't see any reason to follow a random unlabelled link which seemed to exist for the sole purpose of justifying yourself for nitpicking my terminology.
> 
> Glad I didn't, now that I know more about it. I definitely have no interest in a bunch of self proclaimed experts whining about how they don't like people's phasing. I use words I think adequately describe what I mean, and don't care about whether they would approve.



Your loss. The acm is not random. That is like calling the CDC a random source for virus information.


----------



## TedEH (Apr 9, 2020)

This thread has gone well.

Anyone else have any audio plugin tools / scripting / libraries / etc to contribute?


----------



## fantom (Apr 9, 2020)

The javax.sound libraries were straightforward to use if the goal is to just use midi and pcm wav.
https://docs.oracle.com/javase/8/docs/technotes/guides/sound/index.html

I wouldn't suggest trying to build it into a vst, but it would be more than suitable for prototyping a standalone app. Could start with command line and throw a Java GUI on it after it is running.

Keywords: prototyping / tinkering.


----------



## Nicki (Apr 11, 2020)

fantom said:


> To be super clear, it is perfectly fine to use reaper scripts, C#, fortran, etc. I am not saying C++ is the best choice to learn. My comment is 100% targeted at the use of "premature optimization" as a reason not to use C++. The phrase is completely out of context with what the experts mean. Choosing scripting tools within reaper or direct use of the sdk is a *design* choice. It's like choosing to build your house out of bricks instead of wood. That isn't an optimization.


In the context of this thread, I don't believe that optimization would of concern as (assumingly) OP doesn't have any knowledge of computer programming languages. For a professional level plugin, developed by an experienced programmer (and sound engineer?), yes, C++ is probably best. However, if a VST plugin is the first project OP wants to take on, the bigger concern would be getting it to work, rather than work well.


----------



## Boofchuck (Apr 11, 2020)

Chebax said:


> Funny enough, I also started doing some research on my own on the topic today.
> (I'm a software engineer with some background on signal processing so I thought this would be an interesting project)
> 
> I found a few posts that look interesting, but I haven't had time to start playing with them yet. Look at this one:
> ...


Thanks for posting those links, I've been very interested in this subject as well and that's exactly the kind of reading I've been looking for. Very cool.


----------



## fantom (Apr 11, 2020)

Nicki said:


> In the context of this thread, I don't believe that optimization would of concern as (assumingly) OP doesn't have any knowledge of computer programming languages. For a professional level plugin, developed by an experienced programmer (and sound engineer?), yes, C++ is probably best. However, if a VST plugin is the first project OP wants to take on, the bigger concern would be getting it to work, rather than work well.



I agree it is irrelevant to the original post. The entire discussion thread was flagged, by me, as off topic to the original reply...



fantom said:


> Pet peeves... But you are stating a common fallacy here...
> 
> ... This is getting a bit off topic for the OP. If the OP wants to try audio processing without a DAW or real time controls, which would help prototype to understand the core logic, then Matlab or other languages would be super useful. But he asked about a vst.



Now that I feel super stupid for quoting my own post. if the OP wants to write a VST, it makes way more sense to build on top of the Steinberg SDK then try to get other random languages working. Any discussion about optimization is people using the terminology poorly. I'm suggest to make it a choice to integrate with the SDK with less issues. That isn't about optimization. That is planning. If I were to pick up building a real amp as a hobby, I would hope people tell me that buying a soldering iron and some flux before I start working is a good idea. Because planning out the process kind of saves headaches from happening. What I would not want is a bunch of people telling me to look into chainsaws and paint brushes, because they aren't the right tool for the task.


----------



## fantom (Apr 11, 2020)

So to keep on topic. For the original post, if the goal is to build a VST. Download the free version of Microsoft Visual Studio and download the Steinberg SDK linked on the first page of the thread. I would hope the SDK has some examples in it. If so, try to compile and link them without changes and run them in your daw. If they work, great. If not, ask some questions.

A completely separate task is to learn the dsp math to try some things out. You could do this in any language you want with the goal of internalizing the math to move into the vst you built before later. I would suggest any of the things in this thread that have a decent pcm wav library. The pcm wave format is probably what you need to use for audio data.


----------



## TedEH (Apr 12, 2020)

I never really looked at it, but I imagine the sdk probably has enough in it to handle getting the audio to you, so there's no real point in looking up how to read wave files. The actual PCM data itself is very straitforward I think. If I remember right, it's literally just a stream of samples, and the channels are interleaved.


----------



## laxu (Apr 16, 2020)

You can get started building something out of a pile of filters that EQ the input signal in different ways. Your basic cab sim is pretty much a high and low pass filter for example. I'm sure there are some GUI tools that let you play with something like this, no idea what they are tho.

But no, you can't build an amp sim plugin that would be anywhere near the quality you most likely expect from such a thing. That doesn't mean you can't have something usable. Amp sims are a pretty specific niche of DSP programming and there isn't much material relating specifically to building an amp sim.


----------

