Building a Sequencer in a Group Setting

or Motley Crüe Meets A Hackathon

Steve_Weiss
6 min readMar 30, 2014

In my previous live as a musician, I learned many important lessons about group dynamics. I always told people it’s like having 4 girlfriends, but mostly the negative aspects. You have to embrace unpredictability. Every group of individuals immediately becomes a pirate ship when involved with a project they care about.

As part of General Assembly’s January 2014 Web Development Immersive, we were assigned a group project. Groups of 5 were randomly selected by instructors, and we were given 1 week to plan and accomplish as much as possible. Our group consisted of Ilias, Granger, Drew, Zack and myself (Steve.)

Our result is jSequencer, a musical pattern sequencer, modeled after the beautiful simplicity of classic drum machines. You’re presented with a grid 16 squares long. Each row represents a different sound, and each box in the grid represents a subdivision of a beat. A timer cycles through the grid and if a box is selected, it plays a sound. Suddenly all popular electronic music, hip hop, and modern day pop music is created.

jSequencer in action

It was built primarily with Javascript (and jQuery) using the Ruby On Rails framework. We took full advantage of the HTML5 Web Audio API which is fascinating and magical.

Up until this point, we had primarily worked on projects by ourselves. When you’re running the show, you dictate the pace, the direction, the user stories, the style guidelines…everything. When others become involved, a completely new set of concerns emerges. Our Git commits were suddenly full of merge conflicts. Before making a change to a controller…you have to ask if anyone is currently working on that controller. A hill had suddenly emerged in the middle of already uneasy terrain.

We started off at a good pace. After a day or so of planning and research, we broke off into two teams, one to get the Audio API working, and one to create an Amazon Web Services(AWS) account to store sound samples. By the end of day two, we had a snare drum sample triggering based on a Javascript timer….we were kings among men, no one could stop us. What naive beginners we were.

While we were all in good sprits at this point, you really don’t learn much about a group until you’re in the weeds. This happened Saturday morning. By this point, things began to get complicated. We had achieved very basic functionality, but the real work was just getting started. Our goal for the day was to handle user signup and login, and being able to create multiple rows of different sounds. We got off to a rocky start.

One younger member of the group came in looking a little rough. He had perhaps celebrated our earlier victories a with a little too much enthusiasm, and left his bag containing his laptop at a bar. While he slept it off for a bit on a pod shaped couch, the rest of us split into teams to tackle user authentication and dive further into the Audio API. I went to the user group.

It turns out, we needed to keep everything to a single page, without refreshing. With an app like this, a user would play around and create a beat before signing up or logging in, but would then want to save that beat without having to navigate away from the main page and lose all previous work. This differed from our previous experience, and occupied most of my next few days.

The others made great progress on the actual sequencer functionality, and had multiple sounds triggering and looping. The downside of this, is that not everyone could know what was going on at all points of the app. It gave us a small glimpse of what it must be like to work on a much larger and more complex project.

Some found this frustrating, understandably. The underlying rules of teamwork suddenly became very clear. You may not be working on the super cool part of a project at all times, but everyone has to maintain that team mentality. It may not be possible to just step into the drivers seat on a section which someone has been hard at work on for days, or your idea may not be agreed upon by the majority. You have to maintain support and a positive outlook. Yes, that sounds quite idealistic, but no one wants to work with the person who causes problems.

When the legendary session bass player David Hood was asked how he got so much work, he responded “I was always on time, my gear always worked, and I was easy to get along with.”

There was a fascinating This American Life episode, entitled “Ruining It For The Rest Of Us”. It focused on a scientific study on work in a group setting. They came to the conclusion that if one person brings an extreme negative attitude, it can greatly affect progress. One bad apple can bring down the entire team.

Luckily, no one got to that point, and we handled disagreements in a mature and effective manner. Spirited discussion may have even helped the process, we all had ideas which didn’t quite make it to the final product. People get very passionate about opinions. That is probably the very nature of opinion. And when not everyone agrees, it can get tense.

One constant struggle was whether to have a separate table in our database for groups of instruments, and what to call that table. Do we call it “kits”, “instruments”, “suites”, “ensemble”? Do we even need this table at all? Why can’t we just build a wave table synth instead of triggering samples? Can we just do a big animation the entire time of a hippopotamus dancing? What is our true purpose on this planet?

The agile process proved to be very helpful in these situations. If we had other ideas, we’d write a new user story. If there was time, we would work on it. If not, it would go into the “nice to have” category. That category is filled with great ideas which will one day hopefully see the light of day.

Group work is not without its pitfalls. But it does have an extreme advantage. 5 people working on a project can accomplish more than 1 person, it’s just that simple. Pair programming often makes tasks move far faster than solo, and it’s a great opportunity to learn from your counterpart. This can also be a challenge with 5 person teams, something which was no accident on the part of instructors.

The ability to learn from others in the group may have been the most important benefit. I feel I learned an incredible amount from asking questions and observing the workflow of every group member. Everyone has particular areas where they excel, and when you combine those areas like a giant transformer, you get something as powerful as…a giant transformer.

Overall, we came out the other side with something we’re very proud of, and got our first glimpse into self directed team development. You also get an accurate representation of everyone’s character when working in close quarters for a week straight on a challenging project (Imagine what happens after a year or more?)

I feel very fortunate to have had the opportunity to work with this crew. We laughed, we almost cried, and most importantly we learned.

--

--