Dave Griffiths writes about live coding, his Fluxus 3D engine, Scheme Bricks, weaving, and creative programming projects.
HN commenters admire his live-coding work, pointing to Fluxus, the drag-and-drop Scheme Bricks language for music, and his blog's weaving section.
Keep in mind there are actually two domains in music: instruments (sound synthesis) and orchestration. Both Skoar and Alda (which was linked yesterday) are only orchestration languages.
I've been researching about this and narrowed down by these criteria: (1) Modern and maintained (2) Open source (3) Multiplatform (4) Supports live coding (5) Not MIDI-only output (6) Text-based (7) Not Java (sorry JSyn :P)
For me live coding is important since I prefer to compose music in an exploratory fashion. Also, live performances are cool. Read more about live coding and resources in http://toplap.org
The list in no particular order (beware of the brain dump):
·
## Overtone (https://overtone.github.io/)
The coolest kid on the block is actually a frontend to SuperCollider.
- Clojure based.
- VJ-ready. Integration with Processing via Quil (https://github.com/quil/quil) and GLSL shaders via Shadertone (https://github.com/overtone/shadertone).
- Lots of tooling: https://github.com/overtone
·
## SuperCollider (https://supercollider.github.io/)
- Object-oriented functional language (similar to Smalltalk/Ruby/C/JS).
- Basically Overtone minus Clojure minus VJ plus IDE.
- Client-server architecture (which is what allows Overtone to use it as a backend).
·
## Sonic Pi (http://sonic-pi.net/)
- Ruby DSL + IDE.
- Built for Raspberry PI (but runs anywhere SuperCollider and Ruby are available).
- Another frontend to SuperCollider.
- Designed to be suitable for teaching children.…
I'm somewhat surprised he isn't basing his work on Fluxus: http://www.pawfal.org/fluxus/
> people who might be a little hostile to working in a Lisp.
Hostility is an excellent word for it.
> Doing VR GUI development in the native apps is unpleasant – you can gut it out in C++ with our current interfaces, but the iteration times and code structure don’t make it a lot of fun.
> In-editor prototyping is nice in Unity, but actual on-device testing cycle times are terrible, and you wind up with all the bulk of Unity and poor access to the native VR features like TimeWarp layers.
This is exactly the reason I've focused on WebVR with my Primrose project. Otherwise, JS sucks.
> I am a big believer in functional programming (and static types) for large projects, but there is an undeniable bit of awkwardness compared to just imperatively poking things for small projects
That's funny, because I would say the opposite is true: imperative code with global state is harder to poke around on because it's harder to reason about your state, whereas functional code [0] can be sliced and diced and put back together much more readily.
There are places where traditional for-loops, with a readily exposed counter, are extremely useful in game programming. Perhaps that is what he means? Map and for-each are great when they are the right tool, but I've personally never subscribed to the idea that they are particularly "easier" to use than for-loops, or "more functional".
> The design usage …
I know of at least one warehouse management system (and in fact maintain a deployment of it as part of my day job) where all the source code for the business logic exists in a SQL Server database; the vendor developed their own IDE of sorts for it that queries the different types of language objects for editing and eventual compilation. Most of the logic itself exists as "process objects" consisting of lists of code elements to execute (comparisons, assignments, database operations, even subprocesses) and pass/fail branches, all manipulated via the IDE's GUI. I suspect it's possible to manually edit the code via SQL (and in fact I'm looking into this, since the IDE is Windows-only and I'd like to do my editing in Linux), but much more tedious (lots of UUID manipulations and joins and such).
On a different note, Lisp would lend itself well to what you seek. While most Lisp/Scheme programming happens in a text editor, Lisp is inherently syntax-agnostic; sure, s-expressions are the most typical, but once upon a time there were M-expressions[1], and Scheme has support for alternative syntaxes[2]. Projects like Scheme Bricks[3] take this even further into visual representation.
[1]: https://en.wikipedia.org/wiki/M-expression
[2]: https://srfi.schemers.org/srfi-119/srfi-119.html
[3]: http://www.pawfal.org/dave/index.cgi?Projects/Scheme%20Bricks
I feel that talk made an impression on many people. I think that talk made live editing "mainstream" and Bret "stole" the concept by doing a good show just like Apple does. It's been done for years but no one "bothered" making a good show/product that wowed people.
From the top of my head (fluxus) [1] and impromptu [2]. And I bet every game company have their own live editing tools.
Anyway, </rant>.
What inspired me was this video of Iq's live coding setup [3] from last year. Months later I made a webgl version [4] to help spread glsl know-how. Then doing the HTML/CSS/JavaScript one was just natural de-evolution :)
[1] http://www.pawfal.org/fluxus/
[2] http://en.wikipedia.org/wiki/Impromptu_(programming_environment)
[3] http://www.youtube.com/watch?v=9g8CdctxmeU
[4] http://glsl.heroku.com/e
I am amazed at how technology and older technology come together over time. I was following Dave Griffiths since my early interest in live coding and the program fluxus [0]started. He has a section on his blog on weaving [1] that is pretty cool. I remember when flexible circuits were starting to be integrated into hats and sweaters (LEDs and such). From Jacquard loom to FM sweaters!
[0] http://www.pawfal.org/fluxus/
[1] http://www.pawfal.org/dave/blog/category/weaving/
Here's a cool thing you can do in Scheme if you feel depressed that nothing is written in Scheme:
http://www.pawfal.org/fluxus/
(P.S. I love Scheme and did everyday things in Scheme when I had the opportunity to for a while. But right now I'm really enjoying Clojure and I think that Clojure might replace Scheme for me, because of Java libraries, and because of the really concise, consistent, and pleasant syntax, especially for maps and functions.)