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