New subject: (LV2) plugins and accessibility

20 Jan 2011

Excerpts from S. Massy's message of 2011-01-19 20:23:40 +0100:
...
  On Wed, Jan 19, 2011 at 10:52:55AM +0100, Philipp
??berbacher wrote:
  Excerpts from S. Massy's message of
2011-01-18 21:05:40 +0100:
  On Tue, Jan 18, 2011 at 07:40:50PM +0100, Philipp
??berbacher wrote:
  So I guess what it really takes is a host that
provides a good CLI-UI.  Yes, or perhaps a host allowing interaction with the plugin
through a
 TCP port like LinuxSampler does.  So that one can write a CLI-UI as well as another
UI to control the
 host? Similar to ecasounds net-eci?
 I'm not sure that would work well for GUIs because some plugins give
 fancy feedback in realtime which would need tighter coupling of backend
 and GUI than TCP can provide, I think. In my opinion it's wiser to focus
 on what's needed.  Ah, yes, I had overlooked that.
 [...] If we manage to write a really good host then a second version or a fork
with a GUI could still be written, but I don't expect anything like
that. The host will need at very least an rt-thread and a UI-thread
anyway, so some separation will be there in any case.

...
   I've never
seen a braille display, let alone used one, so it's hard for
 me to imagine the braille-specific problems. I'll definitely look at  Think of
one line of (often) 40 characters which you move around on the
 screen. One of the most important factor is focus-tracking, i.e whether
 the braille terminal application (brltty on Linux) can do a good job of
 following the cursor around. I've read that braille displays have between 18
and 84 characters, 40 is
the most common variant?

...
   bristol. Can
you provide me with examples of CLI-driven programs that
 get it wrong and why they get it wrong?  Well, as far as getting it dead wrong... I
recently was interested in
 trying a mail client called "sup" but, either there is something faulty
 with its use of the curses library, or something is wrong with the ruby
 implementation of curses, but my display just won't track the
 highlighted message, thus making it next to unusable. Funny enough this is the mail
client I use :)
It certainly doesn't limit line length, but I think braille displays
have a way of dealing with this Problem. I have no idea why it doesn't
work with sup, but sup has a bunch of problems anyway..

...
  But, coming back to audio software, I think it's
more a matter of
 convenience/inconvenience, rather than right/wrong. Taking the example
 of Nama (which BTW is an absolutely awesome godsend to the text-based
 audio world), it uses a readline, command-driven interface, which works
 great for things like adding tracks, creating and assigning busses,
 adjusting pan and volume, and so forth. However, when it comes to
 fine-tuning the parameters for a compressor, this same approach can be
 tedious, because usually, even if one has a good idea of what the
 starting parameters should be, one still needs to fine-tune things by
 ear, and writing things like
 mfx GH 3 + 5
 mfx GH 5 - 0.2
 ...then realising you overcompensated and doing
 mfx GH 3 - 1.5
 ...can be tedious, compared to, say, using up/down arrow and then shift
 up/down to fine-tune parameter values. Which is why a vi-like interface
 allowing both a visual and a command mode is an excellent way of having
 one's cake and eating it. :) I see your point. I know nama but I haven't
really use the text frontend
and the GUI isn't nearly as powerful.

...
  On the other hand, I remember, many years ago, someone
was trying to
 develop a text front-end for ardour, but it was entirely keystroke-based
 and I found it very difficult to use compared to ecasound's interactive
 mode...  Also good to know, but I doubt it even builds these days.

...
   What I'd
be interested in is a reliable host that can be controlled
 by using the keyboard. Fancy GUIs can't be controlled with the
 keyboard in a comfortable way, CLI-programs can. If the program is
 comfortable to use for the kings of CLI it's as good as it can get :)

 Maybe we can write it together, but mind you, while Rui calls himself
 the uber-procrastinator I AM the uber-procrastinator (Julien, I'll sing
 'Enemy Aprils fool', hopefully before April). I'm also only a novice
 programmer. However, I think we could do it if we take one step at a
 time. You have the UI-expertise, we all have a little programming
 expertise and I think we could ask more experienced programmers if we're
 really stuck. So we have expertise and a goal, what remains is getting
 it off the ground, effort and time.  Sounds good to me. The fact that UI and DSP
are indeed separate meants
 that it's at least likely to be simpler than I feared it might be. 
UI and DSP need to be at least in separate threads. I was about to
create a wiki for this project to collect ideas when I realised that a
wiki is probably not very comfortable for blind users, probably better
than a forum, but I guess keeping it at mails is better for now.

So what I have so far:
the DSP part, the backend needs to be rt-capable, jack for audio, maybe
midi at some point and of course capable of hosting LV2 plugins,
including extensions that make sense. The language will need to be C or
maybe C++.
The frontend could use ncurses, which is a C library but has bindings to
many languages. I have no idea yet whether it really is hard to write
UIs in C, but I'd prefer taking the native language over bindings in
general.
Those are all just programming aspects, and I'm not familiar with any of
that, so it would take me quite some time to get somewhere at all.

The probably even harder part is figuring out what the program should do
and how the user should be able to control it. A program that isn't a
pleasure to use won't be used. I only have a few vague ideas so far and
I won't tell them just yet so your fantasy can roam freely.

Regards,
Philipp

Re: [LAU] (LV2) plugins and accessibility