[LAU] Editing zynadsuxfx/yoshimi patches?

[Arnold Krille]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20110422/19733a26/attachment.pgp>