Hello, Sorry, been away for a bit. Leaving the question of the interface itself aside for the time being, it seems that the most crucial thing is to come up with a way to gather, sort, and define the exposed parameters in a manner as flexible as possible and as painless to developpers as possible. One question which hasn't been answered yet, I think, is that of whether OSC is the best way to control sound engines and how well it is supported at this point. If so, then we can focus on OSC and its peculiarities and we needn't keep the interface and the generation/control mechanisms separate. I mainly liked the FUSE idea because I thought it could be useful as a means to separate the interface from the generation/control part, thus allowing our interface to drive, not only OSC-enabled applications, but *any* kind of application capable of generating a FS hierarchy, be it inlined or through any third-party protocol. If we focus on OSC alone, then this becomes an extraneous and likely tedious step. Otherwise, Julien's idea of a standardised way of describing parameters, be it through XML, RDF, or any other structured format would be the ideal way to go about it. With suitable tools to generate this file, even a non-programmer could easily help produce a working interface. Not to mention that such a file could be used to create alternate GUIs, just as much as text, or even FUSE based ones. This is largely a synthesis of this aspect of the discussion so far. Any thoughts? Cheers, S.M. -- _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
