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.

While I was at it, I performed some very (very) slight modifications to make Gibber.lib.js play nice with p5.js, the newly released port of Processing to JavaScript. Although there already is a p5.sound.js library, I’d argue that, like Gibberish, it’s too low-level for music making; it lacks the elements I listed previously: theory, synth presets, and easy sequencing. However, it’s better for sound effects and whatnot as it uses buffer-processing with browser-native audio nodes, while Gibber performs per-sample processing using JavaScript and is thus less efficient (although arguably more flexible).

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:

http://gibber.mat.ucsb.edu

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

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!