Posted: 21 Jan 2018, 18:40
This is related to the reverse UI patching idea, but a bit different.
Also possibly one for HH4 (which I assume is years away!).
One of the strengths of Usine is the wiring, signal flow, etc.And for signal processing that is exactly what you want.
But for making a comprehensive GUI, signal flow and wires are not ideal.
Think think of making a UI in a browser with javascript, and compare to making a UI in Usine. In Usine, If you want to fully control a slider for colours, caption, input and output, etc. you need many wires. In Javascript you can just get or set properties without any wires.
If you could programmatically write to anything in the workspace from a script you could be asking for chaos, strange bugs, etc.
That is sort of what IML can do in a clumsy way, and why I dislike IML so much - it can do some interesting things (although I have not had much luck with it, using "internal" names, etc.) but it is really an internal language and is rather hacky.
What I would like is the ability to control visual components from a script or SDK like you can with Javascript. This would require an object model and parameters and settings to be available a properties, etc. One advantage of wires is that it controls the interface between components, e.g. a module can only write to other modules that it is wired to. So it would be fine if it the new facility was only possible within a patch.
This would not be intended to get and set signal flow, only visual properties, and it could operate at the UI refresh rate, not at bloc rate. You could see it as an improved and much safer IML, with proper object model syntax rather than just text strings I suppose.
The idea is that you could produce a UI in Usine that could be controlled from code in a similar to what you could do in javascript and a browser.
Also possibly one for HH4 (which I assume is years away!).
One of the strengths of Usine is the wiring, signal flow, etc.And for signal processing that is exactly what you want.
But for making a comprehensive GUI, signal flow and wires are not ideal.
Think think of making a UI in a browser with javascript, and compare to making a UI in Usine. In Usine, If you want to fully control a slider for colours, caption, input and output, etc. you need many wires. In Javascript you can just get or set properties without any wires.
If you could programmatically write to anything in the workspace from a script you could be asking for chaos, strange bugs, etc.
That is sort of what IML can do in a clumsy way, and why I dislike IML so much - it can do some interesting things (although I have not had much luck with it, using "internal" names, etc.) but it is really an internal language and is rather hacky.
What I would like is the ability to control visual components from a script or SDK like you can with Javascript. This would require an object model and parameters and settings to be available a properties, etc. One advantage of wires is that it controls the interface between components, e.g. a module can only write to other modules that it is wired to. So it would be fine if it the new facility was only possible within a patch.
This would not be intended to get and set signal flow, only visual properties, and it could operate at the UI refresh rate, not at bloc rate. You could see it as an improved and much safer IML, with proper object model syntax rather than just text strings I suppose.
The idea is that you could produce a UI in Usine that could be controlled from code in a similar to what you could do in javascript and a browser.