This took a while, but I just finished my entry, pretty happy with how it turned out for my first time actually editing a video! This video is purely an introduction, next week there will probably be some more devlog-y content.

nice! I will have to watch it a couple times to get all the details, a good thing that it's only 2 minutes long 😄

Nice cameo by Pilot in there :)

@Mariano Guerra yeah it's quite dense, and I even cut out some of my script 😅 Its quite tough boiling down all the inter-related properties in an order that makes sense too.

the sounds from the beginning of the video are from pilot? how do you get such nice sounds? when I tried pilot the sounds where quite basic (noob question 🙂 )

The idea being that that makes mental-modelling easier for the programmer, and allows the audience to relate the code to the output better, since there can be neither dead code visible nor 'zombie' side-effects from previous evaluations left in the output.

how do you know what to keep and change from the running stuff? you do some sort of "code tree diffing"?

@Mariano Guerra I think it's actually all Pilot presests? Comparing the video to my pilot's launch values, it seems I adjusted channel #2s settings, but 7 and E are completely stock... thats all I'm playing :)

I may have been using a crappy channel 😄

the matching is done using the tags, zero text diffing / guessing involved: - Expression without tag or unknown tag? New instance. - Expression with existing tag? Parameter change (unless expression head changed) - All expressions whose tags are no longer part of the code are removed

very cool, I like that the tags are autogenerated by the editor, that’s a good solution. Nicer than say React.js which demands that the coder provides unique IDs for all nodes

Nice demo. I think it could be better if you allow a visual controls to coexist, and become subroutines effectively, so that parameters can be adjusted with knobs, sliders, and mutually exclusive graphical controls. To a avoid reprogramming, i suggest you let right click pop up a slider to adjust parameters. And for picking notes a little keyboard would be more fun. Anyway just a suggestion.

@Andy F yeah, that is a bit silly in react, but its because react cant know which strange logic you use to assemble your output tree. Here the tagging is actually done by the interpreter, not the editor, so you can use any text editor and simply need to reload the file immediately after saving.

Nice. For me, this captures the essence of how live programming should work. I haven't tried those other tools, but "zombie side effects from previous evaluations" is not acceptable to me.

@Doug Moen maybe the term villifies it a bit, but it's a real problem with SC and tidal IMO 😉 You evaluate statements like a = SomeInstrumentDefinition() a.play() ...and when you delete those lines you can no longer do

a.stop()

. It's even worse when you don't even store the "thing" in a variable but just .play() it right away

@s-ol [034..044] ...expressions do not coalesce into their value once they are evaluated. They continue existing as operators that can update their own return value as their inputs change.

I have been working for some time to implement a stronger version of this idea in Curv. Subexpressions that depend on a time varying input signal behave as you describe in the above quotation. Although my theoretical justification is based in FRP, the goal is to support live programming in exactly the way you describe in the video. The source code you see in the editor corresponds exactly to the animation you see (in Curv) or the music you hear (in alv).

@Doug Moen dependencies between expressions are tracked in alv, and expressions which do not have "IO Inputs" (such as time or external messaging impulses) are "eval-time const" and never update. I'm going to check out Curv again, I think last I really played with it was just before you really started working on the livecoding aspect (with UI extensions etc)