20 Jan
2011
20 Jan
'11
8:29 p.m.
Excerpts from S. Massy's message of 2011-01-19 20:23:40 +0100:
I've read that braille displays have between 18
and 84 characters, 40 is
the most common variant?
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..
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
On Wed, Jan 19, 2011 at 10:52:55AM +0100, Philipp
??berbacher wrote:
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.
Excerpts from S. Massy's message of
2011-01-18 21:05:40 +0100:
Ah, yes, I had overlooked that.
[...] On Tue, Jan 18, 2011 at 07:40:50PM +0100, Philipp
??berbacher wrote:
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. 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. 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. 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.