Monday, 27 May 2013

What's new in Text to Music?

My very first blog post, a long time before the rest, was on the subject of my favourite side-project, Text-to-Music and what I'd done with it. Well, that was over a year ago now and I've started showing it off at conferences since then. Turns out developers love to tweet and see/hear the result.

Well, since then I've tried to develop it past a system which can only read tweets, after all, it's a pretty re-usable algorithm. Also highly hackable, as it's easy to plug in other sources of text, and to take substitute the existing Pure Data patch for another sound generator (provided it can read a TCP port).

For those of you who don't know, Text-to-Music is a ruby patch which reads a string of text, character by character and then sends a message to pure data to sonify it with these rules:

  • Letters are notes one semitone apart, alphabetically.
  • Upper-case letters are one octave above their lower-case counterparts 
  • Numbers are three semitones apart (describing a diminished scale)
Punctuation is a selection of special cases which follow no particular rules.

For over a year now, the repo has included scripts to get text sources from:
  • Manually typing them in
  • Text files
  • RSS feeds
  • Tweets
I have prototyped a system for creating and queueing messages for Text-to-Music from within Ruby on Rails, a plugin I named acts_as_singable, however there were problems in getting this into production. Not the least of these is that I don't know anyone who could use a real-time sonification of something from a rails website in real-time. 

Anyway, for any developers reading this I can announce a potentially quite useful feature (which is a first for TTM). Yesterday I added two new scripts to sonify GitHub commits. 

This means that for open repositories, you can review the last twenty commit messages as a sound. Which is fun, but not very useful. If you need to review these, you might find it easier to do so at your own pace rather than waiting for the typewriter effect to take place. 

However, you can also monitor a github repository in real time, and hear commits as they come in. This is potentially quite helpful because you can hear a colleagues commit and ignore it, keeping your eyes on your work while being aware of the traffic on your repo. 

I've also learned, after using TTM quite a bit, that you can learn to recognise certain words which are used a lot, so you could get an idea of what part of the project is being worked on and the kinds of things being fixed. Merge messages which tell you the conflicting file paths have a lot of forward slashes, which are easy to recognise. So you could tell when conflicted merges are happening. 


It's still a 'nice concept' idea, in reality, but it's creeping closer to becoming a helpful aural notification system. If you're using Mac or Linux feel free to try it out, get the code from https://github.com/ajfaraday/text-to-music and let me know what you think on twitter: @MarmiteJunction 

Tuesday, 21 May 2013

Music Tech Fest

So, I was busy this weekend, spending my time at something descriptively named Music Tech Fest. It's a three-day event now in it's second year at Ravensbourne university (practically in the shadow of the Millennium Dome).

It was a meetup with some fantastic musicians, music hackers (in this case, programmers) and journalists, as well as people from the music and app development business. Talks from many of the same, and somewhere amongst it all, yours truly.

Actually, music tech fest is the source of what has to be my favourite picture of myself from a conference EVER!


The fact that this picture exists hints to the fact that this free event was also streamed live across the web, meaning that even if you couldn't get there, you could have tuned in and taken in some of the sounds and ideas that were flying around on stage there.

The talks included topics such as Music for Social Change, various music, social and video apps, and a cocktail making robot, along with music from acts as diverse as Meta-Ex, Shlomo and Ezra of the Bionic Orchestra. Plus the results of a two-day music hackathon which had been happening at the same  time (where clearly a lot of creative ideas were being bandied about).

There was also some brilliant sound installations, including my personal favourite, the musical typewriter by Xiaofei Dyson...


I'll let you guess what happened here.

It had all the classic hallmarks of a fantastic conference and/or festival (I'm genuinely not sure which it was), namely that I'm still tired two days later and have a lot of ideas floating around in my mind, just waiting to get out.

Nice job, Music Tech Fest!

Sequencing and wavetables, part 1: Arrays in Pure Data

So, programmers will know that an array is a list containing pieces of data, referenced numerically. I can tell you that in pure data, it's a list of numbers, which is expressed visually as a graph.

As described in Pure Data and BACON: Part 1, you can create one with Put > Array and define it's length (number of items), size on screen and the numbers it represents by right clicking it and selecting Properties. You can set the actual numbers with a message (connected to nothing) starting with a semicolon, it's name, the first index (usually zero) and then a list of numbers. Finally, you can select numbers from your array with tabread, feeding it the position of the number you want to pull out of your array.

Well, that was a short blog post...






Okay, once again, I can't leave it there without showing you how to make something cool, and for a change I'm beginning to write this without being entirely sure where it's going to finish. So lets start with our basic, start of post patch...

Step 1: How to count upwards, the easy way.



Okay, so what's happening here? Firstly, I've introduced a new object here, f, short for float. Now a float (or, to give it it's real name, Floating Point Variable) keeps hold of a number, and when it receives a bang (the activation message which is generated by metro), it outputs it's number. The right inlet will set the number it's holding, without it being output.

The practical upshot of this is that when we send our float out to + 1, and then back into the right inlet, the number it's holding increases (or increments) by 1. So every time the metro fires, it will move our number upwards, in this case every half second.

Now, you'll also notice this doesn't make any sound yet, and it will, but this would make an awful musical sequence because it would just keep increasing, go beyond human hearing and then back to human hearing via a digital side-effect called foldover (I won't to in to this now, but it's not a terribly desirable sound). Instead we're going to muzzle the numbers this is creating with something called modulus...

Step 2: Make it loop


Modulus is nothing to be scared of! A fact I didn't realise in my early days of Pure Data coding. Modulus (represented here by a percent sign, %) is the remainder after your number is divided by that amount. So here every multiple of 8 will return zero, followed by 1, 2, 3 etc. until it reaches 7, at which point the number will be a multiple of 8 again, and it returns 0.

The practical upshot of this is that you've now got a number which cycles from 0 to 7, providing 8 specific numbers.

So now we can make ourselves some sound...

Step 3: A very simple sequence



I've modified our counter, for a start, it's now one fifth of a second, and counting up to 16. Then, just like my typically starting patch, I've added sixty (to put us in the middle of the range for midi notes), converted this from midi to frequency using mtof, fed that to an oscillator then out to the sound card via dac~.

Do take note that you could write a version of this patch with any of the Algorithms of the Street in place of that osc~, but I'm keeping it simple here.

Now you'll hear a maddening pattern increasing by a semitone (known in music as a chromatic scale), you may want to mute the sound as you start building the next part of the patch.

Step 4: Time to add an array.



So, I created an array, and set it's Properties like so...


So it's got 16 members, and they range from 0 to 24 (at least within the box, you can set numbers outside this range if you want). The I wrote the message to start at index 0 and put that list of numbers in the array. That's a fairly listenable melody based on a minor scale, but you could have any list of numbers here and you will hear the changes in the melody, but I recommend you keep it between 0 and 24.

Actually, I had to sit here writing out the notes of a minor scale in terms of their relationship to the root, in semitones, then write this melody using notes from that list. But we're programming here, and I shouldn't have to sit here choosing from members of a list, I can get Pd to do that for me, so here comes another array.

Step 5: A second array, a scale.



Wait a second, I hear you cry, what second array? I can only see one.

Well, the object 'table' is an array, hidden away. Because we don't need to worry about it's visible dimensions, we don't need to set up any attributes, and a scale looks fairly dull anyway (it's just a line upwards, we can't learn anything from the shape of it) we don't really need it taking up space on screen.

The sequence array, however, shows us the shape of our melody (I've changed it's vertical range to 0 to 14, to match the 15 members of our scale array. So the output of our sequence, instead of being semitones apart, are members of a minor scale apart. This may not mean much to you, but it means the notes we're hearing go together much better.

We can also draw our melody, instead of writing out the number of each note by hand. If you're out of edit mode you can click on one of the points on your sequence array and drag it around, and it's neighbours. There's just one thing we need to do...

Step 6: Drawing a melody



Can you spot the difference?

Well, I've drawn a new shape in my sequence array, and moved the table, scale, out of the way. But importantly I've added an i between my two tabreads. This is an integer or whole number box, mostly what it does is, whatever number is fed into it, it only outputs whole numbers, meaning anything that comes out of our sequence, it will only give the right values to get a member of our scale array.

This is fun in itself, true, but I've only put six steps in this tutorial, and my Pd tutorials always have seven steps, or a seven with a sneaky extra step. So lets look at what we could take more control of here...

  • The plus before mtof could move the whole sequence up or down without changing it (known as transposition)
  • We don't have to use all 16 steps of our sequence all the time, we could change our modulus to define a different sequence size.
  • The speed doesn't have to be constant, either, we can vary that pretty easily.
So, what does a patch varying these three things, as well as the sequence itself, look like?


Step 7: Taking control!

There it is, control at every possible point (although we could expand this patch a lot, some kind of array-based sequencer could be a part of just about every patch we've made so far). I've added simple number boxes (ctrl + 3) for transposition and speed and commented them, there's really no explanation needed here if you've been following so far and know what they do.

I've also introduced a new UI element, the line of boxes labelled sequence size, known as a radio (Puts, Hradio). This is simply a method of choosing one of a list of consecutive values (from 0 to one less than the size you give it, under the right click > properties dialogue, this one has 16). We've added an offset of 1 (+ 1) to make this a bit more useful and feeding it into the modulus box, this decides how far through the sequence array it will read through before restarting. So if you click near the left hand side of it, like me, you'll only get a short slice of your sequence, to the right... all of it.

So that's it, have fun playing around with your simple sequencer.

As ever, feel free to get in touch (@MarmiteJunciton) to let me know how you found it, if you had any problems putting it together, or if you just want to talk tech, music or pizza.

Thanks for reading and God bless

Andrew


Wednesday, 15 May 2013

Algorithms of the street - Part 2: Amplitude Modulation

So, I've already shown you Frequency Modulation (FM) in pure data, it's an algorithm, or recipe for Pure Data, meaning you can use it in other contexts, change some parameters to vary your sound and if you're really lucky, reading Algorithms of the Street - Part 1: Frequency Modulation will have told you exactly what FM is.

Given that you might well have read that post by now (if not, I would recommend you do) you'll have noticed that there's some similarity between the title of that post and this one. The fact that there's only one word and one number different, perhaps?

As the name suggests, Amplitude Modulation is a lot like Frequency Modulation. Only instead of modulating (changing, in a regular way) the pitch, or frequency of our tone, it modulates the volume (amplitude).

If you've read the FM tutorial, some of this will sound quite familiar. If you're feeling confident you could always skip to the end of this one and see if you can see the difference in the patch.

Step 1: No Modulation Yet



Once again, I've used a version of the generative patch from Pure Data and BACON (Part 2) as a starting point. Clicking the toggle at the top there will start a random stream of numbers, converting to frequencies and creating a random, continuous melody. But the tone being used is fairly dull, a simple sine-wave. It's hard to listen to for a long time, and we can take a lot more control of this tone.

Step 2: Modulate the amplitude



First, notice that I added a frequency within the oscillator box, and cut the wire connecting it to our random melody generator. Secondly you'll notice that I've added another audio multitiply (*~) and a second oscillator, which is only working at one hertz, a single cycle every second.

Your ears will be telling you, at this stage, that the sound is fading in and out with a regular pattern, on the same note. This is the simplest form of AM, with an oscillator going very slowly (a Low Frequency Oscillator or LFO) and no extra control.

So what's going on here? Let's look at some 'known facts' I've mentioned in earlier blog posts:

  • Digital audio is a high-speed stream of numbers which are converted to control signals for a speaker or speakers
  • These numbers range from 1 to -1
  • An oscillator in Pd outputs this same range, 1 to -1
  • Because they're numbers, they follow the same multiplication rules as numbers:
    • If you multiply it by 1, it is unchanged
    • If you multiply it by 0, the result is 0
  • Sine waves (which are also the output of osc~), plotted on a graph, are this shape.

We're multiplying a tone (called the carrier) by a much slower tone, which is changing it in some way, and so is called the modulator. So the volume starts at 0, silent, increases, arcs through it's maximum value, then back down below zero? 

Once again, we can rely on the multiplication rules from the world of maths here. If you multiply a number by -1, the result is the same, but on the other side of zero. So what we're actually doing here is turning our sine wave upside down, then producing the same volume arc as before. Although we can't tell the difference because it's shape is unchanged, we just hear the a repeated volume arc.

So effectively, the amplitude modulation we're hearing is more this shape:


Also, because we're hearing both the up and down parts of the modulating sine wave as an increase in volume, we're hearing this pattern twice a second, instead of once. 

Step 3: Bringing it up to speed

Phew, that was easy.

Okay, so we've increased the frequency of our modulator to half that of the tone itself. We're hearing a thicker, more interesting sound. But why?

Well, as I discussed in Pure Data and BACON (Part 1), the human ear can only recognise around 30 separate sounds in each second. When sounds are more regular than that (have a higher frequency), we hear a continuous sound instead of separate events. So our modulation is now part of a complex tone, instead of making the volume lurch, you can't hear the process as it happens, only that the tone sounds different. 

So... With this algorithm in place, we can just add our melody generator back in, right?

Step 4: The Fly in the Ointment


It seems such a simple idea, we add melody to a tone generator, and we get a melody produced in that tone. 

Our ears, however, tell us that it's not at all like a clear melody. Just like this step in my Frequency Modulation tutorial, we've exposed a weakness in our modulation algorithm. The frequency of the carrier changes but the modulation frequency (literally, the frequency of our modulating oscillator) doesn't.

Unlike FM, however, there's an additional problem. Once again, the world of maths tells us that multiplication can be changed around and the result doesn't change (2 x 4 is exactly the same as 4 x 2, and so forth). Because of this, it's not at all clear in our algorithm which is the carrier and which is the modulator, they act on each other in exactly the same way.

So the rather unpleasant sound we're hearing now is two tones competing with each other to become the note you're actually hearing, and they clash. 

There is a solution, however...

Step 5: Control the depth and use a proportion


Okay, the first thing you'll probably have noticed here does nothing to the sound. I've added a couple of comments (ctrl + 5), to tell you which oscillator is the modulator, and which is the carrier. These literally do nothing at all except say something on-screen. Don't believe me? Right-click on one and check it's help patch.

More importantly, I've added another multiply below the modulator, which means it will only change it's volume from 0.5 to -0.5, having half the effect (which we call the modulation depth). Also (as a side-effect) reducing the volume of our sound by half. 

The most important thing here, however, is the multiply above the modulator. This means that whatever frequency of the carrier, the modulator will be at half of that. They are changing frequency in synchrony, so you can hear what is effectively one tone, changing it's pitch, as opposed to two warring frequencies. 

This will produce something like an organ tone, this specific ratio reminds me of the music from the classic game, columns. Happy memories.

We can vary the tone it'self by changing the modulation frequency and depth, just as we did in the FM tutorial. However, before we start playing around, there's a problem we must take care of...

The modulation depth typically just controls how much effect the modulator is having, but here it's also vastly changing the volume of the resulting tone. The best way to do this is by adding an offset to keep the modulating tone from crossing zero.

Step 6: An offset to solve the depth issue


Again, the most noticeable thing here is not what I'm trying to show you, I've changed out the numbers in the multiplies above and below the modulator. These are set to range from 0 to 1 and control the modulation frequency and depth, respectively.

Below the lower of those, however, I'v done something unusual. Two pieces of fixed arithmetic on our modulator frequency. So:

  • Adding 1 (with +~) changes the range from 0 to 2
  • Multiplying by a half changes it to 0 to 1
This means that while changing the depth will affect your volume, a depth of 0 does not mean a volume of 0. It means a volume of 0.5, and a depth of 1 means a changing volume that centres around 0.5. This also means that we no longer have the arcing waveform of earlier. The graph of our modulation volume now looks like this:

Notice how it's all above that centre point (zero). 

Step 7: Two things to control? Use a grid


The first thing you'll notice here, is that I've added a grid (to create your own make an object (ctrl + 1) and type the word 'grid' into it), I've also set the properties like so (to get to the properties dialogue, right click and select properties).

I made it big with the Height and Width fields, then set the range of both axes to 0 to 1 with a small step size. 

I've then taken the output of the grid to two sends, mod_frequency and mod_depth, and replaced the two sliders with the corresponding receives. 

Hey presto, we're generating a melody and changing the sound of an AM tone generator with a dot on a grid. 






Secret extra step: shhh, don't tell

Okay, so there's tutorials for both AM and FM synthesis here on the blog and I've stressed that these are re-usable algorithms, and once you understand them you can swap them out for oscillators in other places. The inquisitive mind is now probably thinking "does that mean I can make a synthesizer with both frequency modulation and amplitude modulation?" 

Of course you can, if you've read both posts you'll know all the parts of this, so I'll just whip up an AM/FM synth patch...


Well, there you have it, I've assumed an FM modulation depth of 0.5 and an AM depth of 1 (you don't need any objects to multiply by 1, I removed that one entirely). 

You can probably work out what each part of this is doing, so you can now have a play with the grid, as in both individual cases, when the frequency is low, you get a thick, heavy kind of sound, and when it's high it's richer, more bell-like. But this effect is compounded by two modulation frequencies. 

Near the bottom left of the grid, when both are low the sound can be heavy, and you may even hear a regular rhythm in the modulation in the bottom left square. To the top right it's more rich and complex than you will have heard so far in this series of tutorials. 

It's starting to get more complex now, and I promise I will eventually get around to blogging about hiding bits of Pure Data patch away so you can concentrate elsewhere, but for now, everything's on show. 



Well, that's it for now. I hope this all made a reasonable amount of sense and enlightened you a little about Amplitude Modulation. 

Did you find this tutorial helpful? Get stuck anywhere? Don't know what on earth I'm blathering on about? Feel free to comment here or get in touch with me direct at @MarmiteJunction

 Thanks for reading, God bless.

Thursday, 9 May 2013

Algorithms of the Street - Part 1: Frequency Modulation

So far in my blog, it's all been sine waves. Mostly because this is easy to put down in a hurry, useful for live coding and allows me to focus on a different aspect of the patch I'm creating. All my tutorials so far have been recipes, and like all recipes you have to understand how it works before you start to change things, add extra ingredients, cook it at a different temperature, use a blender instead of a vegetable knife, and so on. (It seems I've started enacting this principal in by blog by adding bad cooking metaphors).

Anyway, I think it's high-time I started talking a little about how to make slightly more complex tones than just sine waves, so here's the first in a series of synthesis algorithms you can use in place of osc~ which will work in the same way, but sound different.

For the slightly less maths orientated amongst us (like me), an algorithm is a repeatable method of reaching a solution, or at least producing the same pattern. It's a mathematical method which will respond to different input and produce results accordingly. So in PureData terms, it's useful to learn some algorithms which you can then use time and again to produce similar, but different, results.

Step 1: The problem...



So this is a random melody patch, similar to one we made in an earlier post. It chooses random numbers between 60 and 84, converts those to frequencies then makes the osc~ produce that frequency and sends it out to the sound card (I suggest you build this patch before proceeding).

The problem is that a sine wave is a very simple waveform, with only one frequency, and it can become grating pretty quickly, especially if you're not hiding this effect by changing the pitch regularly. A patch like this:


will drive you nuts. You're in luck, however, because an oscillator isn't only controllable with numbers. You can also control it directly with anther audio signal.

Step 2: Modulate the frequency



So what's going on here? Well, the osc~ at the top of the chain is at a very low frequency, half of one herz, meaning it takes 2 seconds to complete it's cycle. Incidentally if you ever see a piece of technology with the term LFO written on it, this is all it is, a Low Frequency Oscillator.

Now, as I have explained before, an osc~ creates it's tone from an arbitrary 1 to -1 range. Meaning if we multiply it (with *~) by 20, this will move up to 20 and down to -20. If we then add (+~) 440, the result will range from 420 to 460. The result is that you can hear the slow waveform of the first oscillator changing the pitch of the second.

We call this higher oscillator the Modulator or Modulating Oscillator, because it is modulating (which simply means 'changing') the Frequency of the tone. Meaning we have achieved Frequency Modulation, or FM.

The practical result of this oscillator working at low speed and changing a very audible aspect of the sound is that we can actually hear the shape of it's wave or it's waveform, which looks like this.


So you'll hear that wavy, siren sound in the frequency of the resulting sound. And this is the exact same sound which, sped up, is the tone you're hearing it produced with. Just like the clicks in Pure Data and BACON (Part 1) the wave has a different effect when it happens less than 30 times a second, allowing you to hear individual events. 

It follows that by speeding up the modulator, we can hear a very different flavour of sound.

Step 3: Modulating at speed




All we've done here is change some numbers, but the modulator is running at a speed which you would be able to hear as a tone, which is also half of the pitch of the second oscillator. I've used half simply because it's quite a nice ratio to use. I've also changed the amount by which it's changing the frequency of the second oscillator, what we call the Modulation Depth. Because it changes how deeply the modulator modulates the tone. You're probably starting to get that these terms do actually say what they mean, once you understand the words being used.

The result is something like a kind of bell sound. It's still more or less at 440 herz, because it's revolving around that frequency, but it's more of an interesting sound. You can't hear the individual waves of your modulator any more, but they're changing or 'colouring' the sound of that first oscillator, which is still just producing a sine wave, it's just changing it's frequency at high speed.

So if that plus is the figure we're revolving around, does this mean we can feed that melody generator into the plus and hear a melody in our new bell tone?

Step 4: Bell + Melody = ?


If you had to predict what the above patch does, you'd probably assume that the melody generator feeding the centre frequency of your frequency modulation would play that melody with our FM tone.

But your ears won't be telling you quite that story, the effect  we're actually achieving is that each note sounds like it's being made with a different tone and they sound more or less out of tune. This is because the 'flavour' of an FM tone comes from the proportional relationship between the modulator frequency and the carrier (the carrier being the oscillator which isn't the modulator).

The reason the sound we're producing sounds so 'interesting' (which can be thoroughly euphemistic when talking about music), is because the modulation frequency isn't changing, but the carrier frequency is. So 220 hertz is a different proportion of 480 than it is of 440, or any other number. Each pitch has a different 'flavour' of FM, meaning your ear can't settle to hearing the centre frequency as the pitch, it keeps moving back towards the modulator frequency.

This isn't a problem when we're using it as an LFO, but when the modulation frequency would be audible as it's own tone it can really throw you off hearing this as music.

To combat this problem, we simply have to write our patch so that the modulation frequency is a set proportion of the carrier frequency...

Step 5: Proportional tones


Now, this patch hasn't changed very much, but the effect of it has. We've just added an extra multiply and a link to that from the same source as the carrier frequency. Meaning the modulation frequency is always half that of the carrier. The effect you get from your ears now is that each note produces the same kind of tone, it's like a kind of organ tone.

A little experimentation will show that if this multiply is set to any figure between 0 and 1 you get some interesting sounds (0.2 is a favourite proportion for me, it produces a nice thick tone). Armed with this information, you can start to take some more direct control. Time for some GUI elements

Step 6: Take control of your modulation


You'll notice something new here, a slider (Put > Vslider or Ctrl + Shift + V). It's easy enough to understand, it outputs a number based on you sliding the line through it up or down. To get a decent effect you'll have to change it's range by right clicking on it and selecting Properties.


This opens up a dialogue with properties of the slider. You just need to set it's output range from 0 to 1, like so:


Now when you move your slider up and down (when you're out of edit mode), it will change the proportion of your modulation frequency and give you a different kind of tone as you do. The melody is out of your control, but the tone is right within it.

There's only one other part of the algorithm you may want to change, the depth of the modulation. So, just for the fun of it, we're going to use a new GUI (Graphic User Interface) object called a grid...

Step 7: Two dimensional control with a grid



You may notice one big change on this patch, namely a great big blue grid to the right hand side of it. Create this grid by creating an object as ususal and typing the word 'grid', when you click off this object it will initialise to a grid just like the one above. Just like the slider you can right click it and select Properties, then I recommend setting the properties of your grid like this:


So in short, width and height decide how much space the grid will take on screen, the X min, X max and X step change the numbers that it will output when you move left to right on your grid and Y min, Y max and Y step do the same for movements up and down. The two outlets from the grid then output this information which we're sending (via named sends) to the two multiplies in our FM algorithm.

The result is that when you leave edit mode and click on your grid, you can drag the pointer around and change both the frequency proportion and the depth of your fm synthesizer. Towards the top you will hear deeper or more severe modulation, and lower down the change will be more subtle.

Towards the left you'll hear thicker sounds, and right at the left hand side you'll hear some slow wobbles, until the modulation reaches 0 and you hear no sound at all. As you move right on your grid, you'll hear richer, bell-like tones.

Now you've made this synth, explore the sounds you can make, you may as well. See if you can produce a tone resembling a synth you've heard on a record, or in some classic sci-fi, the tones are there if you look hard enough.


The fact that this is an algorithm means it's re-usable in other contexts, anywhere you use an oscillator to produce a frequency, you could use two oscillators coupled to produce frequency modulation.

The inquisitive mind will now be thinking, "I'm seeing two oscillators here... does that mean I could replace them with FM within my FM?". The answer is yes! You can make multi-layered frequency modulation, use another oscillator as an LFO to change the frequency proportion or depth, the possibilities are literally endless. You now know the recipe, so why not play around with it?

I'd be interested to see what creative variations on FM you can come up with, and help you through any problems you run into in the process. As ever you can get hold of me any time on @MarmiteJunction.

Until next time, with more synthesis algorithms, good bye, and God bless.


Appendix: Doing it right

Reading this back two days after it's publication, I've realised that I made two mistakes in the final version of the patch, namely:


  • Crossing wires in Pure Data is bad form, while it's usually possible to tell where they're going because they're all straight lines, it gets very messy very quickly and that's where untidy, indecipherable Pd patches come from.
  • The modulation depth was a fixed figure, where we can make the sound more consistent again by making the depth a proportion of the pitch as well...
So, with both axes of the grid set to range from 0 to 1 (with small increments) an extra send for the pitch and a multiply for the pitch by the depth added, here's my improved version...