Paul Davis <[EMAIL PROTECTED]> writes: >>Great! Another linux audio tool inaccessible >>to the blind. I am feeling very very left out... >> >>Is there any chance that some of you might realize >>that providing such functionality in a UI independent >>way would be great? Every new LAD program I see is >>basicly GUI dependent, and its functionality can not >>be easily used from without command-line or ncurses environments. >> >>I know, I know, we are not important to you, and a too >>small group of interest. But I had to make my >>frustration some air. > > i understand your frustration. but please remember that the challenge > of making non-visual interfaces for editing multi-track audio that can > be used dynamically (i.e its not just a file saying when to play which > audio chunk when, and you edit the file with a text editor) ... this > is still basically a research project that could probably justify at > least a masters, if not a full doctoral degree :) Well, I am sure the non-visual interface problem for multi-track recording is also unsolved. However, Kai managed to write a multi-track recording tool which is massively useful to the blind. And it even has a GUI, although optional.
> the visual interface frees the user from having to remember a > potentially huge amount of information because its made persistent in > the visual display. DOnt get me wrong. I totally understand that visual interfaces are useful to some kind of people, but * Alternative, scriptable, interface have their advantage even for the non-blind * Designing your app more modular will make it easier to extend it later. I know, we should be hacking alternative interfaces ourselves, and we do this when we are given the opportunity. But last time I was motivated to do some rewrite work on a LAD GUI tool, it was so highly interwoven with the underlying Toolkit in use, that it was no fun, and I gave up after some hours of headache producing source-code review. > i have not yet seen or heard any ideas about how to use a plain text > interface to do most of the things that a visual editor like this > makes possible. dynamically positioning audio when you can see it is > an completely different process from editing a text playlist, for > example. I am convinced that if we actually allow us to use the functionality you describe, we will invent a interface which is useful to us. It is totally clear that I can not expect from Free Software coders that they find the optimal interface for the blind. But if we are given the ability to somehow use the underlying functionality, we can investigate this. I've already written ecasound.el. I am sure I can come up with some interface to an interesting audio app, if I am given the ability to do so. > programs like this are typically 70% GUI and 30% audio backend. asking > the developers to take such a program and remove the GUI is really > like asking them to develop a second program. What I essential do is asking developers to implement their 30% backend engine in a well-defined library, which can be used by their 70% GUI, and by other code which might want to. -- CYa, Mario | Debian Developer <URL:http://debian.org/> | Get my public key via finger [EMAIL PROTECTED] | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
