21 Jan
2011
21 Jan
'11
7:43 p.m.
On Thu, Jan 20, 2011 at 08:29:27PM +0100, Philipp ??berbacher wrote:
[...]
I've read that braille displays have between 18
and 84 characters, 40 is
the most common variant? Well, more or less, since 40 characters offers the best
compromise of
usability, portability, and affordability.
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.. As I said, the main issue
seems that it highlights the message in a
non-standard way that brltty won't track. But, as I've never used any
other curses-based ruby applications, it could be specific to that
binding.
[...]
Wikis are fine,
actually, I like them; they are probably better for
collating information as well. And, yes, I can't stand forums, I avoid
them like the plague. :)
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.
At this point, I am thinking
that what is more likely, and what could be
more benificial, would be that some of this work might potentially be
ported back into ecasound. A standalone Text-based LV2 host is required,
because many LV2 plugins are softsynths and require a separate
interface, but many are also effects, and, for that, ecasound as a host
would be quite welcome.
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. 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. 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,
Jack goes without
saying. Midi would probably be the next priority in
line, since it seems many LV2 plugins would be useless without it.
including extensions that make sense. The language
will need to be C or
maybe C++.
Right. I will need to have a look at the LV2 reference to see exactly
what extensions are available and which would make sense.
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.
The basic task for the UI would be:
* Enumerate parameters from host (I believe with groups as well).
* Build a coherent list of groups and subgroups of parameters with type
and value range.
* Allow for a sane way to navigate and modify said parameters.
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
Very
true. But this part seems to me more straightforward then the rest:
what we need is easy recognition and manipulation of parameters,
ultimately, with the ability to save and retrieve presets.
I won't tell them just yet so your fantasy can
roam freely.
Cheers,
S.M.
Regards,
Philipp
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user