@ingox "I would consider the solution with [route] as elegant and the way to go"
Thank you! So I'm not missing anything obvious
@jancsika Good summary, thanks.
@whale-av "Pd is all about messages...... and so it is all about lists"
Right, I understand arrays. (In SC, array elements are just references to objects rather than a fixed data types, so, like pd lists, each element can be a different type --
['selector', 4.0] is valid as both an SC array and a pd list.) I haven't spent enough time with pd's list manipulation objects, but I will have to, soon.
list-abs is a good tip, thanks. Seems to have a lot of equivalents of SC's array operations ([list-add] = array1 + array2, [list-drip] --> Pseq(array, 1).asStream).
You can also sort by position in a list...... by undeclared index.
That one is beyond me at this point.
The real difference of data flow programming is that it is always 'running'. So mistakes are seen straight away which is a huge advantage for us noobs.
Hm, signal processing is always running, and GEM is always running, but messages are running only when something is triggering them, right? If I "play" a Routine in SC, then that is always running (until stopped), not really any different from a pd object graph triggered periodically by [metro].
I think what's more approachable about data flows is that a patch cord on screen is "concrete" in a way that function arguments in code are not. (But I'll still use SC for my own work because I find it easier to scale up to high complexity.)