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. -- _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
