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
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.
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.
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?
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.
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.
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.
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
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]
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
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
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.
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 email@example.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 firstname.lastname@example.org:myapp.git d2b28d4..d0fc25e master -> master
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.
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