to learn software programming

[chord]

What are the legalities of programming a synth in a programlike like MAX/MSP or Reaktor?

Could it indeed be stand alone without any of the drivers from the original program?

Is there a way to then uncompile it and recode it so that it would work as VSTi, DXi, RTAS or AU plug-in?


More importantly...could you sell it and not get sued by Native or Cycling 74?

[VitaminD]

dear urs
how to be like you in programming
take C, C++, java and what else?
let people know the real deal
you mention you could give tips on programming unix
what are they?
thanks

There is an art to programming no? an underlining creativity to how one problem solves.. You'll never be URS, you'll forever be you just be the best you!

I'm not an audio/dsp software arteeest (yet).. so take this with a grain of salt.. HOWEVER, you could always just download synthedit, download the module sdk, and start creating some modules... this way you get a feel for the 'reaktor' style of building along with the coding process as well.. just an idea.

-------------------


URS:

please include an orangutan plugin

[spaceman]

Yeah, C is way to go.

C++ is helpful (and a basic knowledge is needed to start with the various SDKs), but you won't need all of it.

You'll hardly ever need to write any assembly code.

Of course, you need a Development Environment. On MacOS X, this comes free. Just install Applications/Installs/DevelopmentTools.pkg

The first step would be, grab an open source synth from the net and check out how it works. Then, build a basic synth that emits a sine only, then breed it until it's what you need. Takes between 3 months and 3 years.

don't you need a heck of a lot of maths as well?
or is that just for the innovators?

[Urs]

don't you need a heck of a lot of maths as well?
or is that just for the innovators?

I don't know a shit about maths. Reading the dsp related papers is mostly an academic exercise for me that typically causes headaches.

What one needs is *ears* and a sense for logic. You gotta be able understand some concepts, even complex ones, but these hardly ever involve tough maths. Well, if calculating the frequency of an FFT bin is tough for you, okay, but once you get it, write it down in your own formula diary and you're done with this.

Others may think different, but for me maths isn't key to sound quality. That's why I call many of my algorithms DSP Crimes, because they contradict to "how it has to be done properly", as written in certain papers.

Also, I have got the impression that many hard-to-understand papers in fact cover very basic stuff. It often happens that you create a dsp algorithm by "common sense", as in: that looks like the logical way to do this, and years later you read a paper with a shitload of formulas describing what you did in 20 lines of code.

Nevertheless, there are *tons* of papers that feature quite some tough maths but are written with pragmatism in mind. These can be very enlighting when you take the time to translate the formulas into something your brain can cope with. One has to develop the skill to distinguish between "strictly academic" and "helpful" when scanning through the realm of theory.

But never ever trust maths more than your ears.

Cheers,

Urs