Re: [LAU] Editing zynadsuxfx/yoshimi patches?

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