My talk at Rubyconf 2009 on using Ruby for audio projects was posted. I focus on frequently unfamiliar open source libs that people may find useful and make reference to a number of BArCMuT presenter’s projects. There’s a lot of talk about using Ruby and Chuck, SuperCollider, solving sync issues, etc, etc. You can find the source code for the presentations on github here

One major Ruby discovery since then is that Charles Nutter (a primary author of jRuby) has a version of Ruby that uses static typing, runs on the JVM, and runs at the speed of Java! It’s called duby and it’s available here

Over the last year I have been contemplating how to further democratize the Bay Area Computer Music Technology group ( BArCMuT ) for more co-organization and stronger collaborative relationships, while maintaining a high quality of events. On my way back from NAMM this idea for writing a constitution for BArCMuT bubbled up. The only receptacle for the idea on South West was this slightly waxy emergency bag.

Since then I have refined the constitutions guidelines and listed them below. If you need to skim this article just skip to the “BArCMuT Constitution” section. Before I get to the guidelines, I would like to share some background on how I arrived at the new form for BArCMuT…

Some Background On BArCMuT’s Inspiration

In 2003 I attended a Dorkbot event in which Tim Thompson presented Key Kit game controller hacks and Dr. Friendly presented a crazy wavelet feedback algorithm. My friend Zu who is an entertainment magazine editor in Poland asked me what I thought the coolest thing in San Francisco was and I told her about Dorkbot. I meant it.

Then, in early 07 at the SF Ruby Meetup I had my mind blown by awesome technical talks by Chris Wanstrath (now Github co-founder) and others. These events made me wonder “why doesn’t a group like this exist specifically for the computer music community?”.

I had recently quit my job at Digidesign thinking that I was going to develop this weird ontological DJ remixing algorithm while I contracted. I was constantly looking for the right technology to build it in. My max patches had gotten un-managable with 100+ sub-patches and lots of logic that was more suited to procedural programming. Java audio sucked. Chuck – what was that? Csound was cumbersome. I was unsure about the Supercollider licensing. Ruby had no audio libraries. Python was a little better supported but less familiar. I wanted to hear people tell me about this stuff first hand.

I started the Bay Area Computer Music Technology Group in the fall of 2007. On the first night, the event magically came together as community leaders like Tim Thompson, Ge Wang, Vlad Spears, Scot Gresham Lancaster, and David Wessel decended on the Space Gallery in the Tenderloin of San Francisco. Nobody seemed to care about the street noise as we watched Ge’s chuck demo while sitting on church pews next to a recently assembled indoor skateboarding ramp.

The group took off after that night. Now there are over 500 members and we have had over 35 succesful events all over the Bay Area (Stanford CCRMA, Berkeley CNMAT, Mills College, Digidesign, Dolby, Maker Faire, GAAFTA etc). The presenters have been world class awesome and many of the members could just as easily be presenting or audiencing. I typically have to warn presenters that they will need to answer some very difficult questions from the expert tribunal refered to as the “audience”. Lots of people have told me how they acquired a job, met collaborators, changed product specs, or began an academic path at a BArCMuT event. This makes me happy and excited.

Fast forward to 2010. The community has gained a lot of great momentum with other groups like Phasor, Overlap.org, Learn Tech, Share San Jose, PyGame, and others. We’ve all been influencing eachother a lot and starting new projects. At an event at CCRMA, Tim Thompson said how BArCMuT had been one of his inspirations for starting the Share San Jose group. This was both nice and funny because I had actually been inspired by his talk at Dorkbot to create BArCMuT in the first place. I think this illustrates how a cool community can inspire itself.

Despite the fact that our community really is a headless web, BArCMuT has formed as a benevolent dictatorship. In 2010 I would really like that to change. To do that I am symbolically stepping down as benevolent dictator and setting up a structure for co-organizing the group (aka the constitution). In fact, it’s weird to even think of the group as just being “BArCMuT members”. BArCMuT is actually just a tool for the community to organize itself, and I would like to re-org BArCMuT to reflect this.

What’s In It For Me

Part of cooperation is understanding why the people you are cooperating with are doing what they do.

At the bottom of my South West emergency bag BArCMuT constitution, there’s a section titled “WIIFM” (an abbreviation for “What’s in it for me”?). At the risk of being overly explicit, let me share why I organize BArCMuT:

• I want to participate in a community that I help to create
• I want to meet cool collaborators and make cool s@&#%!
• I want to know about awesome new electronic art technology, libraries, and techniques
• I want you to think that I am cool and well organized and include me in cool projects
• I want you to return my phone calls and emails

Conspicuously missing is any sort of profit motive. BArCMuT is an Open Source inspired organization, vis a vis Eric S. Raymond. The way I see it, collaboration creates value through network effects rather than through hording.

To get semi-technical, personal sub-optimization (greed) in a commons reduces the benefit of the commons as a whole and ultimately limits its abilities to benefit community members thus trashing the commons. For the mildly cynical or economics obsessed, building a commons can be thought of as “enlightened self interest”. But really, this technical framing doesn’t capture the spirit of why I built BArCMuT. For those who follow their heart, this approach can be described as just feeling good and creating community.

Envisioning The Computer Music Commons

To further the goals that I listed and I believe that many community members share, I want to reform BArCMuT as a durable commons for the computer music community. My strategy from the beginning has been to remove any frictions to having a neutral commons – such as such as pursuing direct monetary gain or gratuitous advertising. Now that BArCMuT exists as a community asset, the next step in reducing friction on the commons is to change the structure of BArCMuT from a tree to a graph.

Part of the strategy for limiting the politics that can exist within a group, is to limit the scope of what BArCMuT does. I hope to reduce politics by: not having a shared treasury, only allowing free events, and limiting the scope to events relevant to learning about or creating electronic arts (e.g. no concert audience promotion). BArCMuT definitely should support the excellent commercial work that is being done within our community ecosystem, but as a commons it should be clearly differentiated from these ventures.

The BArCMuT Constitution

Every group needs some guidelines – the more lightweight the better. Here’s my first attempt at codifying a group constitution for a co-organized BArCMuT. Please post your feedback.

Goals of the constitution:

• Create a durable commons that is not reliant on a single member (i.e. not a benevolent dictatorship run by me)
• Further enable the Bay Area computer music community to stay informed about technical talks, hack sessions, and community events
• Create a neutral commons for members to find collaborators, employment, teachers, and students
• Filter events to maintain a high level of quality

Participants:

• There are four general participant types: co-organizers, hosts, presenters, and attendees
• Initial co-organizers will be invited by me
• Additional co-organizers can be added or removed by an 80% group vote (I could use some additional advice on the official decision making process).
• Co-organizers can schedule official BArCMuT events if they fit the guidelines. An official BArCMuT event is one that sends RSVPs and is listed on the main page of barcmut.org
• Co-organizers, hosts, and presenters are encouraged to list their logo on the barcmut home page

BArCMuT event guidelines:

• events must include a technical talk about electronic art technology
• events must be free to members
• events must be in the Bay Area
• hosts, presenters, and co-organizers are encouraged to mention upcoming electronic art events (free or not), job positions, and products. Although community relevant promoting is encouraged as a vital part of the ecosystem, this should not dominate the event.
• co-organizers can list events (even if they are not official BArCMuT events) in the BArCMuT calendar. It would be great if we could announce all upcoming events listed in the calendar at official BArCMuT events.
• there will be no shared treasury or treasurer for BArCMuT
• venues, presentations, and co-organization are offered for free
• expenses will be payed by co-organizers or by donation (e.g. for security gaurds, snacks, etc.)

I am inviting trusted community members who I have organized events with in the past to be BArCMuT co-organizers. These co-organizers can schedule events that fit the BArCMuT guidelines. These include:

• Ge Wang (CCRMA, Smule)
• Sasha Leitman, Linnea Williams, Carr Wilkerson (CCRMA)
• Tim Thompson (Share San Jose, Visual Music Meetup, ZeroOne)
• David Wessel, Adrian Freed, Andy Schmeder (CNMAT)
• Barry Threw (GAFFTA, Overlap.org, etc.)
• Vlad Spears (Phasor, Overlap.org)
• Harry Tormey (PyGame, Digidesign)
• Chris Brown (Mills)
• Scot Gresham-Lancaster (Cogswell, The Hub)
• Rich & Moldover (Learntech, LoveTech)
• If you are not on the list and you think you should be let me know

A note about scheduling. If there are too many events (e.g > 4 per month) we may need to thin things out. One strategy would be to to list events that repeat frequently once as official BArCMuT RSVP events and then list them in the non RSVP calendar to be announced at other events.

Conclusion

In conclusion, I am excited about being part of more great events this year as a co-organizer. My plan is to work towards a durable commons through transparency and establishing light weight and usable guidelines. If I am doing something that seems to work against this plan, please tell me. I’m not perfect and I would appreciate the feedback.

Even before this article has been completed I have had some great conversations with other organizers about creating this commons. 2010 is going to be a great year for community!

Whither Javascript

Recently I have been working on a Rails project with lots of Javascript include complexity ( Ashbury Music Hall ). Here’s the challenge:

• Some larger libraries and plugins only need to appear on single pages (e.g. Thickbox, FCKEditor).
• Some Ajax page renders depend on core libraries (e.g. jQuery) but shouldn’t be loaded more than once by layouts and partials
• When Ajax page renders degrade to linked pages they may be in alternate layouts and include different Javascript libraries or have different load orders
• Rails partials load before layouts and potentially include Javascript files specified in them before core libraries
• Page and partial specific Javascript (e.g. myview/my_page.js ) presents even more complexity
• Pages appear to load faster if Javascript is loaded on the bottom of the page

Oh what a tangled web we weave.

Thither

The solution I arrived at is to specify sectional order of libraries, accumulate them, deduplicate them, and include them at the end of the page request. This allows definition of core libraries at the top of a layout page for all partials and inclusion of librararies in plugins on any view or partial without duplicate loading or core library omissions. To do this I defined two Application Helpers as follows:

# Use accumulate_js to accumulate javascript paths throughout the application
# it deduplicates them and then they should be included by calling include_accumulated_js
# at the foot of the page.
def accumulate_js(key, path)
  @javascript_list ||= {} 
  @javascript_list[key] ||= []      

  if path.class == Array || path.class == String
    @javascript_list[key].<<(path)
    @javascript_list[key].flatten! # for some reason + was not working properly for arrays
    @javascript_list[key].uniq!
  else 
    raise ArgumentError
  end
  @javascript_list
end

# call accumulate_js first to use the default @javscript_list instance var
def include_accumulated_js(order_array, path_hash = @javascript_list)
  result = "" 

  order_array.each do |key|
    next unless path_hash[key]
    result += path_hash[key].inject("") do |result, path|
      result += javascript_include_tag(path)
    end
  end
  result
end

Then wherever Javascript is called for a request (layout, view, or partial) the names of the libraries are accumulated:

accumulate_js(:core, ["jquery-1.3.2.min.js", "jquery-ui-1.7.1.custom.min.js"])
accumulate_js(:plugins, "beautytips/jquery.bt.min.js")
accumulate_js(:application, "application")

All load path strings from the public/javascripts directories are specified. The library order is maintained but additional loads are de-duplicated. Then all of the libraries are loaded at the foot of the document, ordered by type with a command like this:

include_accumulated_js([:core,:plugins,:application,:page,:partial])

For the specifics of what it does, here’s the rspec spec:

describe "javascript library acuumulation" do
  it "accumulates javascripts associated with a specific key" do
    accumulate_js(:core,["a","b"])
    accumulate_js(:core,"c").should == {:core => ["a","b","c"]}
  end

  it "can accumulate a list of javascripts used on a web page" do
    accumulate_js(:core, "library.js")
    accumulate_js(:core, "another/library.js").should == {:core => ["library.js", "another/library.js"]}
  end

  it "can take combinations of arrays and strings" do
    accumulate_js(:foo, ["lib1.js","lib2.js"])
    accumulate_js(:foo, "lib3.js")
    accumulate_js(:foo, ["lib4.js","lib5.js"]).should == {:foo => ["lib1.js","lib2.js","lib3.js","lib4.js","lib5.js"]}
  end

  it "raises an error if it is of an unknown type" do
    lambda do
     accumulate_js(:foo, 1)
    end.should raise_error(ArgumentError)
  end

  it "deduplicates and preserves order" do
    accumulate_js(:baz, ["a","b","a","c","b","c"]).should == {:baz, ["a","b","c"]}
  end
end

describe "including accumulated javascript" do
  before(:each) do
    accumulate_js(:foo, ["foo_1","foo_2"])
    accumulated = accumulate_js(:baz, ["baz_1","baz_2"])
    @result = include_accumulated_js([:baz, :foo], accumulated)
  end

  it "returns javascript includes" do
    @result.should =~ /script.*src.*javascripts\/baz_1.js.*type.*text\/javascript/ 
  end

  it "includes javascripts in the specified order" do
    @result.should =~ /baz_1.*baz_2.*foo_1.*foo_2/m
  end
  it "can handle nil values" do
    accumulated = accumulate_js(:foo, ["foo_1","foo_2"])
    lambda do
      include_accumulated_js([:baz, :not_in_there], accumulated)
    end.should_not raise_error
  end
end

Accolades

Marc Grabanski, excellent jQuery developer that he is, contributed his sage advice to this solution.

Epilogue

I might put this in a plugin and post to github, but just seems a little silly since there are only two helper methods. What think ye? If this blog post is good enough for you, then it’s good enough for me. Obviously, I’m busy enough that I’ve gone bonky and resorted to archaic english – but if you request a plugin or some other container I may be obliged.