Re: [LAU] (LV2) plugins and accessibility

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

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Fri Jan 21 00:15:01 2011