The Web Audio API provides graph based API for audio generation and processing primitives with a focus on high performance and low latency. For custom processing that is not covered by the builtin native audio nodes, it provides a ScriptProcessorNode whose processing is determined by a Javascript function. Though the ScriptProcessorNode is presented like any other node type by the API, its behaviour differs from the other native nodes in some fundamental ways. This post examines some of these differences using a simple chime model as the use case, and derives some suggestions for the Web Audio API specification.

Here is a demo web app for exploring rāgās and their bhēdams.

Roman text with a few choice diacritics are a common need when writing about Indian classical music. Creating unicode text with diacritics that can be ported between applications is in general a pain. So, I made a small in-browser app that serves as a scratch pad for common diacritics.

Google has open sourced the Tuna set of effects used in their Jam with Chrome project. Here, I collect some thoughts about the code design decisions for their effects framework, since I myself have written Steller.

“eval is evil” has become a maxim repeated in the Javascript community. Douglas Crockford, in Javascript: The Good Parts, rightly advises against hidden and explicit uses of eval for security and clarity reasons. Now, I find eval useful to implement DSLs in Javascript. The in-browser CoffeeScript compiler wouldn’t be possible without eval (directly or indirectly). So, in this post, I wish to explore what appears interesting about eval that is relevant to building such DSLs.

JSON has become a kind of de-facto standard for sharing data among services on the web. The Lisp folks have enjoyed this luxury ever since … well ever since McCarthy made the language and his student implemented an interpreter for it. What’s more, they have also had the luxury of using the same syntax for sharing logic .. and in fact take it for granted. This post is a proposal to bring that “luxury” to the web programming world.

Status: Draft. Comments welcome.

Scheme and Lisp have for long had powerful meta-programming abilities due to the syntax of their language being the same as the syntax for the main data structure supported by the language - the humble list. These languages are therefore well suited for inventing smaller special purpose “domain specific languages.

Javascript, on the other hand, has a “full blown syntax” that makes meta-programming not for the faint of heart. One consequence of the lack of such ability is that developers have not had the benefit of the abstraction possible through small special purpose DSLs.

Here, I outline an approach for creating DSLs in Javascript using the now prevalent JSON format that is native to the language. The initial part tries to explain the kinds of scenarios in which one might consider building a DSL, which is important to have an idea about. Later, I get into the actual representation using JSON.

Closures and variables have a strained relationship in Javascript that causes much confusion among newcomers and results in hard to spot bugs even for experienced JS coders. It is good to have a clear and accurate “mental model” of this relationship using which you can correctly predict what would happen with any given piece of code.

I came up with such a mental model a while back and posted it on Hacker News … which I reproduce here.

If you have been programming in Java and C++ for a while and are used to thinking about problems in terms of classes and inheritance, you may find yourself struggling with Javascript since it has only objects. This post is to – a) provide you with a perspective on why programming with only objects is powerful and b) show you how to translate the class-based concepts you’re used to thinking in into the Javascript world.