A few events coming up in the next couple of months. First, a long-form performance (~ 1 hour?) on October 26th as part of the ACADIA Conference (Association for Computer Aided Design in Architecture) in Los Angeles. I’ll be performing during their hackathon session: http://2014.acadia.org/hackathon.html
Next, multiple performances as part of the ACM MultiMedia Conference in Orlando. I’ll be performing twice a day on the 5th and 6th of November as part of the interactive arts program. I’ll also be presenting a long paper on Gibber on the 4th. http://acmmm.org/2014/
Most importantly, I’m hoping to release a significant refactoring of Gibber sometime in the next couple of weeks before all this happens…
I’ve had requests from a couple of faculty members at different universities to bring the audio portion of Gibber into its own library so that it could be used outside of http://gibber.mat.ucsb.edu. I had always intended Gibberish to fill this role, but Gibberish is fairly low-level and doesn’t come with a number of Gibber’s features that make it easy to get started making music:
- Basic music theory
- Synth presets
- Simple sequencing
I think those three elements in Gibber really do speed up the process of making music, as opposed to making DSP graphs. With that in mind, I’ve gone ahead and created Gibber.lib.js, which can be used inside of any web page. It can also be used inside of node.js thanks to the excellent web-audio-api module by Sébastien Piquemal.
Please try out p5.gibber.js and Gibber.lib.js and let me know what you think!
I’ve been hard at work on a new version of Gibber. It’s got some features I’m pretty excited about:
- Live coding of GLSL shaders (vertex and fragment)
- A 2D drawing API primarily based on the HTML Canvas context
- Some really nice mapping abstractions that make it simple to map audio to graphics and vice-versa, as well as making it easy to setup interactive controls.
- A database backend so users can publish files and browse other peoples sketches (now known as giblets)
- A chat system that also allows realtime collaborative code editing (like Google Docs) and remote code execution for networked live coding performances
- Improved audio performance by including the newest version of Gibber, which also has some extra ugens to play with
- A module system so that end-users can easily extend Gibber and share their extensions with others
- Improved error reporting with line numbers via an extra parsing stage
- Mouse and keyboard bindings
- Integration with Interface.js and Interface.Server
Ack. There are too many features to list them all. Those are the important ones though. Gibber 2.0 is not quite ready for prime-time, but it’s getting close. My main task at the moment is to work on the publication system / browsing of publications. You can try out the new version here:
There’s also a new forum there… I’ll probably closing the forum here in favor of using that one. Let me know what you think! – Charlie
The newest version of Gibber is now live, and contains a number of substantial improvements:
- new default demo song
- new minimal color scheme
- a pretty slick freesound integration (if I do say so myself), with an included tutorial
- more graphics demos
- code fades when you’re not typing if you are using graphics (thanks to livecodelab for the inspiration)
- beatboxing drum kit demo is now included (thanks karl)
- electronic drum kit is now used by default by the Drums object
- boids / flocking audiovisual demo
- various bug fixes
Try it out!
A ambient performance that mostly consists of sampling and layering the output of Gibber on top of itself repeatedly.
This is a recreation of a performance I did at a bar last week in downtown Santa Barbara. It uses the Gibber monosynth a bunch and has some granulation at the end. It also has a few mistakes, most notably at the start of the trumpet part.
What was especially nice about this performance (as opposed to previous ones) is that I didn’t have to worry about CPU usage at all, thanks to the new custom-written audio backend for Gibber. Even with screen capture software running (which takes quite a bit of CPU) there weren’t any glitches.
Here is my latest performance recording; the new Gibber default script is based on tweaks to this performance. It makes extensive use of Karplus-Strong and lots of flanging. It also shows the new verbose constructor syntax for objects, where you can pass any parameter to the constructor by name. There’s still a few objects I have to implement this for…
I’m feeling reasonably confident that this is how the Gibber syntax is going to look, and thus, getting closer to removing the “Beta” label and publicizing Gibber. Please let me know if you have feeedback!
I’ve made some small syntax changes over the past few days. More importantly, I’ve dramatically cut down the CPU Gibber uses by implementing a much smarter sequencing algorithm. After viewing the original Gibber performance, which maxes out the CPU at the end, I decided to take another go at a performance using some of the same ideas but trying to make things move a little quicker.
I also performed a variation of this at a composition forum today at UCSB… the first Gibber public performance.
Here’s my first stab at a Gibber performance. There is a lot of low-frequency content that will not be heard on laptop speakers…
This post starts my official announcement of Gibber, a new browser-based, live coding platform. My goal for Gibber is to create a super simple syntax for musical live coding performances that can also be an educational tool. I think there are some pretty interesting selling points for a browser-based implementation, such as automatic updates and easy networking. The browser provides a lot of affordances and I’m looking forward to exploring interactivity in the context of live coding.
Here’s a screenshot, primarily to provide a small amount of color to this blog entry. Please try out Gibber and be in touch in the forum!