Koodihommia

Virtually all of the audio plugin development is done in low-level languages like C++ to keep the illusion of real-time as close to being true as possible. Recently though, ROLI released a new programming language for audio processing. It's called  SOUL , a less convoluted way of designing audio processing software. I took a look at it and in no time, created this simple detuned sinewave synth. Sure, it is pretty much based on the examples but it took only a couple of hours to implement. If I would have done this in C++, a week would not have been enough. SOUL provides abstractions for inputs and outputs, lots of ready-made functions for waveforms, phases, and time-to-frequency domain conversions. It's pretty new though and examples, editor support, and proper documentation is still lacking. I plan to keep an eye on the development and will return with some more demanding audio processing later on.  You can try the example on the browser by copy-pasting it to the browser play...

Back in the day, everyone was using Winamp. It is a music player with the user interface of a mixing console. The bloody thing had an equalizer on the front page! As an amateur music producer, I know that EQ is a powerful tool but making changes that sound good is difficult, to say the least. Mixing engineers spend considerable effort with the artist to balance the frequency ranges to arrive at the desired musical outcome. I bet the 15-year-old me butchered a lot of songs with the thing. Now we are using Spotify, a player with basically a search bar and a play button. I ran into something called Ousterhout's Law on the  Operating Systems: Three Easy Pieces book . Here is a quote from the book TIP: AVOID VOO-DOO CONSTANTS (OUSTERHOUT’S LAW) Avoiding voo-doo constants is a good idea whenever possible. Unfortunately, as in the example above, it is often difficult. One could try to make the system learn a good value, but that too is not straightforward. The frequent result: a configura...

The previous blog post about the memory structure left me thinking about where the memory is allocated. Why did one of the variables stay in the stack and one go to the heap?  I stumbled upon this wonderful presentation on the very subject. Turns out that the go compiler can tell me where the variables are allocated. You just need to give it a couple of GC flags. Let's take another look at the example program I used in the blog post. Looks like everything escapes to the heap when building with my mac! It most likely has something to do with the println() debug command taking a interface as its argument instead of a known type. Source: https://www.youtube.com/watch?v=ZMZpH4yT7M0