One of the first posts I wrote on the new version of this blog was about my genetic algorithm Ruby gem, Darwinning. I actually started building the library back in December of 2012 when I was first learning Ruby and it’s gone through several updates and periods of inactivity. Usually I’ll just add some tests or make a small update when I have some free time. It’s been a pretty casual project. I just didn’t think that there was that much of a need for a Ruby GA library, I just thought it would be fun to make.
Recently I’ve seen a steady stream of people starring and forking the Darwinning repo on Github and I’ve received some really thoughtful and helpful pull requests from people, so I wanted to give the library a bit more attention. I had some free time this weekend and used it to finish off a major feature that I had been working on and finally published the 0.1.0 version of the gem!
The major feature I added was the ability to use Darwinning in existing Ruby models via include. This lets you utilize the library in projects that might not be specifically about genetic algorithms.
Here’s my dumb, contrived example:
require'darwinning'classTripleincludeDarwinningGENE_RANGES={first_number: (0..100),second_number: (0..100),third_number: (0..100)}attr_accessor:first_number,:second_number,:third_numberdeffitness# Try to get the sum of the 3 digits to add up to 100(first_number+second_number+third_number-100).absendend
Then you can use some nice built in methods to generate a population of these objects and evolve them towards a fitness goal:
ifTriple.is_evolveable?triple_pop=Triple.build_population(0,10,100)triple_pop.evolve!# evolve until fitness goal is or generations limit is metpp"Best member: #{triple_pop.best_member}"end
I’ve been having fun working on this project and it’s really cool to see some other people contribute to the project. If you want to play around with the library or have an interest in genetic algorithms just gem install darwinning or check out the Darwinning Github repo. There are always more updates to do, but it felt good to make some progress on this project.
Last weekend was my first wedding anniversary. We didn’t really have big plans to exchange gifts but I thought it would be a good opportunity to finally record “Our Story”, the song I used to propose to Eileen. I had been meaning to do this for a while, partially because I knew if I didn’t I’d probably forget how to play it and that would make me a terrible husband.
If you don’t want to read all my thoughts on recording the song feel free to just go listen to it now. I’ll only be a little offended.
This song was written to be played live, only on acoustic, and has some holds that feel pretty loose so I had to start off by making sure I could actually play it with backing drum track. It took me a few tries to get the feel of it but I think it came together without sounding too rigid.
After recording the acoustic part, I got to have a lot of fun writing all the other things that go on top. I had a lot of fun with the bass and actually mixed some of the low end out of the acoustic to give the bass more room. The piano in the chorus really came together pretty nicely, particularly the hits under “I can’t wait to write…”. The left hand work there gave it some good body.
As usual, I was tempted to do more electric guitar noodling than I should but some after some editing I was pretty happy with the little theme I had in the verses. The lead part in the choruses ended up acting as more of a harmony that gave the chords an interesting sound at times.
There’s a part in the 3rd verse right after the line “together with our furry child” where it sounds like someone just stepped on a piano. That’s because the cat just stepped on the piano there. Since the line was actually about him I mixed it down but left it in.
The outro was interesting in this song. It was originally the verse or chorus of an early draft of this song that never really panned out, but I liked the lyrics and it was in the same key as the rest of the song so I really wanted to make it work. Also it was a nice held chord segue into actually popping the question, which was pretty important at the time.
I wanted to be sure this still sounded cohesive with the rest of the song, but still go out big and I think it turned out well. While I could have mixed it a little better, the pick slide into distorted power chords is just a lot of fun. The piano part was just something simple I stumbled on while I was messing around, but I really like what it adds. I ended up doing a lot of editing to decide which instruments should stop when and I’m happy with those choices. There was a lot of value in editing this song a few days after I had done most of the recording.
All in all, I was really happy with how this turned out and Eileen seemed to like it too. It’s always fun to record original music and this song was particularly important to me.
So back when I was working at Berkeley (and had more free time) I decided to formalize the tracking of some of my skill improvements. These were mainly things like drawing, playing guitar, playing piano, vocals, comptuer science theory, etc. I set up a small WordPress blog called Input Coffee and just made posts for every session in order to keep track of what I had been working on. I liked seeing all the posts every month and having a record of what I was doing, but a blog wasn’t the perfect solution. I wanted better ways to add up time per week or month for each type of task.
I decided to start tracking this sort of thing again, partially in response to reading Make It Stick, and I wanted a simple way to track my practice sessions for things like guitar, chess, drawing, and other stuff I’m working on these days.
I started by just creating Google Docs for each session, which worked fine and helped me not avoid doing real practice by spending a bunch of time building a complex system to track my practice. But then I gave in and built a system to track my practice. Like the original WordPress blog, it’s called Input Coffee.
This system is pretty simplistic, just a Sinatra app that reads some Markdown files and turns them into CoffeePost objects so I can examine them based on tags, subject, date, and a few other fields. The Markdown files use a format very similar to Jekyll’s posts and I just parse out meta data from the little header.
Here’s an example post:
---
date: 2015-07-14
subject: guitar
tags: acoustic electric
hours: 1.0
---
Spent most of this session doing acoustic stuff...
I don’t even have this hosted anywhere, I just run a local server when I want to see stats about my practice. Right now I just show total posts/hours (since May 25th, 2015), some breakdowns by subject (guitar, vocals, chess, drawing, etc.), and some numbers for the current and past week
Obviously, I’d like build out some more metrics and it might be fun to make a nicer interface, but for now this works for me and I’ve avoided overly-over engineering the solution. Being able to track this sort of stuff really helps keep me in good habits.
Eileen was out of town this weekend so, as I typically do in these situations, I took advantage of the time do some recording. As mentioned in previous posts, I’ve really been into the Aaron West and the Roaring Twenties record so I decided to finally record one of those songs, Divorce and the American South.
This is a pretty faithful cover. I didn’t deviate too much from the original version and actually resisted my urge to add some lead guitar parts to the song. In place of the slide guitar, prominently featured in the original song, I focused more on the organ part to do something tonally interesting against the acoustic guitar. The organ also just fills the song out nicely without adding a bass part.
I also recorded some saxophone for the first time since recording the last Captain Supreme song, which was pretty fun.
This recording session gave me the chance to really work with with my new vocal mic (MLX 2003A) and my new monitors (JBL LSR305s). I ended up using the MLX for both vocals and the acoustic guitar and just used my SM57 for the sax. It was really nice to be able actually hear things in the mix with the new monitors. Hopefully the end result is better for that clarity.
As always, vocals were a challenge. They’re not perfect but I feel like I’m making progress, which is always nice.
I spend the vast majority of programming time working with Ruby these days. I’ve gotten to know it pretty well and it is honestly a joy to use, but I want to make sure that I don’t just limit myself to a single language or even a single type of language (the occasional Python project doesn’t quite count as adventurous). Out of curiosity and a desire to work with a more low level language I’ve started playing around with Rust.
Rust is a systems level language created by Mozilla that might be used in similar situations as C++. I haven’t done anything this low level since I had to use C++ for a data structures class my sophmore year of college, which was a surprisingly long time ago.
I needed a small project to build if I was going to learn anything about the language so I decided to build a Bloom filter. A Bloom filter is a probabilistic data structure that is designed to be really space efficient and allows you to determine if something is “probably in the set” or “definitely not in the set”. For example, web browsers use Bloom filters to store lists of dangerous websites, which is why you sometime get a warning for an obviously safe site.
The end result of this little project was Bloomfilter-RS, a small Rust library that implements a Bloom filter. It can be used like this to create a Bloom filter with 100 buckets and 5 hash functions:
It was pretty interesting working with a lower level language coming from Ruby. I had to think about passing pointers and dealing with a much more robust type system. Fortunately working with Scala in the past prepared me a bit for dealing with generics and default immutability, but it really felt MUCH slower than working with a high level language like Ruby (which I suppose should be obvious).
I don’t really have a major project in mind that needs a language like Rust right now, but I’d like to keep tinkering around with it just to expose myself to other types of langues. It’s also just fun to follow a language as it’s being built (as of this post Rust is still a few weeks away from it’s official 1.0 release and some of the API still isn’t quite stable).
Feel free to dig through my Bloomfilter-RS code and give me any feedback about style or a better way to use language features. It was certainly built as a learning experience.
So last month I found out that Dan “Soupy” Campbell from The Wonder Years put out a solo record under the name Aaron West and the Roaring Twenties. I was rightfully excited by this because the record, We Don’t Have Each Other, is one of the best albums I’ve heard in a long time. The storytelling and imagery are amazing. Dan does a beautiful job of painting a scene in every song. It’s like listening to an incredibly well written short story, but there’s fantastic music to go with it.
I had been sketching the other day and I found it was a lot easier to decide on something to draw if I started with a box, like I would when drawing comics. I was looking for a subject for some comic-like art and decided to do a drawing for every song on this record. The scene-setting and exposition in these songs made them a perfect subject and it ended up being a really fun project. Some of the scenes I drew were just snapshots of things described in the lyrics and for some I took a few interpretive liberties. I recommend listening to the record while checking these out. Enjoy!
I’ll probably post these on Mount Saint Awesome soon, but this seemed like more of a project than a comic, so I wanted to do a blog post first.
So I posted my first Thing A Week post almost exactly 1 year ago today. The idea behind Thing A Week was to get myself to do more small projects with short deadlines and also get myself to work on a bunch of different things so I was producing something interesting each week.
While some weeks I did manage to work with in those bounds and produce a standalone project in one week (for example; the bass pedal, my cover of In The Garage, and the Therimino) I actually ended up spending a lot of my Thing A Week time on pieces of larger projects like RecLaboratory and the photo listener. While this wasn’t the original intention of the exercise I was still able to use the model to break up chunks of work and produce stuff worth talking about almost every week.
In the end I did 36 Thing A Week posts last year. Not as good as the 52 I would have liked, but it still represents a lot of productive weeks. I also found it really valuable to write about what I was working on each week. I think I just really enjoy sharing both the finished product and the process for the projects I work on.
While I really enjoyed doing the Thing A Week posts last year, this year I’m not going to have the same weekly goal. I may do some more Thing A Week style posts when I finish a project but I’m trying to focus more on just doing stuff rather than only on getting stuff done. For example, when I was writing music last year I focused a lot on writing things that I knew I could finish quickly so I ended up with a lot of short musical ideas, but not very many complete songs. I want to spend more time doing things like art, music, and coding (and whatever else sparks my attention) and doing it well. Maybe this means spending more time drawing in sketchbooks and less time making finished comics. Maybe this means starting a couple of songs and working on them until I’m REALLY happy with one.
I have a few project ideas (some big, some small) that I’m already starting to plan out, so I’ll try to keep up with regular Thing A Week style postings discussing my progress on those things, even if it’s just for my own enjoyment.
This last week I built something cool that was actually in the spirit of the Thing a Week project!
Last Christmas my mom got me a distance sensor that could be easily used with an Arduio (which is a totally normal gift) and I finally got around to playing with it. I had originally wanted to start working on some sort of robot but first I wanted to just play around with it and see what I could do.
After running through a few tutorials I decided it would be fun to make some sort of crude musical instrument using the distance sensor. I learned a bit about how to hook up a tiny speaker and then used the value of the distance sensor specify which tones to generate.
This created something that just constantly made steady sine wave sounding noise. I wanted to add the ability to do start and stop notes so I attached a small pressure sensor to the project. Then the tone would only play if you were pressing down on that sensor.
I also added a small LED light that turns on when a note is being played because lights are neat.
Because you control the instrument by moving one hand around, like you would on a theremin I decided to call my new creation a theremino (like theremin + Arduino… get it?). Unlike a theremin, the theremino plays discrete notes from a regular chromatic scale, changing notes every 4cm you move your hand from the sensor. It has a range from B2 to C6.
As you can see from the video below this instrument is actually kind of hard to play. It’s tough to be accurate with your notes when moving around in mid air.
It had been a while since I had tinkered around with an Arduino, so this what a really fun little project. For those interested, I have the the Arduino code for this project available here and a wiring diagram for the Ardunio and breadboard here.
Unfortunately I’ve broken my “Thing a Week” streak due to some busy weeks where I just didn’t have time to make much of anything. I did, however, have time to clean up some of the last few things for the RecLaboratory early tester launch. Bobby and I spent last Tuesday fixing bugs and cleaning up the UI to get RecLab to a place where we were happy enough to let other people check it out.
This doesn’t mean it is complete or bug-free by any means. I’m sure there a lots of little rough spots and the UI, while not terrible, is still pretty bare-bones. But our goal for this “release” was to get the site to a point where we could show some friends and let them try things out. We really just want to see if we’re headed in the right direction with what we have so far before we devote a lot of time to polishing the UI and the code base.
It’s pretty exciting to finally start showing off something we’ve been working on for a long time (on and off for about 6 months now). While it’s kind of nerve-wracking to worry about something breaking now that people other than Bobby and I are on the site it’ll be fun to see how people start to use what we’ve built. We’re rolling out invites very slowly as we become more confident about the feature set and stability of the system.
I also started a RecLab Blog (my first Tumblr account!) to act as a sort of company blog now that we’re trying to involve other people in the site. As always you should follow/friend/read/whatever our Facebook, Twitter, Instagram, and blog.
Please go to www.reclaboratory.com and sign up to become an early tester and we’ll probably send you and invite soon!
Last week was a pretty busy week so I didn’t get too many “projects” done outside of some RecLaboratory work and even most of that was done in between sessions at the Golden Gate Ruby Conference. The major piece of work I finished up, apart from some UI cleanup, was a modal to create (and record!) a new track from a song’s page. I think this will be a very common use case, so I wanted it working before we did the friendly release.
After getting the in-browser track recording to a working place the previous week, I wanted to reuse most of that functionality in this new modal. Building this new feature on top of that existing code caused me to refactor a few things, which was great. I also had to add the ability to use multiple tracks as a “backing track” for the recording because I imagine that users won’t want to bounce the song after every recorded track. This takes advantage of the track pre-loading I had already built into the song page and a little bit of html5 audio object abuse.
This is one of the last functional pieces of the site that needed to be built before we start soliciting alpha testers. Originally we had wanted to open RecLaboratory to early users on September 8th (almost exactly 6 months after Bobby and I first started talking about the idea) but we really wanted to get the last features in so that we could offer users a compelling reason to interact with the service. I think we’re getting REALLY close now!
This last week I built something cool that was actually in the spirit of the Thing a Week project!
This created something that just constantly made steady sine wave sounding noise. I wanted to add the ability to do start and stop notes so I attached a small pressure sensor to the project. Then the tone would only play if you were pressing down on that sensor.
After getting the in-browser track recording to a working place the previous week, I wanted to reuse most of that functionality in this new modal. Building this new feature on top of that existing code caused me to refactor a few things, which was great. I also had to add the ability to use multiple tracks as a “backing track” for the recording because I imagine that users won’t want to bounce the song after every recorded track. This takes advantage of the track pre-loading I had already built into the song page and a little bit of html5 audio object abuse.