DAVID RICE

Software Developer

+44 (0) 7590 538 303

46 Hill Street
Belfast, Northern Ireland
BT1 2LB

Patchblocks

23 Jan 2014 {View Comments}

So I ordered two patchblocks by supporting their kickstarter campaign and they arrived just before the holidays, but I only got the chance to play with them last week!

Myself (@davidjrice) and @kierangraham sat down recently to play with these and had so much fun I wanted to share with you all. Hopefully you find it interesting and maybe gives someone ideas for future hacking.

I’d like to quickly point out that yes, the readability of my blog sucks. I’m workign on it, but till then here’s a gist of the article

Setting Out

We took them out of the boxes and started trying to get something working. We were worried the units weren’t working at all, but it actually had just been so long since they shipped to me they’d ran out of battery. So we realised you needed to plug them in via USB first to charge thankfully that was quite a quick realisation, however we were pretty perplexed when still, nothing would happen.

A wee LED being on is getting somewhere though so we weren’t put off. We then realised you can’t charge the blocks and run them (play audio) at the same time. A-ha! Took quite a bit of digging but we found a forum thread indicating that. (TODO: find that article and link up!)

Up and Running

So we needed an idea, what would be a cool wee project but actually, first. Hold on. What’s actually possible with these wee yokes? So we decided to check out some other patches people had done. http://patchblocks.com/patches and we made sure to sort them by rating. sorry I can’t link you directly to that as it’s sorted client-side!

Right up near the top a few caught our attention but the first ones were definitely dubsiren and Party Starter we came here to make noise right? So those seemed like obvious first choices to… ermahgerd these are awesome.

At some point during getting these to work and starting to understand the patchblocks software and UI we fully realised the amazing-ness of what they were, we hadn’t even made a noise yet well, other than some “general excited noises” probably more akin to a pair of highschoolers and that gradually increased until it was deafened out completely by awesome dubstep noises. Yes!

Although that youthful feeling was dampened slightly by as we were quickly reminded by some gurgles from Kieran’s wee baby that it turns out babies don’t like loud noises while they’re sleeping. Jury’s out wether he like’s dubstep or not but we’ll see. Here, can we use the baby monitor as an input… hah.

This was great but we had a few other general problems getting setup later as we were constantly reconfiguring and swapping our blocks around.

  • we constantly had orientation problems and having to remember which way is out
  • also having to turn the device off and on again after having it connected to the USB. Having a separate indicator for on and charging states and moving the power switch to be a button would solve this I believe.

Understanding

We then took some time to try and understand the UI we really found the help option (up there under “View” in the menu bar) crazy useful and should be on by default! we started just following lines and deconstructing the patches we’d managed to load to see how they worked. The next big thing was finding out there were tooltips on input/output blocks if you hover over them. At this point we totally knew what was going on and now the real fun could begin.

Hacking

So back to the question, what’s cool? Well we hadn’t seen much info about using two blocks together wait? I thought it could do that, can it not do that? well let’s find out. Spoiler alert: it can. Anyway, we were confused when we had two cool sound blocks seperately but when plugging them together nothing happened damn!

Looking into it further we realised that the digital and analogue audio outputs are independent. Awesome. Hmm, so how do we go about using two blocks together though?

Collaborative Blocks

So we then figured out we need to think of the entire block (physical) as just an input/output block (like in the editor UI) exept at a higher level. But the question still remained, why didn’t our two blocks work together? Turns out it was because the patches we downloaded just didn’t send audio to both analogue and digital outputs, just analogue in the ones we tried.

So we then modified both of our patches to just split the audio signals and send to both. That was easy. This stuff is not just cool, it’s easy. That’s even cooler!

but that wasn’t all we needed. We need to then get the signal into the other block, turns out that was easy to it just needed us to think a bit differently. Using a mixer block we were able to just take all our effect logic and drag it to one side and then added handling for the audio input as it turned out, in both of our patches nothing was being done with it, yet.

So having done that we plugged the boxes together and, yes it was a magical experience and many high-fives were had all around. I’d love to say it worked first time but we actually had it plugged in the wrong way. Haha.

Mixing it up

Having two blocks that generate noise isn’t really that cool though so we decieded to think of one of the blocks as a source and the other as a kind of pass-through effect / mixer. We also realised we could then apply the same principle to the noise generator block (dubsiren) and allow it to take input on the line in (from one of our macs) so we could get some backing music to play with.

I then created a wee patch using the delay effect, mapping the controls to the variables available (in the editor) for the delay block and also taking an audio signal in from both the digital and analogue inputs.

Much hacking, one beer and many high-fives later we had it all working.

The Future Editor

So I have quite a few general thoughts on some of the editor and UI, here goes.

  • would be good to see inputs/outputs or the “potential” of the device not being used by a given patch
  • sharing patches isn’t yet optimal, binary files are awkward and hard to collaborate on, how can we improve this. I would suggest bringing github into the mix and being able to use a git repository for a patch (or multiple patces). Plaintext is the future and I’m sure there’s a way we can do this.
  • make the “help” mode on by default, at least until more information is visible in the UI to allow it to not exist!
  • for example, visible labels or iconography for the input/output boxes (not having to hover to remember which one it is)
  • being able to group parts of a patch into a larger thing that takes input/output. Allowing us to hide implementation and make complex patches simple to delve in and understand
  • the editor could be able to pull a list / browse view and install patches right there in the editor (this would be great to be able to see what kinds of things each patch does)
  • categorising patches (probably automatically) to see what kind of patch it is would be a great thing and allow for people to go get inspiration from similar patches

Probably more ideas but I’m running out of steam tonight, I’ll try to add more as I think of them :) Someone from patchblocks should definitely reach out to GitHub as I know this would really interest them and they would love to help you use gh. I like to think of them as not just somewhere to put my code but as infrastructure for a lot of the software I build today.

Hardware / Audio quality

So, not sure if it’s just the dirtyness of the delay effect I was using (or the fact I have dropped it several times, doh) that the sound is a bit flakey. Perhaps I haven’t boosted the audio out levels enough or something. I’d love to get some feedback at some point (TODO: I’ll need to upload these patches we made and hopefully you can review them).

Otherwise yeah, we need to figure out how to make these less droppable, or more drop friendly. I was flipping it so much to remember which was the IO analogue in that dropping it became a regular occurance. Which was fine over at Kieran’s cause he has carpet but the blocks do NOT like my wooden floor.

Finally

I think you get the picture, I love these wee things and I’ve only got to spend a few hours one evening figuring this stuff out but it was all the easier and more fun working on this with a good mate and I think we actually learned a lot while playing with these (even though me and Kieran do or at least should know a thing or two about these technology things).

I actually think the style of node-based style of programming and constraints of the editor forced us to think of new ways of solving problems that I already know how to apply in my day job and for that I am grateful to you for that (and why I have taken the time to write this) as I also want to share these with the rest of our team at Rumble and hope they have a similar experience.

As such I really think these are not only fun but great learning tools and with a bit more robustness and user friendly-ness could appeal to not just musically minded geeks like me but as a great teaching tool for children. Or anyone interested in programming or learning programming. Having some sort of fun stimulous as the output of your work really helps to keep attention and deliver immediate results and happiness!

After writing this I’m really excited about playing more with these in the future (even more than after mucking about with them that nigth) but I just realised I’ve been so passionate about them I’ve lent all mine to friends to have a go with. Thankfully, being slightly compulsive about things I’m glad I have.

The state of mobile WebGL

17 May 2013 {View Comments}

As of the time of writing WebGL is not very well supported on mobile devices However, it is [seriously](http://seriouslyjs.org) awesome (seriously). You can get an idea of device capability from these tools. * http://caniuse.com/webgl * http://get.webgl.org After reviewing. It would appear Android or CocoonJS is the way to go for now. Support from all other browser implementations should hopefully not be far behind. Going to need to get an Android tablet then to test these out. The Google Nexus 10 looks to be the best option currently due to it's [epic GPU performance](http://reviews.cnet.com/8301-19736_7-57581030-251/the-fastest-android-gaming-tablets/). Some Android phones appear to [vastly outstrip current tablet performance](http://www.androidbenchmark.net/cpumark_chart.html). Basically, it's not something to ship production code in right now, but it's time will come very soon and we have the tools to be developing and testing our creations till then. ### iOS * WebGL is only available in iAds, not in a UIWebView or Mobile Safari. * There is a shim browser that can be used for testing [WebGLBrowser](https://github.com/benvanik/WebGLBrowser). *However performance is significantly lacking and not a reflection on the performance of UIWebView (If it implemented WebGL)* * Chrome doesn't work * Opera mini either ### Android * Native Android WebView does not support WebGL (Android 4.2) * Firefox Beta does * As does Chrome Beta Apparently there is work to make Chrome the WebView renderer in future releases. * For now what looks promising is [ChromeView](https://github.com/pwnall/chromeview) a replacement of the Android WebView with the latest Chromium build. ### Firefox OS * WebGL will be enabled by default on Firefox OS * However, "Firefox" handsets have yet to ship * It can be run on Android devices, but tablet support is lagging behind ### CocoonJS A promising alternative is [CocoonJS](http://3d.ludei.com), which has an (apparently) native performance HTML5 platform implementation. That works cross platform on Android and iOS.

Faster Rails 3 Deployments on Heroku

14 May 2012 {View Comments}

Deployments on Heroku have gotten slower since the cedar stack, Rails 3.2 and the asset pipeline. Don’t get me wrong, I love all of these things like I love Street Fighter II, we’ve got over the novelty of new, just give me the turbo edition.

Benchmark

For the test, some things were kept controlled each time

  • Emptied the S3 bucket (for asset_sync to fully run)
  • No new bundled gems
  • No migrations

So, using a stupidly basic Rails application (we use for testing releases of asset_sync) https://github.com/rumblelabs/asset_sync_test_3_2

git push heroku  0.02s user 0.01s system 0% cpu 1:27.61 total
git push heroku  0.02s user 0.01s system 0% cpu 1:28.91 total
git push heroku  0.02s user 0.02s system 0% cpu 1:34.35 total
git push heroku  0.02s user 0.02s system 0% cpu 1:28.45 total
git push heroku  0.02s user 0.01s system 0% cpu 1:26.65 total

=> [87.61, 88.91, 94.35, 88.45, 86.45]

AVERAGE: 89.154

Note: yes this app I am testing with is only “just” more complicated than rails new, so doing some timing on a completely fresh Heroku app would give a more accurate estimate.

Custom asset precompile task

My first idea was to only run rake assets:precompile:primary not for the faint hearted, but if you have built your application correctly to use digested assets throughout, it’s a no-brainer.

This ruby buildpack allows configuration of the task to execute for precompiling assets ENV['RAILS_ASSETS_PRECOMPILE_TASK'].

heroku config:add BUILDPACK_URL='https://github.com/rumblelabs/heroku-buildpack-ruby.git#custom_asset_precompile'
heroku config:add RAILS_ASSETS_PRECOMPILE_TASK=assets:precompile:primary

git push heroku  0.02s user 0.01s system 0% cpu 1:13.54 total
git push heroku  0.02s user 0.01s system 0% cpu 1:18.94 total
git push heroku  0.02s user 0.01s system 0% cpu 1:13.07 total
git push heroku  0.02s user 0.01s system 0% cpu 1:21.01 total
git push heroku  0.02s user 0.01s system 0% cpu 1:13.80 total

=> 73.54, 78.94, 73.07, 81.01, 73.80

AVGERAGE: 76.072

Woot! That’s an average saving of 13.082 seconds per deploy. Nice.

Note: I had to add an extra hack to get asset_sync working on deploy as we changed the precompile task.

Debug Buildpack

I was wondering if I could save even more time… so here’s a debug buildpack with a quick hack to output timings with every logged message.

heroku config:add BUILDPACK_URL='https://github.com/rumblelabs/heroku-buildpack-ruby.git#buildpack_debug'

The output looks like the following:

➜  myapp git:(master) git push heroku
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 280 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)

-----> Heroku receiving push
-----> Fetching custom buildpack... done
-----> Ruby/Rails app detected
======> 2012-05-14 06:17:13 +0000
-----> 0.000107585 : Installing dependencies using Bundler version 1.2.0.pre
       0.073559081 : Running: bundle install --without development:test --path vendor/bundle --binstubs bin/ --deployment
       0.734531922 : Using rake (0.9.2.2)
       0.735997602 : Using i18n (0.6.0)
       0.736449923 : Using multi_json (1.3.4)
       0.737163615 : Using activesupport (3.2.0)
       0.737576858 : Using builder (3.0.0)
       0.738049721 : Using activemodel (3.2.0)
       0.738518515 : Using erubis (2.7.0)
       0.739293731 : Using journey (1.0.3)
       0.739688269 : Using rack (1.4.1)
       0.740488658 : Using rack-cache (1.1)
       0.740923127 : Using rack-test (0.6.1)
       0.741390205 : Using hike (1.2.1)
       0.742001929 : Using tilt (1.3.3)
       0.742994436 : Using sprockets (2.1.2)
       0.743355851 : Using actionpack (3.2.0)
       0.743878451 : Using mime-types (1.18)
       0.744305491 : Using polyglot (0.3.3)
       0.744781819 : Using treetop (1.4.10)
       0.74568785 : Using mail (2.4.1)
       0.747632709 : Using actionmailer (3.2.0)
       0.747760727 : Using arel (3.0.2)
       0.748128902 : Using tzinfo (0.3.32)
       0.748552448 : Using activerecord (3.2.0)
       0.74907975 : Using activeresource (3.2.0)
       0.749463748 : Using excon (0.13.4)
       0.749979571 : Using formatador (0.2.1)
       0.750377764 : Using net-ssh (2.3.0)
       0.750844938 : Using net-scp (1.0.4)
       0.751279192 : Using nokogiri (1.5.2)
       0.760296186 : Using ruby-hmac (0.4.0)
       0.76162912 : Using fog (1.3.1)
       0.778984194 : Using asset_sync (0.4.0) from git://github.com/rumblelabs/asset_sync.git (at master)
       0.779744754 : Using coffee-script-source (1.2.0)
       0.780276683 : Using execjs (1.3.0)
       0.78084057 : Using coffee-script (2.2.0)
       0.781371467 : Using rack-ssl (1.3.2)
       0.781935092 : Using json (1.6.6)
       0.782476196 : Using rdoc (3.12)
       0.783709004 : Using thor (0.14.6)
       0.784896558 : Using railties (3.2.0)
       0.785776908 : Using coffee-rails (3.2.2)
       0.786299563 : Using jquery-rails (2.0.1)
       0.787018031 : Using pg (0.13.2)
       0.787546051 : Using bundler (1.2.0.pre)
       0.788116001 : Using rails (3.2.0)
       0.788627757 : Using sass (3.1.15)
       0.790148688 : Using sass-rails (3.2.4)
       0.790633587 : Using uglifier (1.2.3)
       0.793843146 : Your bundle is complete! It was installed into ./vendor/bundle
       0.818492178 : Cleaning up the bundler cache.
-----> 2.714365124 : Writing config/database.yml to read from DATABASE_URL
-----> 4.776435204 : Preparing app for Rails asset pipeline
       4.77724766 : Running: rake assets:precompile
       22.609565246 : AssetSync: using default configuration from built-in initializer
       22.609565246 : AssetSync: using default configuration from built-in initializer
       22.609565246 : AssetSync: Syncing.
       22.609565246 : Using: Directory Search of /tmp/build_1w8jlj9e4aoaz/public/assets
       22.609565246 : AssetSync: Done.
-----> 22.63974359 : Rails plugin injection
       22.639908428 : Injecting rails_log_stdout
       22.875385302 : Injecting rails3_serve_static_assets
-----> Discovering process types
       Procfile declares types      -> (none)
       Default types for Ruby/Rails -> console, rake, web, worker
-----> Compiled slug size is 18.8MB
-----> Launching... done, v48
       http://myapp.herokuapp.com deployed to Heroku

To git@heroku.com:myapp.git
   d2b28d4..d0fc25e  master -> master

Looking at the output we can see that my custom buildpack timings only kick in within =====> CUSTOM BUILDPACK

➜  myapp git:(master) git push heroku
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 280 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)

-----> Heroku receiving push
-----> Fetching custom buildpack... done
-----> Ruby/Rails app detected

=====> CUSTOM BUILDPACK

-----> Discovering process types
       Procfile declares types      -> (none)
       Default types for Ruby/Rails -> console, rake, web, worker
-----> Compiled slug size is 18.8MB
-----> Launching... done, v48
       http://myapp.herokuapp.com deployed to Heroku

To git@heroku.com:myapp.git
   d2b28d4..d0fc25e  master -> master

Conclusion

Taking my baseline measurements from earlier, we have “control” of about 23 Seconds of heroku deploy time out of the average of 89 Seconds measured. Therefore a saving of 13 Seconds is then pretty good.

That’s then putting an estimate that Heroku’s baseline deployment time is around 66 seconds.

So we may be able to cut our asset compilation time in half with that custom asset task buildpack. However with a baseline of 66 seconds spent “in Heroku” we can’t really get much faster than that without some help from Heroku, c’mon lads, lets get back to sub-minute deploys! As this is just the basics of an app, anything more complicated and you could easily be talking several minutes for a deploy.

Am going to implement some better statistics gathering of all our continuous deployments at Rumble. Would be very interested in hearing what other people’s average deploy times are.

Rails 4

As an aside. I recently started some work on a pull request to make rake assets:precompile faster by default in Rails 4 by making digested assets (rake assets:precompile:primary) the default and killing off the public directory entirely, moving all of those static files to app/assets.

Upgrading to Ruby 1.9 and Rails 3.2.0.rc2

19 Jan 2012 {View Comments}

Last year was a long year of upgrades for a lot of our clients at [Rumble Labs](http://rumblelabs.com). Going into this year, most of our Ruby work is all running on Ruby 1.9.2. A lot of those projects are Rails applications and we managed to have most of those running on Rails 3.0.x. From an OCD point of view, this pleases me. Some of the applications we're working on for clients are now pretty big, Rails is getting bigger and there are more libraries out there. The combined effects of which are starting to feel a little slow. ## Ruby 1.9.3 [Ruby 1.9.3](http://www.ruby-lang.org/en/news/2011/10/31/ruby-1-9-3-p0-is-released/) is the latest stable release of the 1.9.x series. It's been great to start taking advantage of a few of the niceties in Ruby now since the move from 1.8.x. With Ruby 1.9.3 it's all about the speed. I tested running `time rake -T` before and after the upgrade in a number of our projects. Roughly speaking I saw a reduction of 50% in the time it took. This is **great!** If you use [RVM](http://beginrescueend.com/) (and I would recommend you do, or something like it) you can install with the following rvm install 1.9.3 ## Bundler A quick aside in case you haven't heard. The latest beta version of bundler is super fast compared to the current stable release. You can install the latest version of bundler (in your global gemset) with the following. rvm gemset use global gem install bundler --pre ## Rails 3.2.0.rc2 The latest version of [Rails 3.2.0.rc2](http://weblog.rubyonrails.org/2012/1/4/rails-3-2-0-rc2-has-been-released) has a few changes, the biggest of which is some performance improvements to boot time, development mode and asset compilation. For our applications running on 3.1 it was quite a painless upgrade (unlike going from 3.0.9 -> 3.1). # add to your Gemfile gem 'rails', '3.2.0.rc2' # I like to create a new gemset for each specific Rails version rvm gemset create rails-3-2-0-rc2 bundle update ## Heroku What would be the use of upgrading all these apps if we can't try them out, in production! Thankfully it is possible to run both Ruby 1.9.3 and Rails 3.2.0.rc2 in production on [Heroku](http://www.heroku.com) thanks to their new **Heroku Labs** features, specifically their [user_env_compile](http://devcenter.heroku.com/articles/labs-user-env-compile) which allows us to set configuration that will be respected by the heroku build packs. **Note: not for the fainthearted** Heroku mention they may remove any feature of Heroku Labs without warning, so be careful! # Enable Heroku Labs heroku plugins:install http://github.com/heroku/heroku-labs.git # Enable the user_env_compile add-on (for each app) heroku labs:enable user_env_compile -a myapp # Enable 1.9.3 heroku config:add RUBY_VERSION=ruby-1.9.3-p0 That should be your Heroku app enabled to run on Ruby 1.9.3. Next time you push to heroku you should see something like the following in the compile output. -----> Heroku receiving push -----> Ruby/Rails app detected -----> Using RUBY_VERSION: ruby-1.9.3-p0 ## Conclusion I've upgraded about 10 apps so far and have yet to come across any showstopper bugs. It doesn't take too long to do either. So, definitely worth the performance improvements you will gain! Happy upgrading.

Older Posts

«