[linux-audio-user] Jack Rack & machine speach questions - (WAS:multiband compression with ecasound and ladspa)

From: Mark Knecht <markknecht@email-addr-hidden>
Date: Wed Jan 19 2005 - 19:58:40 EET

Hi all,
   Going in a slightly different direction here...

   I was busy yesterday and didn't follow this thread in its entirety
but I think it would be a very interesting project to have a few
sighted folks potentially work with a few people unfortunate not to
have their vision and try to create some basic audio elements that
were more advanced in their capabilities but served certain needs that
an app like Jamin might not address due to its graphical complexity.
If there are others out there that might be interested in this area
then let's talk on list of off.

   Part of my interest is that having, until recently, been a beta
tester for Waves plugins I found over time that I got better sound in
my work using the most simple plugins. I came to think that either I'm
too dense for the most complicated ones (certainly a possibility!) or
that keeping things simple has audio advantages. I'm also certain that
folks that live without sight probably have hearing that more finely
attuned to small changes than I do having spent some years in rock
bands. Putting those two ideas together leads me to ask if creating
some simple plugins that address the vision issues that Julian
originally brought up might not be a good contribution?

   My first idea was to use the info provided earlier that Jamin is
really using ladspa plugins and consider Jack Rack and a simple set of
ladspa plugins to do something akin to a Waves C4. From there maybe
I'd need to do some latency adjustments, etc., to get something that
had reasonable frequency characteristics but thought that could come
later. However I started putting filters into Jack Rack and found I
don't get how it works. Nothing (or inconsistently little) shows up in
QJackCtl's connections window.

   Also, I know nothing about text-to-speech software, assuming folks
without sight are using that. I'd be interested in learning a bit more
about that along the way.

  So, at this point I'm sort of hanging out and seeing what people
think of the idea and who might like to participate. Certainly it's
open to anyone, but I would prefer a fairly low-key group due to other
time commitments right now.

   Anyone interested can certainly write me back or sign up to be the
leader. I'm cool with any level of participation on my end.

Cheers,
Mark

On Wed, 19 Jan 2005 11:23:35 -0600, Jack O'Quin <joq@email-addr-hidden> wrote:
> Mario Lang <mlang@email-addr-hidden> writes:
>
> > Janina, I certainly understand your point, but I also think there
> > is a danger here. We shouldn't tell people that if they *only* use
> > GTK2, all is well. After all, I still prefer the text based
> > user interfaces very much above using Gnopernicus and GNOME. I wouldn't
> > like if GNOME accessibility ment that flexible program design goes
> > down the drain.
>
> I didn't take his message in that sense. Just that it may be possible
> to do something with less than a major version rework of JAMin.
>
> > Jack, I really like the idea of expanding on the OSC interface and making
> > parameters OSC controllable, that allows for easy scripting and
> > remote control from whatever app you might end up needing it.
>
> Agreed. It would be good to have. Eventually, someone will probably
> provide general support for passing MIDI controller input over OSC.
>
> That might make a good "eyes free" interface.
>
> > That said, yes, it is wonderful that GTK2 now offers some sort
> > of accessibility support, but I am not convinced that this is
> > the best we can get. The UNIX idea, keep it simple and flexible, is
> > what fascinates me about Linux/Unix apps, not "a desktop".
> > In fact, judging from my personal taste, I am not sure if I am going
> > to use GNOME for much else than running Mozilla (if that ever
> > starts to be useful). I still feel that using a classical GUI
> > if you are blind is an error per design. True, it might be a good workaround,
> > but it is in no way the ideal interface. And it wastes CPU cycles,
> > maybe even increases latency, to use all the overhead...
>
> Not the best, but better than nothing, perhaps.
> --
> joq "If it's stupid and it works, it ain't stupid."
>
Received on Thu Jan 20 00:15:03 2005

This archive was generated by hypermail 2.1.8 : Thu Jan 20 2005 - 00:15:10 EET