MSG NOT FOUND
So the issue of what is connected to what is something I've been thinking about. I may end up having a mode where you can see pins connecting things together, or even a way to modify them visually. But for now, you are essentially correct. Top-Left to bottom right. It's slightly more complicated because from Oscillator1 -> Filter Envelope are effectively all 'parallel', and there's a hidden node which combines them before they go into the low pass filter. The bit of script I show at the end has the full connection details, but you might also think of this as a UI for a SuperCollider SynthDef. In that case, you wouldn't normally see a UI at all.
A big part of what I'm trying to do is add more visual components to live coding, and enable more control over the performance as a result. That includes the visual side, with the custom editor which will embed widgets for controllable parameters as you type code.
What I’m most interested in is giving the artist control over the performance in a way that sometimes feels missing to me. Creating a complex pattern and mutating it in Tidal, before driving it through a SC synth might well produce a great piece of music, but how much does the programmer know about what the algorithm is doing to achieve the result? Visualising more of the pipeline might help produce even better results, or at least help understand how the results are formed.
Here is a follow up on the Beads layout system. Beads has a very unique layout system that is slightly more advanced than the Apple struts and springs system used in XCode. You design your layout by starting with the full screen rectangle, and subdividing it into pieces. Each chunk can be further subdivided. It has pre-programmed the commonly used types of decompositions: plain, vertical slice, horizontal slice, vertical scrolling, 2D grid, and a farily elaborate report writer for those who need to produce printed reports in the classic style. Since the layout system is in the language itself, you can use variables, IF statements, and subroutines in the layout portion, unlike CSS which hampers you great. Another huge advantage over CSS is that Beads uses explicit whitespace so placement of items is 100% predictable and repeatable, unlike CSS which on a small typo can scramble your page. Building a complex product by gradual refinement is the methodology you use in Beads; always proceeding from a working standpoint, and adding in detail. https://youtu.be/lhLJbC7LA2k
When you were sketching the design, does that actually generate code for you?
So far you can generate declarations, define data structures, in the UI of the IDE. Don't have layout via GUI yet, working on it now. I am building the IDE in Beads, and it is open source and part of the SDK examples. The public has overwhelmingly expressed their desire, no expectation, for a graphical tool that generates code, so it shall be built!
Hi, here's a short introduction video about my flow-based-programming project: https://youtu.be/zckUSrZX2co . In the near future I'll upload more videos to talk and show more deeply about the project, but I hope that this video already gives you an idea of what I am creating
Looks good. Am I understanding right that the nodes/arrows only show what are the inputs, and all actually calculations are specified in (textual) code?
Thanks, and I'll try to explain: Each node has a property taskType which specifies the plugin which is used when the node is executed. The plugins determine the parameters that they need. The expression task which calculates the body mass index is an example of such a plugin. The whole flow is actually stored in json format as an array : both nodes and connections are stored in that array. The json is executed by code, and it is used to setup rxjs observables and trigger the attached plugins
What happens if two branches - or conditions - overlap? Or put in another way: What happens at the point where you have multiple arrows as input?
Basically a node gets executed when it gets called via an input. A node can be triggered multiple times, so if it has 10000 inputs, it gets triggered 10000 times. At least in theory because it depends on the type of nodes and how the flow is setup, for example if the flow has conditional nodes it can happen that nodes don't trigger their output. And some nodes trigger multiple times (in the typescript implementation a node can return an observable which can trigger multiple times)
There's also support for functions and even recursive functions within the flow. I already built a quicksort implementation with this just for testing purposes
Ok, so, the rightmost box. What color does it get when multiple things 'trigger' it with different values?
You'd need some order of execution, right?
What sort of audience do you envision using it, and what kind of analysis/apps do you imagine it being used for?
That are actually the big questions I have myself. I know that I would like to use it myself in production for web and apps which have complex forms which need calculations. But I probably wouldn't use this myself if I wouldn't be in control of the underlaying code and I assume that a lot of other developers who code a lot (and like to code) also think like that. "Citizen developers" could be a potential audience though. I would use it myself on application level and not so much the deep specialized code on lower levels.
I'm attracted to the general approach of being able to write arbitrary expressions or code blocks in the individual blocks (as text) but use a diagram for higher-level code.
One of the current supported use-cases is that you can use the editor locally and run it beside your dev environment. The editor can be easily extended with your own tasks which you can develop in your dev environment. For example if you have a frontend workflow you code the tasks in vs.code in typescript. The same can be done with backend code, I do this myself with a php project. A lot of the typescript code that I've build can already be installed via npm but I am not actively promoting or documenting that, it's there to make it easier for myself at least. But I am also a bit reluctant in putting everything online for free because I am still thinking about a business model
Maybe the above will be the topic for my next 2 minute video, but that will be a real challenge to stay below that limit
It would interesting if a node could output the JSON for another graph of nodes (which would probably require a diffing algorithm to prevent having to recreate the whole thing each time, like a vdom)
One of the items on my backlog is to load parts of the flow dynamically to be able to run flows at scale. My concerns is that this cannot grow indefinitely, parts of the flow also need to be removed from memory dynamically and loaded again when needed. Probably a flow needs to be really really big before this is a problem nowadays. Is this what you meant?
alv week 2: https://youtu.be/pp21N2lSEIk (I'm clearly not able to keep up with a weekly rhythmn with my current workflow, but I'll keep experimenting with what I want out of this :)
Pointing out that physical knobs work well with a structured editor: 🤯
That hardware UI gave me so many good feelings. This was a great video, and I'm super excited to see where this goes. Awesome that people are already using alv, and the example music made with it was a great touch.
I love this makeshift hardware, what's it built with? Besides al foil.
Ryan King an ESP32, two rotary encoders, cardboard, aluminum foil and enameled wire :)
Ryan King go for it! This could be done with any arduino as well, talking over the USB connection. The ESP32 is special because it has WiFi and Bluetooth integrated. I'm using WiFi for connectivity here, but thats just because this grew out of a project to build a wireless light dimmer ;)
I've had my hands full with other stuff for the past few weeks, so Hest progress has been slow (as seems to be my lot, sadly). I guess this is what you get when you start messing with the timeline. Don't mess with the timeline!
I love the dramatic pause in the very beginning where you drop down an octave. 🤣 It had a surprisingly fun bit of tension to it - is he really going to hit that note?
A few weeks ago, I watched a ton of the videos you have up for LunchboxSessions and I was really impressed with what you folks have out there. It's such a great idea! Certainly sparked my curiosity into what the process of creating those simulations/models must be like. I'd be really curious to learn more about that sometime. It also firmly grounded your design of Hest to me. 🙂
That was delightful. Now for the real question and most important question: are Hest path defined by Hest points? Because if they are, you are about one inch away from awesome.
Chris Granger After years toying with ways to color and animate hydraulic / electrical schematics, looking to systems-y games like Factorio and SpaceChem and Mini Metro for inspiration, something Hestian feels sort of nearby to me in a way that other kinds of programming don't.
William Taysom as in.. is a path object just the composite of an infinite series of point objects? Or do you mean.. are the bezier anchor/control point objects also the same kinds of things as the colourful data point objects? Or something else? Not sure what "defined by" means in your usage.
your future of coding is the most mysteriously interesting of all the ones I've seen, fast forward please! 😄
I mean the control points. Imagine a three paths, say, loops. Put a point on each. Connect each of those points to make a new time-varying path. Then points on that path could trace out especially rich trajectories.
I think this is what you have in mind. This is from an older prototype, back when I was rendering colorful trails behind moving points. It's a (sloppy, by-hand) geometric implementation of the Bezier curve algorithm.
This isn't particularly useful (yet?) as a programming construct, but might be useful for building animations — it should make it easier to set up certain kinds of forward kinematics.
Really, it's not something I've designed in the model. It just emerges from exactly what you'd expect — a "point" is just an object with an explicit position, and an "edge" is just an object with a collection of points, and you can convey a point along an edge. That's all the model cares about. Everything else is just rendering, or aesthetic implementation choices.
Fascinating video! I want to know more; where are the lunchbox sessions mentioned above?
Chris Maughan
See the previous TMW Hest video for an explanation of what LBS is: https://futureofcoding.slack.com/archives/C0120A3L30R/p1586795860004500
The videos Chris Granger watched are probably here (ignore the live streams): https://www.youtube.com/lunchboxsessions
If you want to take a look at the subjects we cover, I built a fun graph-based menu here: https://www.lunchboxsessions.com/explore
A good freebie to check out would be Hydraulics > Fluid Power Basics > Energy Basics. That one nicely captures the tone we're going for: complex ideas and systems explored with simulation, animation, and whimsy.
Any questions, feel free to DM me if you'd like to get into the weeds.
I want to somehow hook this up to my code base and watch the data flow through the system.
It's very interesting to think of the curves as defining time. When you pull a point off it's going outside of time. Moving time backwards no longer includes that point. It's like it never existed. Whoa. An editable undo tree. What else could it be good for?
This is a programmable Gantt chart tool I've been working on. I just released it as a beta to my users today. I'm expecting them to find the formulas very intimidating (although most can use basic excel) but I'll let you know what their feedback is next week! Couldn't fit in the canvassy graphical interface but perhaps another time. https://youtu.be/Anv8-3sZFVE
That's really nice!
• I like that you show the last computed value above the formula fields. That's a nice bit of UI. • I love that you support units! The main other place I've seen rich unit support like that was in the calculator app Calca, but we should totally have that everywhere. How long have you been working on this? What's the tech stack?
Ivan Reese thanks! It’s probably taken a year now. The tech stack is all JavaScript. I did an initial version using svg dom elements but it had significant performance issues. So I had to take some time to experiment and learn to code graphics and animations. Now it’s using webgl with three.js and the formulas a parsed using nearley.js . I will be checking out Calca shortly!
Instadeq Week in Two Minutes #4: Providers, a unified protocol to consume batch/streaming data from external systems https://youtu.be/_VVOpGjSV68
Er... how would you describe the problem you're trying to solve?
the data the users need to access to build visualizations is spread across multiple data silos in an organizations, how do you unify and simplify the access to that data and its representation
while keeping the access restricted to the users that should have access to it, adding rate limits etc
Sorry i posted only a partially uploaded file. This is a corrected version. Thanks to William Taysom for catching that. Here is a short video showing how to build a temperature control. You proceed directly from a sketch to a final shippable product using Beads, with no prototyping necessary. A lot of wasted work happens in our industry by using wireframing tools that can't be executed. You are better off with a crude-looking working product than a fake but pretty demo. It saves time, when the final shapes are all worked out from the running product, then you apply the final polish. Beads is rare among languages in that it carries at runtime physical units of measurement (by creating a new datatype which carries the unit exponent array and magnitude of the value), and has pre-programmed all the common conversions, such as degrees Kelvin to degrees Centigrade, etc. In this example i also show how you can have two interlinked controls on the screen, and whichever one changes the model the other control tracks its value, all without any additional code. https://youtu.be/JmmwmisRd2g
great demo! one question, the track expression is tracking all events on all elements of the app or you specify which ones to track somehow? if all, how does it scale and how do you know which is the target?
When you are handed a big code base to learn, one of the hardest things to understand is which code is going to absorb a given event? When you have code that adds and subtracts listeners all over the place it can be very puzzling. So in Beads i made the design choice to force the author to put event tracking for each UI element right after the draw code. So each rectangular section of the screen has its draw chunk, and the tracking logic code must be put right afterwards. In the case of a mouse event, the runtime looks for the topmost overlapping rectangle, and gives the topmost handler the chance to look at the event and process it. If the tracking code returns Y the event is absorbed and disappears, but if the tracking code doesn't absorb the next chunk that handles that event gets a chance to absorb. All incoming events whether they be keystrokes, network events, synthetic events, or finger taps, are fed through a serialized event model i call the Loom. The overall goal is to allow post mortem debugging with visualization of the screen as time is run backwards.