> Date: Mon, 12 Apr 2010 02:16:40 +0200
> From: julien@email-addr-hidden-lab.de
> never saw anyone doing that. So if you have pairs of information, try to put
> them in one or the other half of these 80 chars, not somewhere in between.
The code attempts to use a single 40 character line as per you comments on
braille displays, the parameters at the left, value at the right and always at the
same position - I can pack them together if you want, value right next to the
parameter name but for visual display that is difficult to read. The line width
is going to be configurable anyway, currently it is coded to 80 characters and
the parameter display uses a little under 40.
> One thing, that the Bristol CLI still lacks, is cleaning up the console
> settings. If you use readline or other curses functionality, you need to
> stored the settings of the terminal, before you start curses.
Fixed this.
> About quicker navigation. Finding a parameter you wish to change:
> :find cutoff
> Brings you to all params containing the string "cutoff". Although in this
> case I'd even go for:
> /cutoff
That is a nice suggestion, it is now implemented:
/lfo
Search for any synth parameters that contain lfo. If there are lots then they
are displayed over a couple of lines. These may use all 80 characters at the
moment until the line width is user configurable.
/^lfo
Search for any synth parameters that start with lfo
In both cases, if there is only one match then the line is completed. If you
enter when there are multiple matches it will move the parameter to the
next higher one.
> For the readline interface. Setting a filter parameter say with the command
> "filterset". In Bristol you'd type ':' for the readline mode and then you'd
> do:
> filt<TAB>
> This should complete as far as possible, or you do:
> fit<TAB><TAB>
Have implemented TAB completion for search operations:
/lfo<TAB>
Complete the word if possible, otherwise list them.
This is also done for the insert mode:
:rea<TAB>
will complete to ':read '. If no match is found from the commands list then
it will search the synth parameters so that they become commnads:
:oscbtr<TAB>
:oscBtranspose [then give the new value and enter]
I will work on accepting incompete but unique commands, the set of
them is limited so there will be little duplication anyway.
> About quicker navigation. Finding a parameter you wish to change:
> :find cutoff
> Brings you to all params containing the string "cutoff". Although in this
> case I'd even go for:
> /cutoff
Agreed.
> co<TAB>
> [making]
> core
> So you go on with this line:
> core shu<TAB>
I am not sure if I will also do completion on anything but the first word of
a command, will have to see. It is kind of like this: the command set is not
going to be particularly rich in context - it's not a shell or anything so I
don't see much activity going on in the file system space for example.
> help all - print all command-names.
> help [command] - print help for the specific command
> or help category - print all the commands of the category and their meaning.
> As to category or command, in the syntax, that is completely up to your
> liking and judgement of the application. When you only have a few commands,
> help [command] will be easier and quickly done. When you have loads of
> commands, help [category] will do the trick as well. You don't need to supply
As yet there are no commands implemented, will work on them:
find
read /* =load */
load /* =read */
import
write /* =save */
save /* =write */
export
help
set /* control key to function, debug, linewidth, etc */
midi /* channel, debug */
quit
Er, actually quit has been implemented. Import and Export will take the current
memory which are normally saved in the ~/.bristol/memory cache and copy it
to/from another file (no filename completion is envisaged - again, it is not a shell).
I can add to the list of commands but the above are targetted at the first release.
Other stuff will be done with enhancement requests.
> the extra help [command] in addition. It's easy enough to navigate it.
> Yet beware of the small text-terminal. Usually it's set to 25-29 lines per
> screen. So if you have loads to print, use a pager (less). The (n)curses
> library offers a global variable called LINES, which should hold the number of
> lines, the screen has. The same goes for COLUMNS.
I will give access to lines and columns settings and keep the help terse - perhaps
I can rename it from 'help' to 'hint'? Which line of the screen is displayed on your
braille pad - you are talking about 25 lines so I take it you can move the current
one up and down easily enough. If so, how is that done - do you use control codes
that are then not available to the bristol CLI?
Julien, or anybody who is playing with this CLI, if you want this updated version
let me know and will post it again but I don't have anything like SVN or GIT active.
Kind regards, nick.
_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
https://signup.live.com/signup.aspx?id=60969
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Mon Apr 12 16:15:02 2010
This archive was generated by hypermail 2.1.8 : Mon Apr 12 2010 - 16:15:02 EEST