Audio gubbins and other such stuff
Variety of Sound have just brought out BaxterEQ, a new shelving EQ promising transparent mastering and mix buss shelving. However, they are running out of bandwidth for hosting it with, so for the time being I have offered to mirror it here – Download for Win32 VST
Csound is possibly the most powerful sofware synth around, however, it is not exactly the most intuitive program for realtime use. Sure, you can use it set it up so that you can control it through its ctrl7 opcodes using MIDI CC messages or even use its FLTK widgets to create a user interface but it is time consuming and detracts from making music.
Performing electronic music live is an area where Sensomusic’s Usine really excels though. Usine is a modular audio envirnoment specifically designed for realtime use. It is fully moulti-touch enabled, supports the OpenSoundProtocol and even lets you create your own GUIs quickly and easily. Now if only it was possible to use something like this to control Csound.
Well actually it is 
Csound can easily be embedded into other software using its API and Usine allows the creation of user modules using the C++ programming language so I just couldn’t resist combining them. This gives the best of both worlds – Usine’s live performance orientated features with the power of Csound for creating music.
I will be writing an article for the Csound journal explaining a bit more about how it all works together but in the meantime, here is a video demonstration kindly filmed by nay-seven.
So it seems that oversampling is the cool thing to do at the moment, what with Cytomic adding x256 oversampling to their compressor ‘The Glue’ and 2CAudio offering oversampling in their reverb Aether.
I can see the point of oversampling a compressor as it is performing amplitude modulation, so there is the potential for aliasing to occur (even if x256 is a bit excessive) but I never would have considered there being much point oversampling a reverb, since they are generally linear time-invariant systems. I suppose it would alter the frequency response of any filters within the reverb system and potentially improve any noise produced by interpolation of the fractional delays but that’s about it?
Anyway, I decided to join the oversampling arms race and add it to a special version of my reverb MVerb. Whenever it detects the VST host rendering it will now oversample the reverb x16 so if you runnning at a samplerate of 44100Hz MVerb will actually be at 705600Hz!
Have a listen and see what you think, is it worthwhile oversampling a reverb or a waste of CPU and memory, let me know…
MVerb is now available for Linux in VST and LADPSA formats thanks to ccern and lubomir.ivanov, who have kindly ported it using axonlib.
Another little update for MVerb
This time I have added a GUI using graphics kindly provided by Eric at Novaflash.
I have also inverted MVerb’s damping parameter so that increasing the control increases the damping and so reduce the frequency content of the echoes as this seems a more natural way of doing things. Watch out though as this may change the sound very slightly in saved projects.
Blurk has very kindly ported MVerb to OS X
There are a couple of different OS X versions: a VST version (universal, for Tiger and higher) and an AU version (universal, Leopard and higher) using Magnus Lidström’s Symbiosis library.
Thanks Blurk!
Digital reverb has always been something of a dark art as there is very little information publicly available and most of the big companies releasing reverbs are very vague about the techniques they use. The only real example is Freeverb so I though I would share some code for a reverb that sounds pretty nice and is very low on CPU usage. It is based on the figure-of-eight reverb structure suggested by Dattarro, which uses a bank of allpass filters to smear the phase followed by a loop of multi tap delay lines that feedback into themselves to create echoes. I have also added another delay and a mutitap delay to act as predelay and early reflections. The early reflections still need a bit of tweaking but they do the job for the moment.
The code is written in C++ and is available under the GPL license. It is really simple to use as it is all contained in one header file and should be cross-platform. There is also an example showing how to use it in a VST plugin.
Let me know if you find any bugs
For those of you wondering what happened to Duet, my automatic double-tracking/harmonizer effect, it is now available exclusively with Computer Music Magazine with the current issue (151).
By independently pitch-shifting the left and right inputs, Duet allows audio pitch to be manipulated in real-time, while still maintaining the time duration. By also delaying the re-pitched audio and altering its pan position, Duet can accurately create the illusion of multiple voices and add a luscious texture to your music.
This allows you to enhance vocals and instruments, such as guitars, by thickening the sound and adding a rich glossy sheen to your music. Happy harmonizing
A few people have contacted me recently asking how I actually use Nasir live and it’s all done with Plogue Bidule. All my MIDI is generated in Nasir and then routed to Bidule via MIDI Yoke where it gets sent to different groups I have set up for drums, bass, lead and pads etc.
Each group filters the MIDI so that it only receives information on specific channels and then passes it to a MIDI switcher with multiple VSTs attached. For example, in the drum group below I have eight instances of Microtonic attached to the switcher, which each have different presets loaded. I can then control which instance is being used by sending MIDI program change messages on the appropriate channel from Nasir to flick the MIDI switcher’s output to the different copies of Microtonic. The MIDI switcher can also be set up to control the bypass mode of each VST attached so only the copy receiving the MIDI actually does any processing so I can hook up as many VSTs as I want without wasting any CPU.
The audio out from each group then passes to its own effects group that contains a number of separate effect chains. Different effect chains are again selected by sending MIDI program change messages from Nasir to an audio switcher. As with the MIDI switcher, only the audio switcher’s outputs that are selected are being processed, everything else is automatically bypassed to save CPU. This allows me to have lots of complicated effect chains set up and flip between them live. Bidule can also use fade windows to smooth the transition from one effect chain to another. The first output of every audio switcher is always the dry output so when things start getting wild I can easily flip the effects back off.
All the individual effects groups then feed into one master group that again contains a audio switcher with lots of effects chains connected to it for applying to all the different instruments simultaneously. This all then goes into a brickwall limiter to prevent any clipping occuring and also to protect whatever speakers or P.A system Bidule is connected to. Since everything is created live and uses lots of effects and randomization anything could happen and I wouldn’t want to deafen anybody or blow speakers up!!
So after trial and error with pretty much every host going I am really pleased with Bidule for live use. Once Nasir is up and running I don’t have to flick back to Bidule at all, I can switch between VSTs and effect chains all by sending MIDI messages from Nasir. Also, by using the switchers to bypass unused VSTs I can keep CPU usage right down where the audio will never glitch when playing live with my laptop.
Bidule and Nasir make the perfect live combination!
I thought I would have a quick look at how good a few different C++ compilers were at optimising my code and it turns out Microsoft are better than I gave them credit for. I compiled the same VST plugin using as many optimisations as possible and monitored the CPU usage in Plogue Bidule. I then averaged the number of cycles used of ten measurements in Christian Budde’s VST analyzer.
MinGW using G++ 3.4 = 11.53% (77517 cycles)
MINGW using G++ 4.40 = 11.90% (79222 cycles)
Visual C++ 2008 Express = 6.65% (38521 cycles)
Admittedly it’s nothing too scientific but Microsoft certainly know what they are doing with compilers, its just a shame that that the Visual Studio IDE is getting slower with each version. I was surprised how slow G++ was in Windows in comparison and also that there was no performance gain going from version 3.4 to 4.4 However, G++ has the big advantage that it’s also cross-platform so although the code itself may be slightly slower, using G++ makes it a lot faster to get the code up and running on Windows, Linux and OSX.