[LAU] Editing zynadsuxfx/yoshimi patches?

S. Massy lists at wolfdream.ca
Thu Apr 21 00:07:02 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
> 
> Random thoughts:
> * Use a tree structure for commands/parameters
> * Have expand/collpase function for the parameter view (aptitude, mail-clients)
News-readers like trn and slrn are also good at this.

> * Parameters are searchable (the tree-structure is searchable for node-data)
> * Always move the real cursor (no soft cursor) to the actual parameter
That is very important, soft cursors are nothing but woe.

> * Encourage programmers to use consistent long and short commands for the shell part
> * leave fullscreen mode by colon and enter by ESC
Very sensible.

> 
> Questions:
> * Which keys/mechanisms to use for collapse/expand?
> * How to move between parameters on one level?
First, to broaden the topic and make discussion easier, I would like to
adopt the terms class and object, where objects are what we want to
manipulate, and classes are groups of related objects or classes. So,
for instance, we would always have a top-level Main class, which could
contain an effects-rack class, which in turn would contain multiple
plugin classes each containing several "parameter" objects. Makes sense
so far?

A main key (could be enter) would operate on whatever is selected: a
class would be expanded or collapsed depending on its previous state,
while an object would be brought up for editing. We'd have to come up
with an extensive set of editing keys to manipulate objects, and another
set of keys to manipulate classes (e.g collapse all, collapse up two
levels, jump to next class). However, in my mind, a lot of the
navigation tedium would be rendered needless by the search function.

> * What about real menus (as in file, view, edit,...)?
I don't care much for menus: they waste my time. I think the command
interface is there to handle one-shot functions like these. (see below)

> * Can one assume, that OSC is always the easiest/fastest choice and hardcode it?
OSC is by its very nature Open, i.e there are no real definition of what
it is. Besides, there are some OSC libraries out there. A library such
as the one we are pondering should basically be there to make it
extremely useful to create front-ends for applications, some of which
might already have been in existence for a long time. I think it should
most likely limit itself to managing "objects" (like parameters) and
"actions" (load, save, reset, etc.).

> * Would the commandline mainly just echo the fullscreen tree-structure?
> * Would the commandline hold special (non fullscreen) commands?
I think the two modes should be mutually exclusive, except where there
are strong reasons to do otherwise. The "visual" mode is well suited to
navigating large collections of objects and modifying their values in
real-time (e.g while playing, experimenting to find a new sound). The
command interface, on the other hand, is perfect for dealing with one
shot actions or defining/performing complex actions. Some examples:
:write mypatch.xiz
:read mypatch.xiz
:route LFO1 OSC1
:set polyphony 32
:set polyphony 0
:set arpeggiate 1
etc.


> 
>   I thought about a few of the questions and here are my tentative answers:
[...]
> * 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.
But, as various groups are collapsed at the start, it is still fairly
easy to go down the tree to the desired parameter. For instance, I'm
sure, just like me, you've configured the linux kernel often enough
through menuconfig that you know pretty well where to go if you want to
enable a certain driver. Also, a sufficiently powerful search feature
would eliminate much of the need to "poke around" for something.

> 
> * 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.
I really don't feel we have any need for menus if we have a command
interface. But if you really want one, go ahead. :)

> 
> * 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
> name - change to level "name". get name - get current state, set
> name <value> - set parameter name to value. Perhaps some more
> symbols are needed to show things like sublevel, boolean, integer,
> float, string or list/enumeration. Perhaps get can offer that info.
>   That way a lot can be done by the basic interface infrastructure,
> without the programmer having to worry about getting all the names
> correct a second time round.
I thought of something similar yesterday, but I doubt it would be very
efficient. 

>   This would make some thing a little longer perhaps, but very
> consistent. Still shortcuts might be nice. Perhaps they can be
> implemented as aliases/substitutions:
> alias filter_res='set synth/filter/resonance'
>   ?
I'm just not sure what the point would be if one could simply hit slash
and type "filter reso", hit enter, and be immediately positioned on the
right parameter. The only benefit I can think of would be if one wanted
to assign a value to multiple controls, as in:
:set detune OSC[23] 5

> 
> * Would the commandline hold special (non fullscreen) commands?
>   Should one allow for it or wouldn't it be counter productive at
> this point? One idea might be to allow setting a whole level in one
> go. Good for setting plugin parameters. So you might do:
> ls effect/reverb
> room size
> reverb time
> bandwidth
> damping
> dry
> early reflection level
> tail level
> set effect/reverb 50 4.0 0.6 0.6 0 -18 -20
>   Another thing, which I'll enter into the file shortly: have a
> pager for the shell output, or at least allow to set one!
A pager is always a good idea, also the ability to pipe to external
commands and back.

> 
>   So I ope, this doesn't seem too pointless or unorganised... Please
> someone pounce and make me see the errors of my ways. :-)
This is a very interesting discussion. I had never thought in terms of
interface design before and what works for me or doesn't. It's also
interesting to see the difference among users.

Cheers,
S.M.
-- 


More information about the Linux-audio-user mailing list