I've been following Ronin and the author for a few years now from a distance. As I have said in other threads on hn about this work, the theme and ethos are so consistent and thorough they just slap you in the face. You know exactly what is going on with Ronin, Oscean, Orca and it is a pleasure to see such clear manifestation of intent.
Ronin in particular is the most fascinating piece of this network to me. I was hooked by the (broken) version 1.0 when I first found it a couple years ago and played around a bit with fixing it. It played well with a few other key influences in my life and I've been playing around with similar--albeit prototype--systems ever since.
To name one stand out feature. I have been playing around with generative design/creative coding/coding art for a while now and I seem to be on an edge of the domain. My work lately has been increasingly taking a set of starter points, so to speak. I have shapes or layouts in my head that I want to run through the generative process, but I am distinctly starting with these hard coded values.
Ronin provides direct manipulation on the canvas with `$` prefixes in the code. If you type `$point`, then click on the canvas, "$point" is replaced with code representing that point. The simplicity of this interface for writing code that heavily involves numbers in context (ie on their domain) is an inspiration. There are probably a couple of names for this connectivity, but one might be bi-directional evaluation. Manipulations in code yield the canvas, and manipulations on the canvas yield code.
There's a lot going on here, xxiivv.com
And some fun to be learned by poking through git commits. If you know Orca, (was popular here a while back) it didn't start as a music generation system.
There is a plan9 and acme demo on YouTube which is eye opening. One idea that has captured me is the idea that end users ought to be able to create custom UIs. This appears to be a foundational principle of plan9, the way all text is able to be executed. Another avenue for this idea are ZUIs as originally envisioned. Individual clipboard state can be reified as buttons in the UI, any formatting or pens or fonts can also be manifested in the interface and selected with something along the lines of the "eyedropper" tool present in many applications.
I agree, thanks for pointing me to that info page. I would bet that keys representing functions probably evolved simultaneously with the first computer typewriters, they've been around forever and are "obvious" to some degree. Making functions apparent in menus is also probably synonymous with the first non text-based GUIs. I don't know enough about the history of toolkits, but as far as I can tell that area of development is nowhere near mainstream today.
I have been reading Sutherland's Sketchpad thesis, and it struck me that no aspect of the system was unavailable to the user. By itself, this isn't entirely unusual, I think the same could be argued for emacs or linux in various ways or even of software when code is available etc. The unique aspect of this universal control with regard to sketchpad is that it was a graphical system. Controls for the graphics and viewport were essential, and reflected by the development of the first oop principles of master/instance and recursive expansion of arbitrary material in the workspace. Of multiple viewport movement controls (physical dials too!) and focus-selection zooming.
It is easy to imagine extensions of sketchpad with graphical macros. Of savable viewport state, of non-euclidean jumps between locations on the digital "paper".
It's funny to me that most clever things I enjoy about vim seem like they could fit right into a graphical system like sketchpad. `mkview`, marks, folds, repeat operations, contextual movement or selection like accessed via combinations of `[{(`.
Infinite canvas artboards are fantastic workspaces, but lack even the basic "focus shifting ability" of a few stacks of paper on a desk, taped on a wall, or strewn across the floor.
The thing I like about the best parts of vim and emacs is how much it feels like a conversation with the computer. Such that it natural lends itself to interacting with completed things. Indeed, "ciw" only works if you have a completed "word" to change.
Notebooks are usually tons and tons of fragments. Such that a precise dialog with them feels very difficult. I agree it would be awesome, but I have yet to see something that doesn't just harken to the ultimate failures of graphical programming languages. Neat for performance style programming. But needing a ton of rehearsal to get a performance.
It sounds very cool, but I hit a brick wall almost immediately when I tried to use it: how do I run a script? The tutorial video says you type cmd-R but that just reloads the page when you're running it in Firefox.
It's probably fair to say this software isn't the most user friends as a result of its continuous change. In chrome and firefox Control-Enter runs the web app version I find here: https://hundredrabbits.github.io/Ronin/
The author is a reasonable person. The community is as poisonous as hell. Two people in the slack group made many to leave. Nothing has been done yet. A few years ago, they removed a friend of mine. Because the two men turned their eyes on them like the malicious Sauron.
The output is interesting. Remove yourself as far as possible from the community.
This is exceptionally cool. Thanks for sharing and building!
When I'm using Sketch or Movie Maker or Logic or some other GUI-based >>x<< editing tool, the thing that keeps going through my head is: "Dammit I wish I had the abstraction tools that I have as a programmer. It would literally make this task 100x faster."
To me Ronin is some strong validation that all these editing tools would be much improved by a human-readable and programmable intermediate representation of what you're doing with the GUI. The GUI is just an editor for modifying this representation.
FWIW, Autocad, being written in Lisp, had a repl that was fed via the UI, so that you could basically see what the UI was generating and write your own scripts based off that.
I haven't used Autocad in 25 years, so I don't know how much of this is still true.
They complement each other. There are certain things that I’d love to pull up a command line for (e.g. quickly aligning dozens of objects using a non trivial heuristic); but on the other hand there are plenty of things where the act of visually working through it, placing multiple options side by side on the canvas, rearranging things by hand etc., helps in solving the problem itself.
What would be really nice is if we had a solid set of standards for inter operation, such that I could work on the same video editing project in After Effects, through the command line, through some open source tools someone else wrote... etc.
I have a project right now where I have assets generated in Sketch, some other assets generated by Python scripts, all feeding into an AE project, the output of which gets fed back into some of the Python scripts... I can do great things, but it’s super kludgy/buggy to work with, and as a software engineer see so many trivial ways in which it could all be so much faster and more pleasant to work with (e.g. After Effects natively only supports very limited JS like scripting, so I have to have duplicated Python + AE code... and if the AE motion tracker could serialize tracking data for Python...).
I’m not holding my breath because this kind of computing, while more aligned in philosophy with the early composable UNIX roots, is IMO most entirely incompatible with the state of the (creative) software industry/economy (Adobe, like everyone else, would like to do as much as they can so that you do not give any of your time or money to creative software other than Adobe’s).
> They complement each other. There are certain things that I’d love to pull up a command line for (e.g. quickly aligning dozens of objects using a non trivial heuristic); but on the other hand there are plenty of things where the act of visually working through it, placing multiple options side by side on the canvas, rearranging things by hand etc., helps in solving the problem itself.
> What would be really nice is if we had a solid set of standards for inter operation, such that I could work on the same video editing project in After Effects, through the command line, through some open source tools someone else wrote... etc.
The big challenge I see here is a two-way mapping between code/representation and GUI. Ronin here has code >> graphics, but question is how to have a clean mapping from graphics >> code?
> I’m not holding my breath because this kind of computing, while more aligned in philosophy with the early composable UNIX roots, is IMO most entirely incompatible with the state of the (creative) software industry/economy (Adobe, like everyone else, would like to do as much as they can so that you do not give any of your time or money to creative software other than Adobe’s).
I do wonder if this is going to be a space that gets disrupted. We're already seeing this with smaller players like Sketch and Figma going into the image space. Still GUI tools, but proves that the barrier to entry isn't quite as high.
Is the technical moat for audio and video THAT insurmountable? I get that people won't be making the next hot music video on open source software right now, but I personally could use something dead simple to compose together a bunch of screen recordings into a demo video.
> I have a project right now where I have assets generated in Sketch, some other assets generated by Python scripts, all feeding into an AE project, the output of which gets fed back into some of the Python scripts... I can do great things, but it’s super kludgy/buggy to work with, and as a software engineer see so many trivial ways in which it could all be so much faster and more pleasant to work with (e.g. After Effects natively only supports very limited JS like scripting, so I have to have duplicated Python + AE code... and if the AE motion tracker could serialize tracking data for Python...).
Lisp has a long history in computer graphics. It was particularly popular in the 1980s.
There was Symbolics, a manufacturer of Lisp workstations (sometimes also remembered as the first company to register a .com domain).
Symbolics had a Lisp-programmable 3D graphics suite that seems to have been fairly successful at the end of the decade. Here’s a video from 1989:
https://youtu.be/gV5obrYaogU
The video doesn’t seem to show any Lisp though.
On the 2D side, the immensely popular AutoCAD adopted Lisp as its expansion language in 1985.
Also notable in the context of "two-way mapping" is Dynamic Windows, the Symbolics Lisp-machine window system. Dynamic Windows was a "presentation-based interface", by which its authors meant that data structures had "presentations", which were interactive widgets that could be used to interact with values.
For example, if you evaluated a Lisp form in the Listener, it printed out the value just as you would expect, but what you might not expect is that both the evaluated form and the returned result would automatically be mouse sensitive and would offer menus of operations to be performed on them that were relevant to the data structures that they represented. The text on the screen wasn't just text; it was a "presentation"--in other words, a kind of reference to the in-memory data with an interactive visual representation.
Later, Apple did something similar with SK8, a sort of Hypercard-on-steroids built on Macintosh Common Lisp. Its design was not exactly like Dynamic Windows, but it shared the idea that values could have presentations. A distinctive feature of SK8 was that you could grab and drag widgets with the mouse, then drop them into a listener window to get references to them that you could then use in code to operate on the live widgets.
So there's definitely a good amount of stuff you can do in this "two-way mapping" direction. Some of it has been done before. Doubtless much more remains to be discovered; it just needs the application of labor and imagination.
I love that video tour of the lisp driven graphics software. I was just watching it the other day.
I often wonder what would have happened if there was a line of that OS/software still going that was still partially code-driven. Reminds me a lot of the interactive text editors/visual programming stuff that was all over HN a few yrs back with Clojure and others.
Ronin in particular is the most fascinating piece of this network to me. I was hooked by the (broken) version 1.0 when I first found it a couple years ago and played around a bit with fixing it. It played well with a few other key influences in my life and I've been playing around with similar--albeit prototype--systems ever since.
To name one stand out feature. I have been playing around with generative design/creative coding/coding art for a while now and I seem to be on an edge of the domain. My work lately has been increasingly taking a set of starter points, so to speak. I have shapes or layouts in my head that I want to run through the generative process, but I am distinctly starting with these hard coded values.
Ronin provides direct manipulation on the canvas with `$` prefixes in the code. If you type `$point`, then click on the canvas, "$point" is replaced with code representing that point. The simplicity of this interface for writing code that heavily involves numbers in context (ie on their domain) is an inspiration. There are probably a couple of names for this connectivity, but one might be bi-directional evaluation. Manipulations in code yield the canvas, and manipulations on the canvas yield code.
There's a lot going on here, xxiivv.com
And some fun to be learned by poking through git commits. If you know Orca, (was popular here a while back) it didn't start as a music generation system.
Edit:
Ronin tutorial video, 5:22. First 30s tease the original version I saw. https://www.youtube.com/watch?v=SgAWGh1s9zg
Old version tutorial/demo 4:09 : https://www.youtube.com/watch?v=gifzjhyBwOc