Cuttr is written in scala and will apply randomised (but hopefully interesting) mathematically defined processes to the RGB values of an image.
Usual, found on Tumblr, shown on Tumblr rules apply.
I’m planning on adding a few more glitching possibilities to it but the early results are already pretty promising. Much of the time with this was actually spend wrestling with the OAuth stuff, made significantly easier due to the Scribe library. Also, I still don’t quite get reading of binary data in Scala. Should be easy, but never seems to be.
Anyway enjoy the results
]]>This is just a really basic Virtual Machine I wrote because I’ve not written one before. Eleven instructions, very basic memory model, no stack or registers and both Python and C implementations. I’ve written a simple assembler program so writing code for it can be done more easily but it’s really very limited. Did the job as a learning exercise though.
Not really a programming project, but I’ve started having an active go at improving my workflow and an important part of that was to sort out a good bash environment. Having it on github means I can easily share it between home, work and any remote servers and I can keep track of what I’m testing out with it.
Having gotten Glitchr working I decided to have a go at using Scala for some image processing. Cuttr will (once it’s all finished) allow you do define mathematical functions and apply them to the image, either as a whole or as separate colour layers. It started with the idea being just to algorithmically cut them up but extended somewhat once I realised how simple it was.
Every programmer should be able to render a Mandelbrot fractal, this is mine. Written in C, using SDL to display it and allows zooming and outputting to PNG. The code is actually reasonably neat as well!
Based along the same lines as the very minimal and very cool todo.txt, this is a tiny command line app written in bash that allows me to quickly take notes. It’s pretty much functioning at the moment but I’m wanting to extend it with the ability to upload the notes to Evernote as well, once I’ve figured out what the hell their API is doing.
So that’s some of what’s been consuming my time recently, there are a handful of other smaller projects but none are in the sort of state where they’re of much interest. I do have some plans to start some SDL + OpenGL graphical experiments but there’s a bunch of maths I need to relearn first. Better get my nose in some good books.
]]>I started with Jekyll Bootstrap and then created my own theme for it that essentially mimics the old look of the PatchWerk site. A few moments of confusion as to how to use liquid tags but it’s all up and running now. The new site is up at http://rumblesan.com/PatchWerk-Radio/ and hopefully it will use the old http://patchwerk.rumblesan.com domain as soon as I have the DNS settings all sorted.
The Author, Patch and Currently Playing info will all also be available with the plan being to create an api on the server that can deal with JSONP. Gives me an excuse to learn something new.
]]>I resurrected it about a week ago and thanks to Michael Helmick’s TumblPy library I’ve now got it pulling images from and then re-uploading to Tumblr.
You can check out the images at rumblesan.tumblr.com and the project site is at rumblesan.com/glitchr
I want to improve the way the glitching happens at the moment. Currently it’s just the quantization tables that get played with but there’s plenty of other things that can be done. Also it tends to be quite aggresive glitching and I’d like to make it a bit subtler.
Something to play with either way. At least now it’s running it’ll be easier to mess around with
]]>So using a base custom colors.scss file from Zachary Maril and a style.scss file from Alessandro Melandri I was able to rejig Rumblesan into something a little different. Pobablly a few things that need further tweaking, but it’s looking good already.
]]>What this means for me is that
In other words, good times. There’s still a few things I need to sort out but hopefully I’ll have them done in the next couple of days.
]]>Everything will get sorted in a week or so but updates may be even more sporadic than they have been.
The good news is that I’ve thought of something new to keep me busy and entertained with Pure Data. More on that in a week
]]>
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.
]]>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/
]]>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.
]]>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
]]>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?
]]>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.
]]>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.
]]>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.
]]>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.
]]>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.
]]>
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.
]]>
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.
]]>