Live Coding in CoffeeScript • Hacker News Board

Re: Live Coding in CoffeeScript

#31

Post by yaxu » Tue, Feb 19, 2013, 10:24 AM UTC

seanmcdirmid wrote: post #28

yaxu wrote: post #25

Earlier quoted context omitted.

One more point from my phone on the train.. I've also been frustrated with people assuming "live" in live coding refers to a live audience. I prefer to think of it as live electricity. But it is just a really easy way to explain live coding to non programmers.. For whom seeing the results of what you are doing, while you are doing it, is the natural way of things.

I think we both get annoyed in the same way for different reasons :) But your community is high profile because of performances so that's what people tend to see. It doesn't help that you guys are also focused on music and media generation, applications areas that are disconnected from what programmers typically work on.

Heh, well I'm happy to help with this situation, wikipedia might be a good place to start.

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?

Re: Live Coding in CoffeeScript

#32

Post by canibanoglu » Tue, Feb 19, 2013, 11:20 AM UTC

yaxu wrote: post #27

canibanoglu wrote: post #13

Earlier quoted context omitted.

Ah, I should have been clearer. MIDI to sheet music conversion is trivial. What I want to do is take real audio as input and convert that, which is according to my readings really hard because MIDI and audio formats (FLAC/WAV/MP3 etc) are very different. 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 c…

The research field trying to tackle this is called "music information retrieval", that may help with your search.. I think they have made some headway but it involves quite a few challenges - auditory scene analysis, source separation, pitch labelling etc.

That is extremely helpful, thanks a million for the pointer! :)

Re: Live Coding in CoffeeScript

#33

Post by seanmcdirmid » Tue, Feb 19, 2013, 11:22 AM UTC

yaxu wrote: post #31

seanmcdirmid wrote: post #28

Earlier quoted context omitted.

I think we both get annoyed in the same way for different reasons :) But your community is high profile because of performances so that's what people tend to see. It doesn't help that you guys are also focused on music and media generation, applications areas that are disconnected from what programmers typically work on.

Heh, well I'm happy to help with this situation, wikipedia might be a good place to start. 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?

User interfaces are the classic examples, but I'm going to bring this to compilers in my next paper. It turns out you can easily generate a programmer-observable output for most programs by putting a lot of print statements in your code (barring some device drivers).

Re: Live Coding in CoffeeScript

#34

Post by seanmcdirmid » Tue, Feb 19, 2013, 11:26 AM UTC

yaxu wrote: post #29

seanmcdirmid wrote: post #26

Earlier quoted context omitted.

I mostly agree with you, but I think their will be some confusion until we work this out. I'm not sure what Bret Victors refers to his work, but I found the similarities between his work and Chris's thesis to be very striking even though I'm sure they are independent. Perhaps we can harmonize or at least figure out what the key messages are to avoid confusion. I think you want to provide feedback for each discrete or…

Yes great, lets try to work this out - you should have an overlong email in your inbox from me as a starter :) 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 t…

I program with an IBM Model M keyboard so I can here every keystroke. If you type fast enough, the programmer won't notice intermediate feedback going through 1 10 100. You could even put in a delay but I would hope its not necessary.

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).

Re: Live Coding in CoffeeScript

#35

Post by yaxu » Tue, Feb 19, 2013, 1:19 PM UTC

seanmcdirmid wrote: post #34

yaxu wrote: post #29

Earlier quoted context omitted.

Yes great, lets try to work this out - you should have an overlong email in your inbox from me as a starter :) 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 t…

I program with an IBM Model M keyboard so I can here every keystroke. If you type fast enough, the programmer won't notice intermediate feedback going through 1 10 100. You could even put in a delay but I would hope its not necessary. 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 ex…

Nice point about your keyboard, but I'd still contend that a series of fast keystrokes is perceived as a thrum, not necessarily a series of clicks.

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)