That is a good point. A text based interface is quite an abtraction of something that has been written to be a GUI which means debug output may well be useful. Since that does damage the display, with or without brail, it does beg the question as to whether it could be 'rewritten'. It could be done with some IO redirection pipes, suitable code in the 'raw' IO channel to understand where input came from using a bit of extra select() in there to bring the channels back together and apply suitable output depending on where the different CR were, or that incomplete user input lines were rewritten after each debug line? And then a bit of NL->CRNL for the raw mode interface. Not something I would want to code for a prototype but is unfortunately something that could better be coded in advance than bolted on the end? Nick. _________________________________________________________________ Hotmail: Free, trusted and rich email service. https://signup.live.com/signup.aspx?id=60969

Hello again! When I want to get debug output, I have several choices. Besides the usual, piping output directly to a file: command &> log I can use my braille display to cut-copy-past text. It's similar to the old mouse driver GPM I think. You could highlight a line or more and then copy it to somewhere else. Files are of course the easiest way, because you can directly attach them and the programmer might have parsing methodsfor the output. Perhaps it might get long and an exact output might help. but that usually only applies to very big apps. Warmly yours JUlien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

So it is back on list, good. Something I can make available for bristol in the short term is a VI like interface navigate left/right through the synth parameters with h/l and change their values down/up with j/k (with shift key accelerators and control key decelerators). The nice thing about the interface is that the parameter control can be done quickly with one hand whilst the other one plays the piano. A readline interface might need both hands on the QWERTY to change a value. Each change in these keys results in a short line of text output giving parameter name/value and the audible signal output from the synth. I have this operational already for bristol although I would give it a couple of days to clean up some pretty gruesome edges (you need to use two terminal, one for GUI one for engine at the moment to get it to work for example) but I can clean them up a lot for sometime next week. The code does not need X11 to be active to work but it does still need X11-dev to compile and X11 run time libraries to operate. It kind of cheats and presents a totally dummy window to the GUI - it thinks it has a window open which I need because of the signal paths used to set parameters in the GUI into the engine. Of course, if you don't like VI this is going to be a bit of a pain in the butt - I love it which is why I took it as a starting point. Medium term I can have a mapping file for the keys you want to use. I am not sure I could code another audible tone to represent the value of a parameter, the issue is that audio comes from the engine emulator but the GUI or CLI interface is to brighton. To present an audible signal of the parameter value I would have to rework the engine as well. It is possible, but not in the short term. This can be a prototype for people to test next week, after that we can work on the necessary refinements. The code is only for the Prophet-1 emulator at the moment. It can have memory save/load options operational. If people really object to VI I can work more on the arrow navigation keys but I would have to configure a very raw interface to get that. Regards, nick,. "we have to make sure the old choice [Windows] doesn't disappear”. Jim Wong, president of IT products, Acer _________________________________________________________________ Hotmail: Trusted email with Microsoft’s powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969

Hi Julien, So, the best way to start this message is to say you are in for a world of hurt. Prototype code is not likely to be fun. You can get hold of a file below for version 0.60.0p. You should be able to do the following; ./configure --disable-x11 make You might get past this point - lets see. If not mail me, either onlist or off, I prefer off as we will be dealing with specifics of your system and my proto code. If you have issues with the interface design then it should naturally be onlist as that will be interesting to more people. You will still need X11 headers and probably libraries to build it, I will work that out of the final release. The final code will not link to the X11 libraries but it still builds the libbrightonX11 as well as something called libbrightonC11 for command line only. http://bristol.sf.net/files/bristol-0.60.0p.tar.gz Assuming this actually compiles and installs then you can do the following: startBristol -cli -mini For anybody else who wants to play with the CLI then building the code WITHOUT '--disable-x11' will be able to use the CLI at the same time as the GUI with the following options: startBristol -cli -pro1 -window Change a CLI parameter and the GUI will track it. You will get some startup messages, then it should finally say 'Hi!' on the braille. You then have the following commands: Cursor motion keys: Left/Right - navigate through the parameters. Up/Down - change the parameter values The value changes are VERY coarse: +/- 10%, I might make this configurable but this will give you very quick changes to params to hear the differences - if you like them then go for finer adjustment. General keys: Dont worry too much about these to start with - you have cursor keys: The idea behind JK is the following: j/k is up/down for the parameter value, <Shift> J/K is up/down even more. <Control> J/K is in small amounts to control the parameter value. You can remap them. CLI: h left CLI: l right CLI: ^k incmin CLI: k inc CLI: K incmax CLI: ^j decmin CLI: j dec CLI: J decmax CLI: M memUp CLI: m memDown CLI: r read CLI: w write CLI: x toggle CLI: u fineup CLI: d finedown CLI: U up CLI: D down CLI: : insert At the moment I don't handle <Shift> or <Control> on the Up/Down cursor keys but I will work that into an eventual release. Mem Up/Down should print a message to say whether the memory is free or assigned. You can remap the keys by editing the profile file for the emulator if you want: for the mini it is ~/.brighton/memory/profile/mini. The cursor keys are always available, they do not get put in the profile file. <Control-C> and <Control-D> will quit the engine and GUI. You will have to save a memory to get the above text in the profile file: the above mappings are the default ones so do not appear in the profile but when you save it they get placed there. The ':' will give you an 'insert mode', a bit like readline but this code is not finalised - eventually it will accept commands to search for synth parameter with completion, have engine commands to adjust its operation. At the moment it just has up/down edit history and quit/exit to leave the app but ^d and ^c do that anyway. As with 'vi', every line in ':' mode will print a ':' at the start of the line. To leave it type ESC. At the moment I have only added in the parameter descriptions for a few emulators, the others will give you (NULL) or empty parameter descriptions: -pro1, -mini, -b3, -juno, -axxe, -bme700 You will have to tell me if the text is a bit terse/short. If you cannot understand what the parameters do then let me know. There are a few emulators that I probably cannot convert to this interface - some of the layered synths (OBXA/BIT/Jupiter/pro10) use some really odd stuff in the GUI to manage the different layers of the synth, they do not lend themselves well to this interface. By the time the code goes out though I should be able to give you a dozen emulators. You can try all of them now but they will not give you much indication of the parameters you are changing. To give you an idea of what you can expect if you even get this to compile and install, here is the edited output from: % startBristol -cli -mini ... going operational: 9af8008, 9af8370 Hi nicky! 01 Glide : 117 02 Mod : 0 03 Osc1 Tranpose : 3 04 Osc2 Tranpose : 2 05 Osc3 Tranpose : 4 06 Osc2 Tuning : 489 07 Osc3 Tuning : 526 07 Osc3 Tuning : 626 07 Osc3 Tuning : 726 07 Osc3 Tuning : 826 07 Osc3 Tuning : 926 07 Osc3 Tuning : 1000 07 Osc3 Tuning : 1000 To get this I used 'l' to navigate to 'Osc3 Tuning' then 'k' to change its value. It could have been done with the cursor keys too. The string that is printed should be the current line, ie, it should not scroll off of your braille display as I don't append a linefeed, it should be prepended. The values are represented a 'per mil', they are actually floats and I can make them floats in the display too (perhaps another config option?), it's just that with k, K and ^K you can adjust values with +0.01, +0.1 and +0.001 (respectively). The concept is that j/k is up down. <Shift J/K> is up/down by even more, and then <Control J/K> is small, controlled amounts. Made sense to me, if it is not functional I can change it or you can remap the keys. I am open to changes to the interface, the data presentation, etc. Kind regards, nick "we have to make sure the old choice [Windows] doesn't disappear”. Jim Wong, president of IT products, Acer _________________________________________________________________ Hotmail: Trusted email with powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969

Hello Nick, hello all other interested devs! :-) I just tested the first version of the CLI from Bristol. In general it works fine. Very easy, the cursor keys work, the display is just fine. The value and parameter name are not so far apart, that they wouldn't fit on 40 characters. So even better. Something to behold, for really cool CLIs, that blind people should find useful. A braille display has mostly 40 chars. The display can usually be set to the left or to the right, no middle position. At least I 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. 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. Readline has it's own set of functions to do that for you. There you only need to take care of interupt handlers. When your done executing, you need to restore the original settings. Otherwise you get non-appearing keystrokes in the shell, prompts appearing anywhere, but not where they should be. So then Nick has put some other questions to me, about how to continue, which I think is very helpful to others, who might be interested. 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> which should display all possible matches. Meaning: commands, that start with filt. Just the usual behaviour, because one is used to it. Even in CLIs there are parts of intuitivity. It's just different from the GUI intuition. :-) 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 (in VI terminology). But no problem with find or search. A short word on TAB-completion in Readline. It's a standard feature. With nothing configured, it will complete filenames. But you can supply readline with your own list of commands. An easy example can be found in the readline info pages. I suspect a much more complex yet marvellous example is asterisk's CLI mode. It was only designed for a bit of controlling, testing and debugging, I suspect. But it understands things like: co<TAB> [making] core So you go on with this line: core shu<TAB> I never figured out how to best write code, that will notice spaces and find the next word it can complete. Not necessary, but if you have something complex, huge and feel there's a need for it. Those guys did it and did it well. I hever had to complain. :-) A word on help. Bristol speicific: just use :help for the command, easy enough. And how to use it? Well at least offer something like this: help [print major categories or some of the basic commands] 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 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. As nothing will be done, while reading help, a simple system-call should be enough to call less. Write your help to a tempfile, best with the PID in its name and open it with less. When shutting down, just clean up all the files, with your name-scheme and PID, or clean up directly afterwards. Another question arose: How about capital letters on a braille display. A braille character in the computer world has 8 dots = 2**8 = 256 chars. So capitals are no problem. More problematic are unicode characters. I know, that one braille driver can handle them, not sure about the other one. But I can read normal German umlauts and the typical western European characters on my display. so that should be a matter of terminal and braille-driver configuration. I hope this wasn't too long for the info it contained and I hope, that it was clear. If something was fuzzy, just go ahead and bombard me with your questions. Kind regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

Hello Nick! Again such a nice update. Thanks for that. I can move my braille display easily enough. The system screen stays the same, so every bgraille display has navigation controls of some sort to move the small "window", that I can see, across the real screen. Completely in order for reading, it doesn't take time and the controls are built to be easily accessible while reading. As I said, the complex command completion is only something for larger programs, which huge command sets. I just mentioned it, since this thread was partly opened to do some general talking as well. I'm fine with no TAB=completion on filenames. They look short enough. The command set you envisage now, sounds very reasonable and completely satisfying. In the search department you again got one better than me "/^lfo". Outputting search results all over the 80 chars is OK again, as it is reading material, not up to realtime changing. The parameters as they are now over the 40chars look fine. No need to close the distance. I'm one for the lookers as well. :-) Hard to believe, but there it is. I always liked beautifying things. :-) And of course I'm already excited about the next version. Give me the link or an attached tarball, I don't mind which. This is really fun. I love it, when you start something, have a really intuitive interface and immediately get sound and are able to change everything to your hearts content. this is going marvellously well. The idea of using the VI-type of interface was a great one! As you can see, I'm enthused about it. Kindly and greatfully yours Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de