Open Source Hardware Panel

A couple Fridays ago was an informal panel discussion of things related to the Open Source Hardware movement and included some big names from the community.

I think it’s important to understand the tone of the panel: there was a declared drinking game that you had to drink whenever anyone said “community”. It was a light-hearted event that generated some excellent discussion. Early on the in evening Bre stated:

Open source hardware is not about the hardware, it’s about the infrastructure to participate.

I’ve had very little (arguably no) direct involvement in OSHW (open source hardware) and this declaration just seemed incredibly profound to me and really underlines the difference in communities between OSHW and FOSS (free and open source software).

There was a fair bit of discussion comparing the two communities, and of course given the crowd, there was a strong bias towards how the OSHW community operates. After learning more of the philosophy of OSHW, I’m inclined to prefer their approach over FOSS’s.

It was said that a lot of the differences come down to atoms vs. bits. It allows for business models to be more obvious because there’s a physical product with a more explicit cost while software isn’t tied to the physical. This also allows software to be a religion in ways that hardware cannot.

Another difference is that the next TODO of FOSS is documentation while the next TODO of OSHW is the consumer product. There are probably those that disagree with this statement, but I found it to be valid and to point out what I feel is a hugely discriminatory factor in FOSS. Overall, FOSS is poorly documented. It’s just not a community priority. Of course there are exceptions, but there is a large contingent of FOSS that seems to pride itself on steep learning curves and insider knowledge. This makes it very difficult for “outsiders” to join. In particular, it makes it more difficult for individuals who don’t exhibit the stereotypical white male nerd traits to participate. OSHW seems much more conscious of inclusion and group contribution.

My limited experience with the OSHW community has been through publications like Make Magazine, Maker Faire and the London Hackspace. All of these are male dominated spaces, so I didn’t expect the gender parity of the OSHW panel. FOSS panels would kill for this kind of gender representation. I find hackspaces (or at least the one in London) to be incredibly similar to FOSS demographics. I’ve even seen it drive away men from Big-C Creative industries because of the huge embrace of nerd culture.

My assumptions of the gender dynamics of OSHW fall apart when I actually think about them. I can much more easily name female contributors to the hardware world than software. Off the top of my head: Leah Buechley, Limore Fried, Becky Stern and now can add the panelists listed above.

I think once you’re inside the engineering club to some degree, in the process of assimilating it can be easy to forget how to be inclusive to those without engineering backgrounds. While at the ITP Camp, and especially by attending the sessions taught by Tom Igoe, I’ve certainly come to appreciate the tools that have been developed for those without computer science or electrical engineering backgrounds, in particular Processing and Arduino. I previously was frustrated with the platforms as I thought it dumbed-down the content excessively and didn’t ensure that proper engineering concepts were taught. However, I now appreciate that they get people writing code and working with microcontrollers without requiring entry into the exclusive clubhouse that is engineering. Learning the technical bits can come later. Finding an initial passion for creating and engineering needs to fostered first.

Sneak Peek at Android + Arduino + Processing

I’ve fallen very behind in posting about the sessions I’ve been attending at ITP Camp, but the one I attended last night has so much exciting potential, it’s skipping the queue of posts of previous sessions. The session description and info can be found here.

A couple months ago Google announced their Open Accessory Developement Kit. While everyone was really excited that they decided to use Arduino in the platform, there were some concerns about some of the engineering decisions that were made. The good folks involved with the development of Processing care about low barriers to entry for programming and feel that the workflow of Eclipse with the ADK could be a bit more user-friendly.

Processing for Android is already released and it is indeed very easy to get something running on an Android device. The exciting new development is in the photo below. This is an Arduino Mega ADK for Android. Only a couple dozen currently exist and as Tom Igoe is helping with the development, he has a box of them at ITP. They will become less exclusive very soon as they go on sale 4 July.

Arduino Mega ADK boark

Once everything is released, developers/artists/designers/people can used the Arduino environment and Processing to created objects that interact with the physical world and are run by Android devices including all the connectivity that they offer. Super amazing stuff.


  • Processing 1.5 or greater
  • Arduino Environment 1.0-beta1 or greater
  • Android ADK 2.3.3 (need API 7 to set up Processing and API 10 for Arduino)
  • Not yet released Arduino ADKLib for Processing
  • Android device
  • Arduino Mega ADK for Android
    • On a side note, starting in Arduino 1.0, Arduino sketches will no longer have .pde as the extension but will begin sporting the .ino extension. This means no more confusion between Processing and Arduino sketches. It is important to know that all .pde sketches from previous Arduino environments (including the examples) will have their extensions automatically changed to .ino. So older versions of Arduino will not recognize the new extension and it will appear that your examples and sketches have vanished. Changing the extension back to .pde will solve that, but reports are that Arduino 1.0 has been running sketches from older versions without any problems.

Entrepreneurship at ITP

The first two sessions that I attended at the ITP Camp were focused on entrepreneurship within creative industries, though from two very different angles. The first was lead by Lawrence Lenihan, a venture capitalist and Adjunct Professor at NYU, and the second by Tarikh Korula, an ITP alumnus and founder of Uncommon Projects, and Doug Barnes, a lawyer and friend of Tarikh’s. The two sessions were different in several ways, most obviously because the first was focused on product-drived industry and the second was focused on service-driven consultancy.

Read, FIRE!, Aim – product-driven business development. The slides were a subset of teaches at NYU. The slides he used for the session can be found here.

Here’s a summary of some of his main points:

  • Don’t write business plans, write business presentations. It’s not worth the time and effort to write a full 40+ page document that will quickly be out of date. It’s better to put energy into communicating what your business does.
  • Form your business around easing a pain. It’s better if it’s a pain that you are passionate about easing. Use tools like Google to see if people are looking for what you want to sell.
  • Figure out how much it costs to acquire a customer.
  • Know the difference between entrepreneurial opportunities and venture capital opportunities. Just because your business is not attractive to a VC doesn’t mean it isn’t a worthwhile pursuit.

Entrepreneurship for Creatives – consultancy businesses. It focused on concrete details, particularly in contract negotiation that design consultants should be familiar with along with other general advice on striking out on your own. It was an excellent session that was well attended; here’s just a few highlights from the evening:

  • Scale is a huge challenge for consultancies. The time to money ratio makes it difficult to grow as you can only work so many hours.
  • Someone in your business needs to be able to handle sales. The whole thing fails if no one is a salesperson.
  • You don’t have to do business the stereotypical white guy way.
  • Pick two: cheap, fast, good. The clearer you are at communicating this with clients, the happier everyone will be with the end result.
  • Contracts do not need to be written down and certainly don’t need to be full of opaque legal jibberish. But writing things down as a matter of record (for instance in e-mail exchanges) is good practice.
  • Educate yourself about IP. Your lawyer can’t tell you what your business model and IP model should be. Only you can make that decision.
  • When allocating IP, pay attention to what you get to retain. What do you really need to own? What does the client really need to own? Be sure that you’re only agreeing to sell things that you own and can afford to sell.
  • Decide what IP you need to own in order for your business to exist and grow, and then let everything else that is unimportant go.
  • When you’re about to blow an estimate on a project, tell the client. Being up front and communicating keeps everything civil. As a service provider, it is your responsibility to be clear with the client.
  • Questions about incorporating and forming legal structures become important when there are more than one of you (e.g. parters, employees).
  • In the US, generally tax and accountancy issues increase as you move from sole proprietor to corporation.
  • Can set up contracts with mixed rates: fixed rate for certain assumptions; hourly rate when those assumptions fail.

Other sources of information that were recommended were Fred Wilson’s blog and the presentation I’ve embedded below.

2011/03 Mike Monteiro | F*ck You. Pay Me. from SanFrancisco/CreativeMornings on Vimeo.

Both session leaders recommended the book Getting Real by 37signals.

These were the first entrepreneurial events/talks that I’ve attended in the US. I didn’t really have much interest in the area until I started my PhD, so I’ve attended business development events in the UK. The thing that really stood out for me during these sessions was just how American-centric they were. In the session with the VC I asked how some of the topics he was talking about translated to Europe, particularly the UK. He responded that he didn’t know and wasn’t interested in knowing. He was only interested in US markets and companies. It was too hard to fire someone in France. While the American-centrism was less blatant in the consultancy session, there was a curious lack of acknowledgement of anything other than the US system. (But oh did the talks of how much money you need as a buffer make me so appreciative of the NHS. Estimates of $400+ a month for healthcare.)

Both talks were focused on New York, as one would expect given our geographic location, but I found it curious that they lacked any discussion of any other place in the world or even just the US. The exception was a side note in the VC talk that countries such as Brazil and China will soon blow up as the next big thing.

In both sessions there was a lot of discussion of the current bubble, though the difference in tenses used was quite interesting. The VC viewpoint was that the bubble is going to crash in the next 18 months and is already approximating the end of the dotcom bubble (Ashton Kutcher was noted as one of the significant signs). In contrast, the consultancy talk believed the bubble is still on the up, though of course acknowledged that it will one day end.

1-in-1: Bee #

1-in-1 is a like a mini hack day, but I find it refreshing that it is without prizes or even formal presentations. The goal is to complete a whole project in one day. You’re advised to not stretch too far or try to learn some huge new skill set. This is the full list of what everyone is working on today.

I am starting on a new project that I wanted to do since I learned about Sing-a-ma-jigs, a singing children’s toy. They aren’t very big in the UK, so when I was back in the US for Thanksgiving last year, we bought a couple (the red and purple in the photo, I found the white one at Goodwill yesterday).

The Choir

Their big draw is that they sing with each other and harmonize. We were then very sad to find that they don’t actually communicate with each other. Some mildly clever music theory (arpeggios from the same key) are used to ensure that multiple toys sound good together. It does result in a lot of very satisfying perfect cadences.

What I would like to do at the ITP Camp is develop toys that do actually communicate with each to spontaneous create harmony. I haven’t worked out the details yet, but the first step is to mimic the original toy with my own prototype that can be improved upon. So today, I am building a bee #, a singing bee. Below is the Bee in all his glory before he finds his voice.

Bee Before

So first, breakfast was consumed. It involved a square bagel.

Sing-a-ma-jig at Breakfast

Then I began working out a simple prototype circuit. I’m using an Arduino and basically building off this tutorial. I wanted to use the Adafruit Waveshield, but I did a poor job preparing and didn’t realize the opamp and dac were missing from the kit. This is the circuit.

Prototype Development

Simple Trigger Circuit

I then began performing a delicate surgery on Bee. I cut out a hole in his face slightly smaller than the speaker.

Bee Before Speaker

Then I crocheted a single crochet chain around the opening by cutting little holes around the edge and picking up stitches.

Bee in Progress

I ended up threading yarn into the crochet to create a drawstring to tighten the opening.

Bee with Speaker

When I went to Goodwill yesterday to find a stuffed toy that I could cut up, I found the white sing-a-ma-jig. I was initially very happy that I had a trio, but when I got it home with my other two, it didn’t harmonize. It sounded awful with them. It also operated slightly differently – it started in the song mode when first turned on, unlike the other two which start in the harmony mode. Today I recorded each one individually and used Sonic Visualiser to analyze the audio. I figured out the keys for each one and it’s now very clear why they don’t work together: the red and purple are in D Flat Major and the white one in is B Major.

So I now know the key my Bee needs to be in to harmonize with each sing-a-ma-jig, and unlike the sing-a-ma-jigs, it’s flexible and can change.

The code is available here.

Bee # from Becky Stewart on Vimeo.

ITP Camp Kickoff

This past Wednesday marked the beginning of the ITP Summer Camp 2011. The ITP is a graduate program at NYU that’s been around for 30 years. It’s a little hard to define, but it’s at the intersection of art, design, and technology and has an excellent alumni network.

The camp has been going for a couple years and it’s meant to be in the style of an un-conference like bar camps and hack days. The idea is for around 50 people to gather and hang out in the same physical space for a month. The space is the 4th floor of a building off Broadway near Washington Square Park in Manhattan, so you can’t really argue with the location. It comes equipped with things like 3D printers and soldering irons and, even more importantly, it comes with staff to train and assist with using that equipment.

The more structured part of the camp occurs in the evenings and weekends as most people are doing some kind of day job. (I’m working in the Department of Music a block over during the day.) The evenings and weekends are filled with sessions lead by ITP staff and camp participants. I’m particularly excited to attend Tom Igoe’s sessions on Basics of Physical Computing using Arduino Part 1, 2, 3, and 4. The full schedule (which is still being added to) can be found here.

I’m going to try and keep up with blogging my experience here, but this is 30 days long, we’re on the 3rd day of it and I’m only just writing the first post.

Why MIR Researchers Should Care About User Experience

I’m at NYU for a couple months to conduct a rather large user study on an interface that I’ve developed. I talked about my PhD work and my current work with a gathering of PhD and MS students last week. I’ve included my slides below, though we didn’t really go through them. It’s an updated version of a talk I gave at a couple universities last autumn.

On a related note, if you look around and find that it’s June and that you seem to be in New York, why not contribute 2 hours towards science? You’ll even get a shiny $20 bill in return. Go here for more information.

Some good discussion ensued and it helped me solidify my own thoughts, particularly as to why MIR researchers should care about user experience. To people within HCI or UI/UX or design fields, to not consider the end user seems like a ridiculous notion, but it’s unfortunately an issue that’s only beginning to be addressed.

I talked with a couple researchers that are working on an interface for a library’s music collection. As we discussed ideas and played the game of “oh, have you heard of ______, let me google that and find it for you,” it was admitted that they didn’t actually know why or how users use would the interface they were creating. They didn’t know what are the most common tasks that a patron of the library’s music collection is trying to accomplish. They said the librarians weren’t even sure. One of the researchers I was speaking with said that in his undergrad he spent a lot of time on ethnographic study and user-centered work, but that the work he was doing now was much more focused on the engineering. Unfortunately, I think that means that they’ve developed a piece of software that might not be useful to anyone.

If every researcher has a platform that they like to shout from, these are the main placards I would display around my soapbox:

  • The data should not dictate how people interact with that data, people should dictate how people interact with that data. My pet peeve is that just because you can project a multidimensional timbre space onto two dimensions doesn’t mean you should. At the very least you shouldn’t force a user to interact with it.
  • Don’t kill new products by letting the first release be your first user testing. Genius had negative reactions when it was first released, and I don’t think I’m the only person that abandoned it after some poor recommendations. Google Music is now facing very public discussions of poor performance that perhaps could have been addressed through some private studies before a semi-public release. If something doesn’t work right away for a user, then you may have lost them forever.
  • Users can tell you which 1% problems to focus on. If the end user can’t perceive any difference in the 1% increase in the performance of your algorithm, perhaps it was a wasted effort. There could be a 1% increase in another aspect of the system that would actually improve the system as a whole.

My current work is attempting to address how a small collection of music (e.g. a list of search results returned from a query) can be best presented to a user. I’m doing this without considering a specific MIR backend – I want to separate how the user interacts with the data from how that data was collated. It’s a very specific use case, but because of that I think it’s one that can be easily improved. I’ll certainly be posting more about it as the work is completed.

It’s the Small Things That Count

I’ve just returned from the San Francisco Music Hack Day 2011. This was the 13th in the series of Music Hack Days and the 3rd that I’ve attended. I was at the very first MHD in London in 2009 and then the London MHD last summer. Along with the MHDs, I’ve also attended a Yahoo! Hack Day and a Culture Hack Day in London, so I feel fairly comfortable at these events. I have hacked at all but the first hack day I attended (the Yahoo! one) and have presented a hack at 3 of the 5 I’ve attended.

I’m no stranger to the gender dynamics of these kind of events and the communities that attend them. Multiple engineering degrees really drive home the point that women are thoroughly the others of the community. However, the last MHD in New York created a little bit of a discussion after Matt Andrews from the Guardian posted a short piece noting the overwhelmingly white male audience of the MHD. There was a twitter discussion that followed which included a complaint that no one seems to be offering advice to improve the situation, only observational commentary. So I wrote up a short list of actions that I thought would help and it received a fair bit of traffic, but the discussion never carried on into planning of another hack day.

When I arrived at tokbox for the hack, I was amazed at the gender disparity. It was certainly the worst female to male ratio that I have seen at a hack day. I just didn’t expect that from the Bay Area, though when discussing it with locals, they said it was very representative of the Silicon Valley culture and they thought nothing of it. Dave was doing a full female headcount of the room and I never caught the final number, but my estimate would be of the approximately 150 attendees, fewer than 10 were women (that were there to participate in the hack, the registration desk and kitchen were staffed by women which raised the total number of women in the room).

To reiterate the statistics in another way, of the 54 hack presentations, 4 involved a woman with two of those hacks involving me (HueSound,Shooting from the Hipster, Music Grid, and DJ DJ Revolution. That means that there were 3 women involved in a completed hack. 2 of those hacks received prizes. 100% of the mixed gender teams (2 of 2), roughly 25% of the male-only teams (about 12 of 50), and 0% of the female-only teams (0 of 2) received prizes. Small sample sizes give weak confidence measures, but still numbers to think about.

I refuse to accept that women just don’t want to attend these events and that there simply aren’t any women in the hacking communities. That’s demonstrably untrue and incredibly insulting to imply that it’s women’s problem if they don’t feel welcome. Talented women do show up, it would just be great if more would join them.

The following things occurred this weekend:

  • The Friday evening before the hack, Elissa Barrett from the main organizer tweeted this:

    Hey #musichackday folks, get some rest while you can! Let’s split the men from the boys and see who’s standing at 5am on Sunday.less than a minute ago via HootSuite Favorite Retweet Reply

    I responded with this:

    RT @elissab: #musichackday … Let’s split the men from the boys and see who’s standing at 5am on Sunday. // not sure where that leaves me.less than a minute ago via Twitter for Mac Favorite Retweet Reply

  • Early into the hack on Saturday, the women’s restroom at Tokbox underwent gender reassignment. I don’t understand why they were gendered in the first place, they were each a room with a sink and toilet. Permitting the men to access the women’s restroom was absolutely fine, but the way the problem was “solved” left the building without a restroom for women. The women used both restrooms as well, but no where else in the building was it so blatant that you weren’t expected to be there.
  • During the lightning API presentations, MusixMatch gave a talk introducing what they do. They felt it necessary to use a porn reference to add some excitement to their presentation and it predictably generated some twitter traffic. They threw out the statement that lyrics are googled more than porn and accompanied it with an image of a woman in a sexual position with another woman. two people in a sexual position. (Ed: the creator of the slide informs me that’s a teenage boy, not a woman.)


    I didn’t act fast enough to take a photo of the slide, but afterwards looked to see if they put it up on slideshare (the above photo is by Thoms Bonte). They hadn’t, but I did find the slidebook for what they showed at SFMusictech the day after the hack. While it had the same text, they had removed the image. Why did they feel it was appropriate for the MHD audience and not for SFMusictech? (Ed: my mistake, that is a slide presentation from last year’s SFMusictech, not the one directly after this hack day.) If you feel you need a porn reference to spice up your presentation, perhaps you should reconsider the initial point you’re trying to make.

  • Before the last London MHD a couple of the regular female attendees requested women’s sizes in the MHD shirts and they were supplied without any great issue. This seemed to have been forgotten for San Francisco as there were no women’s sizes for MHD shirts and most of the other free swag available shirts were in men’s L and XL sizes.
  • I was timidly asked multiple times what I was doing at the hack. The person asking the question seemed to expect me to say I was in business development or the press or someone’s girlfriend. (I was seriously asked if I was there to represent my boyfriend since he wasn’t able to attend.) When I replied I was there to hack, I was met with visible surprise. This happened more than once.

Everyone likes to say — gasp, oh noes, there are mostly men here! how horrible, something should be done!!!1! But nothing ever seems to be consciously done by the organizers (or by frankly anyone in a hiring position at any music tech-related company) to address this. Instead, all these little things seem to slip by under the radar which scream at women: it is not normal nor expected for you to be here. It’s easy to improve the situation, just don’t do the things listed above.

What if every MHD attendee just did this one thing: when another MHD is announced, mention it to a female friend or colleague and say “These things are good times, I think you should go. You would enjoy it.” And then the next time you attend one, make sure the basics like restrooms are available to all attendees regardless of their gender identification.

Nonetheless I had a good time this weekend. I saw friends I hadn’t seen in years, met new ones, and even returned with a little prize money for one of my hacks. But using one of my favorite phrases from the UK, Music Hack Day, pull your finger out.

One in a Million

So I’m designing an experiment. I have an interface. I think it’s really neat, but would like to measure the best way to use this interface and try to quantify its neatness factor. I don’t want to tell you exactly what it is, because you might be a participant in my user study and that could muck around with the results. Suffice it to say that this is an interface for music search and browsing.

When I say it’s an interface for search and browsing, I don’t mean it performs a query. It is only a means to navigate a collection of music. How that collection of music has come into existence is someone else’s business. I just want to help people interact with a collection, in this case smaller collections. The idea is that someone performed some kind of query on the world of music and has a small (< 50 songs) set of songs that they want to traverse through in an efficient manner.

The Problem

I need a several sets of songs in order to perform my user study with my interface. Participants will be searching for specific songs and browsing for songs that fit a written description. As this is an interface for music search and browsing, I think that those sets of songs should be thoughtfully chosen.

I need

  • 6 sets of heterogeneous songs.
  • 10 sets of homogeneous songs so that there are 2 sets of a single “genre” for 5 “genres.”
  • All sets needs to be unique and no song appears in more than 1 set.
  • The sets have no order.
  • There will be approximately 30 songs in a set. This may change slightly after some pilot studies, but it shouldn’t change significantly.

Heterogeneous songs are songs that are as different as possible in timbre and musical style. I want as little similarity between songs within a heterogeneous set as possible.

Homogeneous songs are songs that are as similar to the other songs in the set as possible. This includes notions of “genre” and timbre. I want songs that are similar in signal content and musicality.

I want to use songs that are from the Million Song Dataset. I want this to be reproducible research, and I want to use a dataset that will overlap with other studies. Plus, the 30 second audio clips are exactly the audio content I want for the study – I don’t want full songs.

So I want to know how do I choose my 16 sets of music from the million available songs? I don’t want to write a lot of code – I’m not interested in this selection as a research question. I just want to do it and have it be reasonable. I’d like to use a combination of the Echo Nest API and the sample code for the Millon Song Dataset, but pointers to other useful bits of code will be appreciated as well.

My two main questions are: how should I choose my song sets and what “genres” should be represented?

Final Intro to Programming Slides

Here’s the final set of slides from the third introductory programming class I did with MzTEK. You don’t get to cover a lot of material in 6 hours, but we managed to introduce the idea of functions and how to use them. Writing functions was well beyond the scope (groan) of this short course. I was repeatedly asked what “void” means, so the goal was to try and answer that at some shallow level.

Teaching Programming Part 2

It’s taken longer to put up the slides from the second week as there was some significant re-structuring of the content. It takes a lot of concentration to decide how to present comparators and boolean operators – or at least more than I initially thought. What I originally put together and presented last Monday blurred the lines between too many subjects within discrete math and I think it came across as confusing. I hope this version is much clearer.

It’s funny how the knowledge inside your head mixes together. It can become difficult to explain fairly simple subjects without relying on a large base of information assumed to be understood by everyone. You just can’t expect people from an arts background to understand a mathematical explanation. It does force you to understand the information better yourself.

As this was the first time I’ve taught this material, I was expecting there to be rough patches. Overall though, I think it’s going very well, or at least that the feedback I get directly to my face. Our last class is tomorrow evening. How the time flies! I’ve had students say they are sad it’s coming to an end so quickly and I have to agree. It’s amazing how little you can truly cover in 6 hours.

I think the next steps are to work out a longer version of this material and then start looking at where I can teach it.