[LAD] Interface development for the blind (starting from Bristol)

[Nick Copeland]

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




> Date: Sun, 11 Apr 2010 21:41:59 +0200
> From: julien at c-lab.de
> To: nickycopeland at hotmail.com
> CC: lsutton at libero.it; linux-audio-dev at lists.linuxaudio.org
> Subject: RE: [LAD] Interface development for the blind (starting	from	Bristol)
> 
> Hello Nick!
>    Just got back and found a lot of mails. :-) So I'm replying in reverse 
> order. :-)
>    VI is fine with me. But cursor keys would be great. Reasons are obvious: We 
> might know of VI and you seem to be used to it. But many others don't. Second 
> minor reason: The best hand to fool around with is usually the right one, with 
> me as well. So the keyboard is to the right of the computer. The cursor keys 
> are farther to the right of the keyboard, so not so much stretching. And on a 
> standard keyboard the cursor keys are easier to spot (they have their own 
> block to themselves.
>    But of course working with h/l and j/k is very fine to start and see how it 
> works out. NJo problem about the X-libs having to be there. the ugliness would 
> have been to start X. It adds overhead and loads of things I don't need, and 
> thus don't want. :-)
>    Onto the next mails...
>    Kindly 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
 		 	   		  
_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
https://signup.live.com/signup.aspx?id=60969
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20100412/22895a22/attachment.html>