After some very interesting exchanges with Max/Msp experts, the issue was raised of representing devices as nodes to be patched with cables.
This is already somewhat possible through the “Control surface” process, where a parameter from the Device explorer can be drooped for creating a dedicated slider
and inlet, patchable like any other process.
If the control surface could be extended to receive audio, midi and texture nodes, this alone would cater for all patching needs and workflow.
Altho the question has to be asked, if it is simply about drag and dropping nodes onto a control surface to then attach cables, why not directly drag and drop the node on the desired outlet and save a process, a few cables, and the time it takes to create them ?
The main motivation seems then to be the homogeneity of the final layout, where everything is represented in a single nodal view, without having to look at a separate window (the “Device explorer”), and no inlets, outlets or processes has to be clicked to read the attached address.
Pushing this further, we could imagine a version of score without devices (or “Device explorer”). Instead we would just have I/O processes.
This was probably discussed elsewhere. It would just translate to a box representing a certain Midi device, another representing an OSC namespace and so on … They would then be created and used in the same way any other processes are in a nodal view.
Would this make things clearer and give homogeneity to the workflow ? What would be lost ?
I for one would be very interested in the inverse, a purely address based system, where cables, inlets and outlets would be replaces by addresses, or essentially, “mini Device explorer boxes”. The interest for me, on top of this other homogeneity, would also be to take advantage of wild cards and regexp everywhere,
as well as conversion Units and the ablilyti to extract individual values form arrays (ie. MyParent:/MyNode/MyParameter@[2]).
This is also part of the Discussion on the semantic of ports, addresses & bindings