On Thu, Jan 20, 2011 at 08:29:27PM +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. 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. > 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. > > > > 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.. 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. [...] > > 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. 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. :) > > 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@xxxxxxxxxxxxxxxxxxxx > http://lists.linuxaudio.org/listinfo/linux-audio-user > _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
