[LAU] Editing zynadsuxfx/yoshimi patches?

Lieven Moors lievenmoors at gmail.com
Thu Apr 21 02:19:24 UTC 2011


On Wed, Apr 20, 2011 at 10:42:23PM +0200, Julien Claassen wrote:
> Hello!
>   So I finally went through the thread and collected ideas and
> thoughts. Here they are, a little chaotic still, but I suppose from
> there we can go on, adding to it, shifting things.
> Proposal for a good CLI access to audio (and other?) software
> The interface should have two parts:
> 1. a shell-like commandline
> 2. an interactive fullscreen mode
> 

Hi Julien,

I think you have some good ideas here. I just wanted to share a few
random thoughts...

> Random thoughts:
> * Use a tree structure for commands/parameters
> * Have expand/collpase function for the parameter view (aptitude, mail-clients)
> * Parameters are searchable (the tree-structure is searchable for node-data)
> * Always move the real cursor (no soft cursor) to the actual parameter
> * Encourage programmers to use consistent long and short commands for the shell part
> * leave fullscreen mode by colon and enter by ESC
> 
> Questions:
> * Which keys/mechanisms to use for collapse/expand?
> * How to move between parameters on one level?
> * What about real menus (as in file, view, edit,...)?
> * Can one assume, that OSC is always the easiest/fastest choice and hardcode it?
> * Would the commandline mainly just echo the fullscreen tree-structure?
> * Would the commandline hold special (non fullscreen) commands?
> 
>   I thought about a few of the questions and here are my tentative answers:
> * Which keys/mechanisms to use for collapse/expand?
>   In alpine/pine the folder list (one major level of the tree) can
> be navigated by using the cursor (all directions). ENTER is used to
> access a folder (go down the tree). Only in the sublevels entries
> (mails) are listed one underneath the other. So cursor left goes
> back. Best to think of a different way, so one can have more
> compressed layouts, probably organise strongly related parameters in
> one row.  For example Attack Decay Sustain and Release.
> 

I've been using mutt, and I like to be able to navigate with one hand.
The 'j' and 'k' letters became fairly standard (because of vi)
to move up or down a page or list, and 'h' and 'l' for left and right.
To navigate down a hierarchy, I'm using 'i' (easily memorized as 'in'),
and to navigate back up again I use 'o' (easily memorized as 'out').
I find this quite intuïtive, and comfortable because you can relax the
other hand whilst navigating the hierarchy.
Of course, this is not really vi friendly, because 'i' and 'o' are
used to get to insert mode. But it mutt and newsbeuter it feels really
good.

> * How to move between parameters on one level?
>   Well partly answered. I think simple lists (showsn as such) might
> be very long seeing the amount of parameters Yoshimi has to offer.
> Or what do you think? It is a little more complicated than aptitude
> or some of the other examples, since they mostly use it for simple
> lists or long menus.
> 
> * What about real menus (as in file, view, edit,...)?
>   I think some real menus might occasinally be nice. It's just
> another tree with a root node, from which the main menus branch out.
> Might be reached by something like Ctrl+first letter or a printed
> capital.
> 
> * Can one assume, that OSC is always the easiest/fastest choice and
> hardcode it?
> * Would the commandline mainly just echo the fullscreen tree-structure?
>   If the command line does echo the full screen commands one might
> use a filesystem like navigation: ls - show all parameters on this
> level, probably with "/" after them, if they open a sublevel. cd

I think it would be great to have a generic command line interface
for controlling applications with OSC, that can be navigated as a 
filesystem. I really like that idea, and it reminds me of the /proc 
and /sys virtual filesystems that are used to set the kernel parameters.
Now I'm dreaming out loud, but would it be possible to automatically generate 
such a filesystem, based on an OSC mapping.
Also I wonder if you would still need the tree view, because the output 
of ls could provide you with something similar.

Well, I'm not sure this is the most realistic idea :-)

Greetings,

lieven


More information about the Linux-audio-user mailing list