Live Coding in CoffeeScript
bryanenglish.com
bryanenglish.com
Also, it's way more fully developed than audiolet, and seems to work way faster.
See also "livecodelab" and "gibber": http://www.sketchpatch.net/livecodelab/index.html http://www.charlie-roberts.com/gibber/
Gibber is multi-user live coding in the browser.
There are many more live coding systems here: http://toplap.org/
What exactly makes this "live" coding? As far as I can see, you have to press Esc to run the code. If this is considered live, what would be a non-live equivalent?
My understanding of live was that you see/hear changes as soon as you change the code, but I didn't find that to be the case here.
Very confusing, I feel like I'm fighting a losing battle since live coding sounds so similar to live programming, but the terms mean completely different things and arose in different contexts (live programming arose in a pedagogic context, live coding arose in a performance context) at about roughly the same time.
"and just starting to learn CoffeeScript, because it seemed rather cool"
This thought pattern is wholly flawed. "Seems cool" is not a reason to learn coffeescript, in fact there is no good reason except syntax fetishism, which is also not a good reason.
Live coding is absolutely everything about live feedback. This gives you access to performing in front of a live audience, but that is only part of it. It also allows new styles of collaborative programming, and exploring of ideas in composition.
Live coding is about using programming languages to manipulate running code, maintaining state (if there is any).
Check out the code in the "hacking perl in nightclubs" article that this one links to. The software it discusses takes on live updates without restarts or losing state (in fact, the code in the editor is part of the state). It also has an option to take on edits every keypress, but it's off by default, because it's impractical. Sometimes you just don't want 1 and 10 to be interpreted on the way to 100.
Live coding arose in an interdisciplinary context of music performance, pedagogy, media theory, psychology and computer science.
The thesis you link to is really excellent, but has shared roots with live coding and is referenced in the live coding literature.
> Live coding is absolutely everything about live feedback. This gives you access to performing in front of a live audience, but that is only part of it. It also allows new styles of collaborative programming, and exploring of ideas in composition.
This really isn't the point. The "live feedback" is not about performance, its not about new styles of collaborative programming, its not about composition of time-based media. It is simply a better way to debug your program, it is simply better feedback to the programmer while they are writing their program.
> Live coding is about using programming languages to manipulate running code, maintaining state (if there is any).
You've stated this differently before:
> For me, live coding is about live, end-user programming of time-based media. Live coders write software for themselves, and the timeline of software development is often shared with the end result. This brings both social and creative aspects of programming to the fore.
Now, imagine my frustration when I'm trying to promote a new way of debugging a program, and people say "we've heard about this before, but we aren't very interested in music." Do you understand why I'm frustrated? Live programming aims to change programming in general, you should be able to live program a web app, a map reduce program, an operating system, a compiler, anything! This is not the goal of live coding as I understand it.
> Check out the code in the "hacking perl in nightclubs" article that this one links to. The software it discusses takes on live updates without restarts or losing state (in fact, the code in the editor is part of the state).
But you see, that's where our disconnect is: LP is not just about updating code without losing state, its about changing the entire program's state as if the new code HAD ALWAYS existed. Simply preserving state is not good enough. Now in a dataflow language (like quartz composer), there is no state and you simply re-execute the new wiring; very easy. But if there is state involved, the problem becomes much harder. The live coding crowd hasn't done anything to solve that problem yet, and in fact, they don't really need to; it seems like preserving state is sufficient for your use cases.
> It also has an option to take on edits every keypress, but it's off by default, because it's impractical. Sometimes you just don't want 1 and 10 to be interpreted on the way to 100.
Did you ever watch the quicktime videos embedded in my 2007 paper? I did just that ('1', '10', '100') and the effect was quite nice; I got applause right there when I gave the talk at Onward. It is definitely a UX challenge, and Chris's discussion about steady frames, I think, is the key to a decent live programming experience. Also, Bret Victor's demos have no delay in them whatsoever; continuous feedback can be nice and exciting. Of course, we need to do a lot of UX and implementation work before it is actually practical. The live coding community has working systems today, you guys already have what you need; we don't, we just have a bunch of prototypes and demos (unless we count visual languages where liveness is easy).
> Live coding arose in an interdisciplinary context of music performance, pedagogy, media theory, psychology and computer science.
Sounds like a nice focused story to me :)
> The thesis you link to is really excellent, but has shared roots with live coding and is referenced in the live coding literature.
The important point to make about Chris's thesis is that it is very close to Bret Victor's demos and goals as stated in his learneable programming work. That this is a new way to understand code while we are writing code, the story is very narrow, nice, and easy to understand; there is no reason to expand it in other ways.
I can understand your frustrations, lets talk by email about establishing a clearer distinction between performance and more general contexts, if you don't mind. But I think not on the basis that they are completely unrelated, to me it makes sense to think of live coding in social situations (including lectures, dojos,conference talks as well as a/v performances and group music making) is an application for live programming languages.
I can agree reinterpretation per key press is useful in some very particular circumstances, but not others. The difference is not in delay, but in what constitutes an edit.
I think you want to provide feedback for each discrete or continuous action by the user. This is quite easy if we are relying on structured editing, but much harder for free form text. My current policy is to re-execute memoization units after each keystroke, though certain syntax and type errors can prevent the executed expression tree from changing (but then the feedback is a syntax/type error!). Getting live feedback also requires toleration to transient syntax/semantic/and execution errors, and to be fairly efficient. In this case, we should tolerate and react to '1' and '10', even if they lead to a program in a weird state (e.g., x - N, where N should be > 100), but you still want to show some kind of change. And this is where live programming is very different: the steady frame that we are viewing while editing should always CHANGE when we edit, meaning it should be focused on some execution result of the code being editing. Doing something without immediate feedback is being a sad panda.
I think I disagree with your definition of "edit". Perhaps this comes down to "chunking" in human perception and action. When I type 100, I don't consciously instruct my fingers to type each character, what I enact and perceive is the number "100". From this perspective, it seems natural for the programmer to control what an edit is.
I've heard VI users talk about edits in terms of breathing. You hit 'w' (or whatever it is they do), type in your edit, then hit escape when you're done. They describe this as natural in terms of breathing rhythm.
Of course in a performance context there is a more concrete requirement that edits need to be timed to happen in a certain way, and everything that happens it part of the output, so you want complete control over what gets interpreted when.. The temporal relationship between programming and output is different from the debugging case which you are more interested in. Both cases are concerned with liveness, but the constraints are different.
As for liveness, I think we disagree on what should be live. I only really care about the feedback loop between the executing program and the programmer editing that program. I don't expect anything else to be live, and actually, it might not even be useful in some cases (e.g., if the program is executing in real-time and is interactive or animated, I have nothing steady to shoot at).
If you're programming DSP, then the haptic upper limits of typing is much slower than the limits of aural perception. But I understand more about what you mean by "steady frame" now.
Yes I think you're right in our point of disagreement. In Chris Nash's terms, you're interested in liveness solely in terms of manipulation-driven feedback loop, and I'm interested in it predominantly in terms of performance-driven feedback loop, and only secondarily in manipulation-driven feedback.
The diagrams at the end of this paper might clarify: http://www.eecs.umich.edu/nime2012/Proceedings/papers/217_Fi...
(I've seen a more detailed version of this somewhere, maybe his PhD thesis)
Are there good examples of live programming literature that doesn't primarily use media generation in its examples? That might be part of the problem - programming with media is an obvious use case for live programming languages, so people assume the low hanging fruit is all there is?
I love that live coding music is making its way to javascript / coffeescript. I can't wait to see what people create with it.
I’ve written some GitHub Issues: https://github.com/bengl/beatsio/issues
midisheetmusic.sourceforge.net
Hell, just upload your MIDI to hamie.net and they'll do it for you (albeit horrendously).
There are some tools that I could find but so far none has come up with good conversion from FLAC or MP3.
I'm mainly interested in classical music and that kind of complicates things. As the number of voices in your audio increase, it gets that much harder to export it to MIDI. I've been thinking about emphasising the melody line and exporting that to MIDI but so far nothing :P
Perhaps a different approach would work better.
But thanks a lot for the help :)