Chris Maughan thanks for the detailed descriptions! It's really great to read about other implementations

No problem 😉 happy to share ideas.

This idea of each node building up the data being passed through in an accumulative way, rather than just "consuming" the input, is really, really interesting to me. It makes total sense, and feels like it could allow some really interesting / different ways of working with dataflow.

Can a slider's "onChange" trigger more than one node? How would that work? Just make onChange an array?

Also — when you moved the slider on the right, was that rewinding the execution history? If so, I found it odd that the sliders didn't update. Perhaps I'm just misunderstanding what it should do.

The slider on the right moves through the node execution history and selects the node that was executed and shows the output payload on the bottom right. And you're right I think: it would help if a node with a slider or other kind of input control also gets updated when the history slider is moved. In one of your video's I actually saw something similar, which was my inspiration to build this history slider. In the past I have experimented with a small list of payloads to show on the side of the screen, and for debugging purposes to add additional debug-nodes. But this works better.

Currently the onChange property can only contain a single node, being able to add an array for this to trigger multiple nodes is a good idea. In the future I also want to make the editing of a node easier with a proper form editor or with a more visual approach (the onchange property should actually be a special kind of connection, for other similar properties this is already partly implemented)

Yeah, the gradually building up of the payload works quite nice, as you can see in this example it can get quite complex. Because by manipulating payload properties you can make loops. The flow in this screenshot is an implementation of the quicksort algorithm, just to see if that would be possible with the flowrunner. It even has a recursive function 😉. The blue lines are hidden connections which are configured in the nodes (here it are connections to the node where the list is stored which should be sorted). I also want to visualize the 'onChange' properties of the slider-node of the other examples like this.

Awesome 🙂

Thanks! :-) that quicksort implementation might look impressive but I must admit : something like list.sort() is a lot easier to use 😉

I now watched your 1st video and it's much more clear, awesome concept!

How come your Orca schedules events in the future? I thought it generally executes in the 'now' - are you running it "ahead of time" and delaying the output? Doesn't that mess with user interaction?

Hi Sol Bekic, Indeed, I am scheduling into the future, but not much.... Orca does indeed schedule immediately, but those generated notes are effectively played after a small delay when the arrive at whatever Synth you are using; you just don't notice. It should be a similar situation here; and although I am testing far into the future, in reality I will probably be scheduling much more closely to 'now'. I'm trying to plan a for a future containing a music generation language I've been working on, alongside Orca. Although Orca is very fast, a music language may not be as fast. I know, for example, that Sonic Pi has a delay of 250->500ms which is added to generated notes. By scheduling a little bit into the future, there is I hope more time to generate and align notes correctly. My sense is that i need this flexibility, but we will see. Pattern languages also let you 'see' into the future, since you can run the pattern forward; so the concept of what is happening 'next' is something I want to at least be able to see.

Yeah, that scheduling into the future seems like a necessary evil when it comes to music tools. Very interesting problem space, considering every system will have a different characteristic latency to be compensated for.

Ryan King per your request, i just added two videos on beads installation, one for mac one for windows, links on beadslang.com

Beads doesn't really need installation as it it is just a few files surrounding an EXE, but you do have to add a chrome extension to run your local web apps, and of course the average person doesn't know about file associations on new suffixes.

Please let me know how hard it was to get going. If people have difficulties getting started they quit immediately.

Great maybe I can get some feedback for you over the weekend.

Is it possible to set up the layout declarations so that the sizes of elements (eg: the 100 in add 100 al d_dual) can be adjusted with some runtime logic? What would the code for that look like?

Also, how do you handle the case where you want a symbol to respond to drag-over or drag-out? Can you add those to track, with something like | EV_DRAG_OUT?

Pop Corn is totally the TodoMVC of music tools. Nice.

I noticed two UI things that felt lacking, both related to scrolling, and I'm curious if / how you're planning to improve them.

1. When you want to connect two things that are far apart on the page (at 0:50), you grab one and then drag it to the top of the page, and then wait while the page scrolls up.
2. When you drag the slider (1:04), the select table grows and shrinks. Since you're looking at the slider, which is below the table, the whole page jumps up and down.

for 1 I have the basket, I don't always use it but for long drags it's really useful, for 2, yes, I've noticed it too and I don't know yet how to best solve it, I was thinking some sort of portal and/or side by side temporary view to see effects of one cell into another one, open to ideas on this one

For 1, can you select those draggable value label things (like "goals" in the video)? If so, can you copy-paste them to achieve the same thing as a drag?

For 2, I've tried solving this problem by adjusting the scroll position to compensate for changing element sizes higher up on the page, but that never worked well enough for me to ship it. I've compensated by basically removing things from the DOM when they're outside the view, so that they can't mess with scrolling, and then reinserting them into the DOM in response to a user action. I don't think that'd work in your case, though. So perhaps the idea of pulling controls out of the main flow is the best bet. You've certainly got a lot of horizontal space to play with in your layout, so you could maybe carve off room for a panel along the left or right that could house vertical sliders and other controls. * shrug *

here's a short demo of the basket tool to drag and drop things to it and then take them from there in the other place

now I understood what you mean by 2, one partial solution for it was to render tables always with 10 rows, if it has less they will have empty rows, this would avoid most of the growing and shrinking of cells, it would add unused vertical space but at least it would be stable.

before I thought you meant that it was hard to see the effect of the slider on the other cell since it was not on the viewport, my answer did not make sense to what you actually said 😛

an alternative solution is to add another navigation mode that allows you to go to the next/previous cell but the current one is always "full screen", I could add some basic tile management to have 2 or more cells instead of just one

You had a productive week! Are you also planning to have forms where you can place input-controls on the same row in multiple columns?

not yet, may add some basic layout capabilities later, but there's a lot in front of that feature 😄

Yeah, priority management is very important😄. Do you use the html5 drag and drop api directly or an external lib to also handle touch interfaces?

html5 api directly, it kind of works on touch with patience but the default timeout to detect drag plus having scrollbars doesn't make it as nice as drag with a mouse

Space X provider — live updates about launch times?

here's a short explanation on what is and how it works

Anything behind the name Jorvik?

yay! nanovg! cool!

Ivan Reese It refers to where I live, in York. I have no idea if this is the final name - haven't decided. It is pronounced with a 'Y' https://en.wikipedia.org/wiki/Scandinavian_York

U013HU44GLS I like nanovg a lot, but I'm only using it instead of ImGui because it has the gradient fills I use, which I think helps lift the UI off the screen a little. Now I'm abstracted, it won't be hard to try other approaches.

The downside is it only supports GL and D3D9 (a backend I contributed a long time ago). ImGui might be more sensible long term.

I haven't looked at imGui for a couple of years so it may have improved since. But I selected nanovg because it was plain C and the implementation was a lot cleaner than imGui

ImGui is pretty amazing these days; especially with the new Docking stuff. But it wasn't long ago I looked, and there was no gradient fill.

Hence the hybrid approach....