So I’m going to be starting a new job soon and one of the many things I’m looking forward to is never having to write PHP again. I want to make a conscious effort to remove it from my life and that means Wordpress is going to go.

Now, I know that PHP isn’t quite as bad as some people make out, it’s certainly got its flaws and can be a bit of a pig sometimes, but if you don’t do anything stupid or obtuse then it does the job and does it without too many problems. My reason for moving is just that I want to put it totally behing me. There’s plenty of much more interesting, powerful and fun things I could be doing, and if I want to learn more about them then starting fresh feels like the best way to go about it.

So, what are these new shiny things I want to play with. The short answer is Scala. It’s one of the languages I’ll be using in my new job and it looks pretty cool. The longer answer is Scalatra, Jetty, MongoDB and a host of other web tech which I’ll be using to rewrite this blog from the ground up.

Keep watching I guess

Currently sitting in a swanky office near Camden waiting for a lecture on Go to start. Language, not the game. Let’s see what this holds.

Reteaching myself C has been a pretty good exercise and, for the most part, has been good fun. A little frustrating at times, but there’s lots of stuff that’s just falling into place and it’s generally making me feel much smarter.

This feeling stopped when I started trying to deal with MP3s….

Encoding with libLAME isn’t too taxing thankfully. It took me a little bit of getting used to but I’m now happily reading WAV files, stretching samples and then pumping out MP3 files at the end. Encoding, however, is a different matter.

I’m using libMAD and I’m still finding it more than just a bit taxing to understand. I suspect that this is more likely my lack of knowledge than the library itself’s fault but to be honest, that just makes it that little bit more annoying.  On the plus side, it really does make me appreciate how easy all these high level scripting languages make things.

Anyway, enough of my whining, As far as SlowRadio is concerned, the project is steadily cruising along and things are looking pretty good. Thanks to some help from Paul I’ve been able to get a program that mostly recreates his algorithm. I haven’t put in any of the onset detection but tbh I’m saving that for a bit later when the other sticky bits are done.

Once I can successfully read in MP3s the next step will be to wrestle with libshout and libcurl so I can go spreading my merry noise across the InterBlag.

Just got to keep moseying along, and keep track of all these buffers right?

Over the past two weeks, whilst taking some much needed time off from work, as well as enjoying the festive seasonal cheer I spent some time brushing up on my C skills. Part of the reason for this is because I’m embarking on a long running project involving pic chips, modular synths and actual hardware will need to get back to some good old fashioned embedded C. My other plan was to start on an idea I’ve had for a while and decided since it would involve quite a bit of DSP, I’d do it in C and use it as a learning exercise.

By now most people should have heard the Justin Bieber 800% slower ”remix” that flew around the internet a little over a year ago. It uses Paul’s Extreme Sound Stretch to slow the song down without affecting the pitch, turning a fairly trite pop song into a truly amazing slab of monolithic, ambient noise. Essentially the program just takes many overlapping windows of audio, calculates the frequency spectrum using an FFT, randomizes the phase value for each frequency bin and then does the inverse FFT. There’s a little bit more magic to it than that, but that’s essentially it.

I’ve decided to create a radio station, much like PatchWerk Radio, that will download CC licensed audio from the internet at large, stretch the songs, and then stream them back out. To help matters along, Paul’s Stretch is open source software so I’ve been able to dig into the internals and find out how it all fits together. At the moment the code is up on github and can be used to stretch audio and write it out to a new file. It doesn’t sound quite as good as Paul’s version because there’s a bit more DSP voodoo in his that I haven’t yet implemented but I’ll be getting on with that in the next couple of days.

Once I have that sounding good, the next step will be to get on with the audio finding and downloading, then interfacing it with shoutcast/oggcast. Given how quickly I’ve managed to hammer everything out so far I don’t think it’s too far off.

For the last (very late) patch of the month I’ve decided not to do any more with the sequencer, but to go off on a bit of a tangent and create a simulation of a bouncing ball. It’s not the most thorough physical model, and there are a couple of issues with it, but it gives a pretty good idea of how to go about taking mathematical equations and transferring them over to PD.

This patch will model dropping a ball from a chosen height and simulating how far it falls or rises within fractional lengths of time. The downwards direction gets changed to an upwards direction on the bounce but the co-efficient of elasticity (bounciness) can be changed to decide how much energy is lost when this happens.

I’ll be using two equations here.

$ x = \tfrac{1}{2} at^2 + v_ot + x_o $

$ v = at + v_o $

These are two of the standard suvat equations of motion. The first says that in a given amount of time $ t $, the position of an object will be its current position $ x0 $ plus its velocity at the beginning of that period $ v0 $ multiplied by the time, plus half its acceleration $ a $ multiplied by the time period squared.

The second says that the velocity of an object after time $ t $ is equal to its velocity at the start of that period $ v_0 $, plus its acceleration multiplied by time.

In the patch below I’ve broken the model down into three parts, one for the first equation, one for the second and then another part that checks when we’ve hit the bottom.

At the top there’s the metro to run the patch and some setup. There are five variables here and I’m storing them in value objects.

• The time period

• The initial starting height

• The current velocity

• The acceleration due to gravity

• The bounciness

It’s worth pointing out here to remember that gravity is a negative value. This patch assumes that positive velocity is up, and as gravity is always pulling down it’s negative.

This patch works with a relative time model instead of an absolute one. We’re calculating the relative change in height since the last calculation, not the overall height since we started. This means that the velocity change also needs to be calculated relative to the last velocity. This is done by the left hand collection of objects which calculate the second equation. The section gets given the sample length and multiplies this by the acceleration to get the change in velocity. This gets added to the current velocity to give us the new value.

The middle section calculates the values for the first equation. It takes the current velocity and multiples this by the sample length then adds on the $ \tfrac{1}{2} at^2 $ part. It adds this to the current height value to get the new height value. When the patch starts, the velocity will be negative as the ball is travelling down, so decreasing the height.

The final part on the right hand side checks to see when the ball hits the ground. When the height is < 0 it reverses the velocity and multiplies it by the bouncyness. On the way back up the velocity will gradually decrease due to the effects of the negative gravity, and eventually it will stop and come back down. Assuming the bouncyness was a less that 1 value, the ball won’t reach the same height, so the time until it hits will decrease.

There are a few issues with this model, mostly around the the section that checks for the bounce. The height will actually go negative for one iteration and only go back up again on the next calculation, after the velocity has been reversed. This can cause issues when the height gets very small and ideally there needs to be something smarter here to work it out.

Also if the sample time is too large then there is a lot of unstable behaviour so it’s best to keep it to values around or below 0.1.

That said, this serves pretty well as an example so should teach you the basics of doing this sort of physical mechanical modelling.

But no1 that’s it for Patch a Day month 2011. I’ll make sure that all the example patches are in the repository for downloading and I’ll leave it at that for now. There will be more PD stuff going up here, I’ll make sure I;m better about it than last time.

Sending output to the launchpad is pretty easy. Sending the right output, in a way that’s easily configurable and fits in with the standard is a little trickier. I’ve had more of a read of the Launchpad programming guide and have a better handle on the double buffering and so on and I’ll put some of that into practise here. The updates to the sequencer here are, I feel I should point out, as pretty or high performance as they could be. There’s definitely a lot more tweaking needed.

One of the things I’ve found a bit of a problem is sending the large number of update messages to the launchpad. There’s a slow down in PD whilst it’s going. I don’t know if it’s due to the MIDI output, or just trying to send a mass list of 64 messages and needing to make the process more efficient but more investigation is needed.

This is the updated track abstraction with the output for the light states. The left hand section that updates the data structure will now also send out a message with the new value of the updated step. The right hand sections are for dumping out the state of all the steps in the data structure. This is used when changing tracks as we want to update the launchpad with the new values and clear the old ones. By dumping out the state of all on or off steps we clear the old data and fill the grid with the new. This could be made more efficient by first clearing the grid, then just sending the steps that are on but i decided this is initially simpler to deal with.

The main sequencer section has been updated as well to parse the data now being output by the tracks. The objects right at the bottom will take the step messages, convert the step number back into the XY coordinate and change the 1 or 0 value into the correct note velocity for the colour we want. The clr abstraction works differently now just to point out. It takes two arguments, one is the colour value to send out when it gets a 1 input, the second for when it gets a 0 input. I’m following the Launchpad programming guide by sending out a value of 12 for off. This apparently makes it easier to add in double buffering later which might well be necessary.

There’s also a small section in the middle at the top that sends out the light on/off messages for the mode lights. The tracklight patch just keeps track of the current track number and, when the track changes, will send out an off message for the old button and an on for the new one.

As I said, there’s actually a fair bit of work that needs to happen on this to make it fast enough but it’s not bad as a start. I’ll probably concentrate on tacking on the drum sounds for the next patch-a-day and then call it finished for the moment.

That will also actually be my last patch-a-day patch for this round. I’m going to be continuing work on this sequencer and I’ll be writing more of it up, just not worrying about doing it once a night though heh.

Just a shortish one today, Yesterday I said that the step sequencer we’d built was mostly working but had a fairly vital flaw, we couldn’t actually save values in the data structure because we were getting not on and off messages from the launchpad. There are a few ways to fix this but I think that the way I do it here is the simplest and most flexible.

First things, we only want note on grid messages, that can be fixed with a spigot in the main sequencer patch.

Note off messages will now get blocked and won’t go through to the track abstractions.

There’s a few less objects in the track abstraction now but a few new ones as well. The biggest change is that the input is now actually only a single number. This number is used to calculate the pointer to the step position as normal, but it then gets sent to a get object as well as the set object. The abstraction will now check the current value in the data structure at that step and then update it with the opposite value, so we’ve successfully toggled the value in the data structure.

It’s easy to change this behaviour if needed, you might want to increment it or do something else, that’s up to you. Obviously we cant just send in a value for the abstraction to store now but that’s also easy to change, or just use the old version.

Anyway, the launchpad can now update the data structure and the sequencer actually sequences if you turn the clock on. Of course some lights on the Launchpad would be good, but that’s a task for next time.

Right, time to hook the launchpad up to the sequencer. I’ve modified the Launchpad IO abstraction to neaten it up and make it actually deal with output and input. The sequencer patch has been changed so that incomng grid messages are converted to a stop number and the mode buttons select the track number to update and the main clock is now on the outside.

Let’s run through them and I’ll explain a bit about what’s going on.

The sequencer is now the steps abstraction and the first argument tells it how many steps we want to have. The basic metro clock is still there, entirely unchanged. The launchpad_io abstraction now takes the channel as an argument as well. All simple and a bit dull.

The launchpad IO now just deals with outputting the MIDI in messages and sending the MIDI out messages. All IO goes through a single inlet or outlet and all messages are prefixed with either grid, mode or ctl to show where it’s from or going to. There’s also the reset option available which sends the clear message.

The step sequencer now has a bit more functionality. It takes the input direct from the launchpad and pulls out the grid and mode button messages. The mode messages control which track we are updating and do that by pre-pending the track name onto the front of the grid message. The tracks then route for this as they do normally. Note the spigot on the mode section, this is there so that only button on messages get through. We don’t actually care about button off messages here so we just stop them coming through.

The grid messages are converted from their XY format into a single value that gives the step position. At this point it may be clear that there is a problem with the current setup. The grid buttons also have button up and down messages coming through, so when we press a button the 1 value gets stored, but as soon as it’s released the 0 is stored over the top of it.

For the moment I’ll let you think about how you might solve this, tomorrow I’ll show you how I do it.

I said I’d do this once I’d done a bit more work on the sequencer, but I realised that it’s probably a better idea to get this done first as it will make testing much easier. This patch is really just taking the MIDI input from the launchpad, formatting it into messages that are easier to deal with, and then translating our simple messages back into correct MIDI for us to send back out to it. As a quick refresher, here’s what the Launchpad looks like.

During these posts, I’ll refer to three sections of the button layout. The eight buttons on the top row are the control buttons, the eight down the right hand side I call the mode buttons, and the 8*8 grid is the grid. Explaining that should make it easier to follow what I’m talking about.

The input from the Launchpad for these is pretty basic, but it’s not as easy to deal with as it could be, the grid and eight mode buttons all have MIDI note numbers assigned to them, but they’re essentially mixed together. Ideally I want to separate the mode button messages from the grid messages, and have the grid messages be in a simple (X Y value) format. The control button input is all as midi control messages, which is easy enough to deal with, but they start at value 104 and it’s much easier just to deal with 0 to 7.

One other thing to note, the input values from all button presses are either 0 or 127, either as note velocity or controller value. For input I find it much easier to just deal with 0 or 1 for button presses, output we actually need to use certain values to set the colours but that can be simplified easily enough. Here’s the patch as it currently looks.

Top left is dealing with grid and mode note in values. Straight out of the notein object I’ve already converted the velocity values to 0 or 1 and the notein object itself is filtering for midi channel 1. This is the channel my Launchpad appears under in PD though it might be different depending upon what’s plugged in. When I turn this into an abstraction, all the channel messages will be an abstraction argument to make integration easier.

The route object specifically selects for the eight note values of the mode buttons and then uses a fairly cludgy way to turn these into 0 to 7 numbers with the on/off value. Anything that isn’t one of these numbers is from the grid which can be turned into the XY coordinates I’m after using some basic maths. The layout of the note numbers on the launchpad follows the equation (row * 16) + column, so by dividing by 16 we can get the row number, and finding the modulo remainder of  8 we get the column. These get packed with the note on/off and that’s the grid message.

The control messages come from the ctl in object, situated middle top, and the channel filter has to be done externally because of the way ctlin works. The values also come in in the format (value, ctlnumber) which we want to be the other way round, the swap object handles that, then the ctl number has 104 subtracted from it and the data gets packed into a nice simple format to deal with.

The output sections basically do this in reverse. One thing to note is that I’ve added in a reset control. Sending the launchpad a zero value on control zero will turn off all the LEDs, a useful function to have.

The right hand side is just to take our input messages and convert them into output messages so the patch can be tested with a launchpad. The clr abstraction gives an easy way to set the output velocities/ctl values so we can select the colour we want on the launchpad. Internally they;re pretty simple.

The creation argument will set a default value, or the right inlet can be used to select and change it. The incoming value gets multiplied by the selected value so note off messages are still zero when they go out. The colours are red low, red full, amber low, amber full, yellow, green low and green full. I’ve just realised that technically all output to the launchpad should always be the off value (12) due to the internal buffering and so on it has available, I’ll need to check that out, but for the moment, have a play around with this if you have a Launchpad and see how it works.

This kind of input filtering and manipulation helps to make life much easier when creating larger apps that interface with MIDI controllers and I hop this abstraction will be pretty useful in future.

OK, carrying on from yesterdays patch, lets get the stepping and clock for the sequencer.

The setup here is really pretty simple, but there’s a couple small things to note. I’m routing for clock and reset messages, just to make things obvious when you;re controlling the sequencer. The reset message gives the pointer a traverse message which resets it to the head of our list of scalars. The clock message will trigger a next message to be sent to the pointer which will then send it’s value to the series of daisy chained objects. This will cause all of them to output their values and they can be seen printed out to the console.

The trigger object is there because of how the pointer deals with coming to the end of a list. The pointer will output a bang, upon receiving a next message once it has already output the last list element. we want that final bang to send it back to the beginning, and then immediately output the first list element. To do that, when the pointer sends out its bang, it first triggers a new traverse message, and then triggers another next message, meaning the first step values get sent out.

Next I’m planning to neaten this up a bit, and then we can start dealing with Launchpad input.