Simple additive monophonic synthesiser, based on two oscillators, a noise generator, volume and pitch ADSR envelopes and some basic filtering.
An exporter can convert Renoise songs to .h (C include files) that can be used in the stand-alone player, for intros, demos, games or anything that comes to mind.
This song is done using exclusively SorolletVoice’s and the stand-alone SorolletPlayer. No other samples or VST instruments or effects were used. No animals were harmed, either ;)
Downloads and source code
Things to do
- VSTi builds for Mac OS X and/or Windows
- A better (custom) GUI – not relying on the host’s provided GUI
- Probably remove the inbuilt filter, saturate and EQ units and move them to separate modular units (i.e. convert them into VST plug-ins and load them in Renoise too, as part of the effects chain)
- Simplify more the code so that it’s smaller (probably remove the dependencies on the CRT, but I’d like to do that in a clean, non-hackerish way)
- Look into SSE instructions in order to make certain calculations in parallel.
I don’t know when any of these things will be done. Of course you’ll be gladly welcome if you contribute with something.
This is an evolution of my first attempt at software-synth making. The first version was written back in 2008 for my 64k intro to_the_beat; it was programmed with pure C and the songs were semi-automatically imported from Impulse Tracker into a prepared template which contained the parameters for the synths. So creating a song was a painful process: I had to load similar sounding samples into Impulse Tracker and then compose the song that way, setting the parameter values in the template song.h file. It was horrible.
So I decided that if I ever did a new version, I would change things so that they were easier for me.
- Change to a C++ object oriented code style
- Have an interactive GUI for editing the synth parameters
The reason for changing to C++ was that I’m simply more used to working with classes and methods than with structs and functions. It just feels better calling object methods, rather than calling a function and passing it a pointer to an struct. So this change was slightly cosmetic.
But the biggest change –and the decision I’m most proud of having chosen– was creating a VST instrument. This fixed several shortcomings with my previous workflow: the lack of a real-time modifiable GUI (or in other words: sliders!!) and the tedious export process to convert a tracked song into something I could use on an intro or demo.
Now I can compose the full song from within Renoise, including changing synth parameters during the song –so for example the filter can have its low pass frequency changed with an envelope defined in an associated automation device–, and when I’m done and ready, I simply run a little python script which processes the song file and extracts the relevant data in order to use it on my own application.
The design is supersimple. There can be any number of voices –subject to your computers’ limits–, each like the following one:
These voices are then added together and returned via the SorolletPlayer’s getBuffer method, which is very similar to the SorolletVoice’s getBuffer method: both receive two output buffers (one for the left and one for the right channel), and a number of samples to be returned. This is different to the usual style of returning interleaved samples (like for example when outputting audio through SDL), but I’m doing it this way because that’s how VSTi works, and it’s easier to work like this all the way and just interleave things together if the data is requested by an SDL-based application.
Incidentally, I have also begun to use Scons instead of Makefile with this project. I had tried CMake a couple of years ago but it didn’t fully convince me. And although I still don’t totally get Scons, I like the fact that it’s python, so I know the syntax already. Besides, it’s very DRY, which is a total opposite to my latest Makefiles, so I love that.
Just look at the Sconstruct file and compare it with any other Makefile. This is super-awesome:
core = Glob('./core/*.cpp') + ['sys/MathUtils.cpp']
player = Glob('./player/*.cpp')
### VSTi ###
libenv = Environment()
vsti = libenv.SharedLibrary(
core + Glob('./vsti/*.cpp') + ['./libs/vst-sdk/public.sdk/source/vst2.x/audioeffect.cpp', './libs/vst-sdk/public.sdk/source/vst2.x/audioeffectx.cpp'],
CPPPATH = '#/libs/vst-sdk', CCFLAGS='-m32 -lstdc++', LINKFLAGS='-m32 -lstdc++'
### Stand-alone player ###
player = Program(
core + player,
Even if you have never seen an Sconstruct file before you can already grasp an idea of the purpose of the above script. Just look at that: core + player for specifying list of files to be built. It can’t get more elegant.
Another reason for using Scons is being able to build for several systems without writing a different Makefile for each one of them. And without having to use nasty stuff such as XCode or Visual Studio. That’s always a good reason for switching to anything!
I aimed to build a demo for Breakpoint 2010 using this new synth and system, but ran out of time. However I still believe this is the intelligent way to go for highly accurate and synchronized visuals and I intend to pursue this path further, although I can’t give a date for the next release :-)
You can read about the process in this series of posts:
- Breakpoint demolog, days 1-7
- Breakpoint demolog, day 8
- Breakpoint demolog, day 9
- Breakpoint demolog, day 10: deltaFrames and me
- Breakpoint demolog, day 11: Envelopes!
- Breakpoint demolog, days 12 and 13: more envelopes
- Breakpoint demolog, day 14: BASS… drum!
- Breakpoint demolog, day 15: filters
- Breakpoint demolog, day 16: saturate & EQ
- Breakpoint demolog, day 17: building for windows (from linux)
- Breakpoint demolog, day 18: loading the Song.xml
- Breakpoint demolog, day 19: loading Song.xml == DONE
- Breakpoint demolog, day 20: design sketches
- Breakpoint demolog, day 21: instantiating patterns
- Breakpoint demolog, day 22: voices, parameters…
- Breakpoint demolog, day 23: rough player
- Breakpoint demolog, day 24: going backwards X-(
- Breakpoint demolog, day 25: eventList
- Breakpoint demolog, days 26-28: busy with something else
- Breakpoint demolog, days 29-30: back to the insidious bug
- Breakpoint demolog, day 31: the culprit has been identified and reduced
- Breakpoint demolog, days 32-33: moving to Windows
- Breakpoint demolog, day 34: VSTi+Renoise working again
- Breakpoint demolog, day 35: some pattern dynamics
- Breakpoint demolog, day 36: plane meditation
- Breakpoint demolog, day 37: device automation goodness
- Breakpoint demolog, days 38-50: change of plans
- Breakpoint demolog, days 51-55: fixing framework bugs, and composing a song too
- Breakpoint demolog, days 56-57: wrapping up