Re: [LAU] Editing zynadsuxfx/yoshimi patches?

From: S. Massy <lists@email-addr-hidden>
Date: Tue May 03 2011 - 23:34:59 EEST

Hello,

Well, everything below makes good sense, and I'm excited to try out
Lieven's programme and see what starting point and new ideas it might
give.

One thing I am wondering is what application or DSSI plugin would make
an ideal test-case. We would need something reasonably, but still with a
large enough number and variety of parameters to give an idea of
real-world needs and possible issues. How complex is xsynth in terms of
controls?

Cheers,
S.M.

On Sat, Apr 30, 2011 at 01:04:26AM +0200, Julien Claassen wrote:
> Hello everyone!
> So I took the old thoughts file, thought some more, rearranged it
> and came up with this. Note: All lines, that start with a '#' are
> for later, perhaps MUCH later! this is just to organise thoughts and
> map the basic structure, the basic requirements.
> As said before: L3et's start small. But as I added: Let's have a
> road in mind, so we don't end up with something nice for the one
> task at hand, which alas has to be completely rewritten for the next
> steps. It's much work, very tedious in the long run and likely to
> not get done. :-)
> Proposal for a CLI client based on automated interface generation
>
> Protocols/mechanisms for communication
> * OSC
> #* MIDI
> #* serial network protocol
>
> Suggested output modes
> * ncurses - full-screen (main)
> #* commandline - shell-like
>
> The Tree of user elements
> * Interface is based on a tree of arbitrary branches (i.e. not binary tree0
> * The tree must be searchable (text-search for node-names)
> * Each leaf marks a command/parameter of the communication-server (i.e. one OSC path, one MIDI controller, one network command)
> * A leaf must hold a number of values of arbitrary type (predetermined by initialisation, because an OSC path can have more than one value attached)
> * Each node must have a name
> * Each leaf must hold the command/data to be sent to the server
> * Must a each leaf hold a function to send the command to the server or can it be generalised and stored somewhere global to one interface instance?
>
> Other things about the interface
> * A listener interface/ADT (listening to the server, updating the tree, if necessary, initialise values)
> * Tree building functions/interface (to construct the tree from supplied commands/paths)
> * A UI interface/ADT (how to interact with the user, ncurses/shell, input, data representation)
> * A data-node interface/ADT (what to be kept in the tree-nodes)
>
> Interface generation (tree-population)
> * Generate and fill the tree manually for a specific purpose first!
> #* Use OSC use Namespace exploration, signature and return type discovery and documentation features
> #* But allow for a description file (RDF?)
> #* A description file might
> # # map commands to appropriate paths
> # # provide documentation, signatures, return types, units, names for sub-parameters/options (i.e. OSC path parameters, options to a network command...)
> # # give command(s) to query current values from the server
> # # tell the means of communication (i.e. OSC, MIDI, UDP,...)
> #* A descriptive file should override info gathered by standard querying
>
> Ideas for the ncurses interface;
> * Display lists of nodes on one level underneath each other
> * Have expand/collapse mechanisms (like in aptitude, mail-clients...)
> * Always use/move the hard-cursor (nNO soft-cursor!)
> #* Go to shell-interface by pressing colon ':'
>
> #Ideas for the shell-interface:
> #* Encourrage programmers to create consistent command sets
> #* Use esacpe (ESC) to switch to ncurses mode
> #* Allow for aliases/short-forms?
>
> Practical issues
> * Question: What to use for the variable lists in tree-nodes? (list, vector...)?
> * For OSC use liblo (already used in many linux-audio apps)
> * For trees look at STL and Boost
> * Try to use as few Linux-specific extensions as possible (if so note it!)
>
> The last comment regarding c++ and other library extensions, which
> are only available on Linux. If one undertakes such a thing and is
> set on it, one should try to make the system available to as many
> people as possible, so it gets accepted.
> What do you think? Additions? Baisc disputes? Obvious falsehoods
> or items of importance missed?
> Best wishes
> Julien
>
> --------
> Music was my first love and it will be my last (John Miles)
>
> ======== FIND MY WEB-PROJECT AT: ========
> http://ltsb.sourceforge.net
> the Linux TextBased Studio guide
> ======= AND MY PERSONAL PAGES AT: =======
> http://www.juliencoder.de
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-user

-- 
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Wed May 4 00:16:02 2011

This archive was generated by hypermail 2.1.8 : Wed May 04 2011 - 00:16:02 EEST