Pure Data snippets – Random list element
Hey, just a small post, coding some PD and realised that the small snippet I just made to select a random element from a list may well be useful for some people. I think I might start doing more small, code snippet type posts because they’re quick and easy to do.
So the section on the right, after the first trigger, takes the list length then calculates a random number between 0 and length – 1. The list goes to the split which will send the first section of the split out the left inlet, and the latter section out the middle inlet. This middle output list will have a random element at the beginning so we just trim that off with another split.
Processing JS and GitHub hosting
So Processing.JS is pretty cool, this much we know. GitHub is also pretty cool, I don’t think anybody is going to deny that either.
It turns out that the two work really, really well together and because of this I decided to throw up a gallery of my Processing.JS sketches that’s hosted using githubs pages.
Check it out here http://rumblesan.github.com/ProcessingJS-Gallery/
PureData versus SuperCollider versus MaxMSP (Why I do what I do with what I do)
So I got an interesting couple of questions in the comments for the last post. Many thanks to Joe for asking some good questions, as well as giving me a reason to get off my arse and write something. I’ll repeat it here for everyones ease.
Hi
I actually came across your blog/web page via various discussions on the Pure Data forum, which naturally I followed up and enjoy reading. However, I noticed in one of your earlier posts (on your own blog) the mention of SuperCollider. Naturally, since I came from the Pure Data forum, I’m a PD fan, like many out there. But reading your remarks about SC I’m interested to ask – what is the difference between the two programs? Is it worthwhile (a personal choice of course) looking into both programs, or in fact is one enough and it’s all a matter of interfaces?
Oddly enough I notice that you do your ‘models’ in PD, probably because it’s freely available, or is that not correct.
Thanks for the posts, I’m trying to hang in there, but since there’s no real order – easy to complicated etc – I often find myself out of my own depth. I also have to say I sometimes try to understand the importance of certain ideas in connection with the results. But in the final picture who cares, it’s very interesting and I’m learning as I read your posts.
Thanks in advance.
Joe
I wrote a reply back in the comments but I think it’s worth expanding on some of these questions with a bit more space to talk. Also on Thursday night at the London Hackspace I got to hear two members of the Birmingham Laptop Ensemble (BiLE) give a talk about the work they did and their thoughts on working with SuperCollider.
So, what do I feel the differences between SC and PD/Max are and why have I gone down the visual patching route.
Essentially, it does just boil down to being typed code versus visually patched code. Both have their strengths and weaknesses but really for me it’s just that I prefer the do audio work in a visual language. I generally think that it can be much easier to see the flow of data through a patch, especially if you’re not a programmer which is why I think that Pure Data has a much nicer learning curve that SuperCollider. That said, if you find yourself wanting to do anything involving dynamic object creation or needing large banks of voices then SC does make it much just because it is written code.
My advice? Try both. and as many other programs as you can. They’re all good for something and ultimately, it’s more about work flow than anything else in my opinion.
So as to why I do everything in PD and not Max/MSP, partly, yes the cost is one reason. Not because I don’t think that Max is worth it because it really is, more just because I want to make the barrier for entry as low as possible.
The other reason is that I believe that there’s less happening in PD, so the learning curve is again that bit shallower. You’ll generally find yourself having to build abstractions for things that come as built in objects in Max but I think it’s an advantage in some ways. The less objects you have to remember, the quicker you can get going and if you need something regularly then it’s good practise to turn it into an abstraction.
I always liken the PD to Max view as being similar to C vs C++. PD and C are like a subset of Max and C++, they’re more minimal, require more building and aren’t as nice looking, but the language itself is pretty small and very versatile.
Make of that what you will.
Rolling your own whilst beating PHP to death
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
An evening with Go
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.
Being LAME and MAD, the trials of de/encoding MP3s
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?
Stretching Audio for Fun and Radio
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.
Patch-a-Day November 2011 – Day 30 – Bouncing Ball
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.
These are two of the standard suvat equations of motion. The first says that in a given amount of time 
The second says that the velocity of an object after 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.
Bouncing ball patch
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
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 
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.
Patch-a-Day November 2011 – Day 29 – Launchpad lights
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.
Step sequencer track with light output
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.
Full sequencer with light state output
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.
Patch-a-Day November 2011 – Day 28 – Launchpad sequencer improvements
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.
Sequencer only accepts note on grid messages
Note off messages will now get blocked and won’t go through to the track abstractions.
Track abstraction now checks current value
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.