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: > > 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. To load and save the settings, just write/read the file "settings" or use it for cp. > 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
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user