22 Apr
2011
22 Apr
'11
1:09 a.m.
Here is more on the parameters-in-filesystem idea:
On Friday 22 April 2011 00:31:39 S. Massy wrote:
On Thu, Apr 21, 2011 at 01:04:06PM +0200, Arnold
Krille wrote:
To load and save the settings, just write/read the file "settings" or use it
for cp.
What about exporting the option-/parameter-tree
into the filesystem
through fuse?
I *like* this idea!
One would basically split the interface in two parts. A daemon in
contact with the main engine (using OSC or any other means), which would
then export all parameters to a file system building a suitable
hierarchy. Each parameter would have a handle node e.g "freq" and a
description node "freq.desc". The description node would contain
relevant information, such as a label for this parameter, a type, a unit
value when relevant (such as hz, bpm, %, etc.) and a range of values (or
choices if it's a list).
Then the actual UI would simply have to crawl this filesystem and
populate its tree based on the values and their description. Likewise,
it could modify the values simply by writing to the appropriate node.
There could even be a separate FS subdirectory containing "actions"
(such as save, load, reset, etc.) which could once again simply be
triggered by writing to the appropriate file. This opens up a tonne of possibilities (scripting,
control from remote
applications, multiple UIs).
Multiple UI's would be possible, even signaling of changed parameters will
work through the inotify system. Scripting will work, for automation you would
have to decide whether the parameter is changed once a valid value is written
or just after the "file" is closed.
You could even define "files" for stream input/output but that part is better
left to jack.
I don't think remote control over network will be possible by this as fuse-
mounted dirs afaik can't be exported via nfs/smb/cifs.
But you realize that this is all actually OSC with a standardized
introspection-method?
- One could write a generic OSC-fuse-bridge if only there is a way to tell
that bridge what to create or how to introspect the (remote) apps.
- One could write/use a simple set of text-tools to introspect/get/set OSC-
paths (like the qdbus/dbus-send/dcop-tools).
Going for real OSC would also add the network-transparency for free. Only
advantage of the FUSE-bridging is that its more like plan9 (everything is a
file).
Have fun,
Arnold