Sunday, December 15, 2013

Dexed; DX7 software plugin emulator

I've bought NI FM7 and then FM8 but it never sounded like the original DX7.  Back then, the closest "real" implementation (to my opinion) was the Nord G2 (; and it required a Nord G2 device. Then came this project and SynprezFM that actually worked on the DX envelopes and stuff... To me as a musician, I needed a real plugin version to work and load it with a DAW.

This is why I made it a "port" that uses JUCE as a host plugin format with (music-synthesizer-for-android) code base...

Call this as a "Sprint 1".

Monday, November 11, 2013

M4L: Ruban 1.0

The first time I played with Max/MSP (it was version 4.5 if I remember right), I was hooked on groove~ with the wave display: it was instantaneous and I didn't feel carved into the walls of one single .wav file or tuning half of the buttons in Reaktor to get something fun. I have nothing against Kontakt, it is a wonderful engine, sounds great but every time I play with it, I feel like I'm writing code in Word processor with a very low resolution. Yes, it has a GUI, but on Kontakt, I get the same feeling of menu/menu/command/menu/menu like a real sampler. You need to modify a voice; save file, open wave editor, do your things, resave file, reopen Kontakt. -1 for the workflow.... And yes, there is editing feature to "edit" directly the sample in Kontakt but half of the time the mouse click does nothing, since I didn't select the right options.

All of this got me on thinking the simplicity of the original wave display on max/msp. I wanted to make a device like that. And to simplify the workflow, it is using one very large buffer (one wave file) that contains all the sounds we need to play. You can cut/copy/paste any part of the large buffer. Later, you can assign 16 different loop point within that buffer. The name of 'ruban' is the french word for 'tape'. The analogy is to be able to embolden part manipulation without having to treat each parts as single wave file.

It has 16 active slices or zones that are triggered via midi note 36 to 51. Each zone have their one envelope, pan and sample speed. If you drag a .wav of .aiff file into the "wave display", the content of this wave file will be copied into the device clipboard. And no, this clipboard is not available outside the application, I'm still trying to find a working piece of code that can read .wav file via the system windows/os x clipboard.

Special functions are also available to modify the buffer or change the borders of the zone :

"gain" : multiply the sample amplitude by an ask value

"sprout" : copies the beginning of a zone by an ask value

"slice" : create 16 equals zone within the buffer

"slicetempo" : places the end of the zone by an ask value in bars; 1 = 1 bar

"pastemix" : paste the content of the clipboard by mixing with the content of the buffer

"delete" : reset zone content to 0

This Max max for Live device requires Java (for buffer edition)

Source file :

Sunday, June 2, 2013

First Glasgow release

Generating music straight from a computer language has always been very fascinating for me. Off course, the code will never replace the composer, but it becomes a very interesting tool if it is used at the right place. There is a lot of offering and some very cool implementations like :
  • AC Toolbox - cool old school LISP tool.
  • noatikl - complete all in one solution. Impressive demo.
  • mxdublin - this one is my latest (2008) experiment. Too complex and heavy. It is dead.
By using those tools and even designing one, I have learn some implementation lessons :
  • The tool should not be a sequencer. In this implementation, the sequencer is Ableton Live and it does a great job. Once the notes are generated, the tool is not required to "play" the song, it is only use to change the live clips. This technique is used to have a minimal impact on the existing composition workflow.
  • The tool should only be used to generate notes and ctrl events; no raw midi events. Midi channel and routing should be programmable by the sequencer/host it self.
  • Time is always relative to the sequencer speed; nothing gets calculated in milliseconds. 0.25 means one quarter note (1/4). 1 means four quarter notes (4/4) or a whole note.
  • The event stream of data should not be encapsulated in a complex object. A event stream in Glasgow should be a simple array and this array should only contains the data of a simple Live clip.

    [ [ 0, 64, 127, 0.25 ], [ 0, 66, 127, 0.25 ] ]

    Events with 4 elements are notes (time, note, velocity, duration). Glasgow API helps you write those type of arrays but if you don't like them, you can make your own API that outputs this type of data. Events with 3 elements (time, midicc, value) could support midi controller change but the M4L API doesn't support that. I am thinking of opening a ticket at Cycling '74 for that.
  • The API should be adaptive based on the type of data. If it is a string, try to parse it into a list. If it is a list, create an iterator based on this list. If it is already an iterator, use it to create the events. Don't create different API for each data type, this is Javascript, let the API adapt it self to the data that is passed.
So this is Glasgow 0.1; it is a Max For Live plugin that enable to write (and get) the content of midi clips by Javascript code. download

And by Javascript code, I mean this :

// this generates a beat (mapped to a bassdrum, snare, hihat)
[ mkp( "0:1", "C-3" ),
mkp( "0:2:2.2:-4", "D-3"),
mkp( "0:0.5:0.3/4", "A#4") ]

This is a work in progress. I will add the chord generation within the next version.