Re: [LAU] Editing zynadsuxfx/yoshimi patches?

From: Arnold Krille <arnold@email-addr-hidden>
Date: Fri Apr 22 2011 - 02:09:39 EEST

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

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user

Received on Fri Apr 22 04:15:03 2011

This archive was generated by hypermail 2.1.8 : Fri Apr 22 2011 - 04:15:04 EEST