1 Nov
2005
1 Nov
'05
12:39 a.m.
I am looking for suitable hardware to handle digital i/o between a Linux
system and an RME ADI-2 ad/da converter that I just bought. I don't need lots
of channels, but reliability of the data transfer is important, including
jitter reduction. An RME card would be excellent but it is somewhat outside my
budget. Also, connectivity to a laptop would be desirable, suggesting either a
USB interface or waiting until http://freebob.sourceforge.net/ (the Alsa
firewire project) matures. I don't plan to run any OS besides Linux with this
hardware, so Alsa support is crucial. As this is for home/personal use I'm not
in a hurry. M-Audio hardware is high on my list of possibilities at the
moment.
Now to the software question: does there exist any sound editor with a
non-graphical interface, i.e., one that can be operated from the Linux console
for inserting, deleting, copying and otherwise editing audio? Due to a
vision-related disability I can't use a graphical display and therefore need a
text-only solution - but all the sound editors appear to require X11. Surely
it should be possible to design an audio interface to a digital sound editor.
Suggestions welcome.
I've discussed hardware on this list once before, and the USB options weren't
highly regarded at the time.
1 Nov
1 Nov
6:27 a.m.
On Tue, 2005-11-01 at 16:39 +1100, Jason White wrote:
Now to the software question: does there exist any
sound editor with a
non-graphical interface, i.e., one that can be operated from the Linux console
for inserting, deleting, copying and otherwise editing audio? Due to a
vision-related disability I can't use a graphical display and therefore need a
text-only solution - but all the sound editors appear to require X11. Surely
it should be possible to design an audio interface to a digital sound editor.
i have no doubt that its possible. i also have no doubt that there is a
PhD waiting for the first person to do this. you are talking about
developing an entirely new set of user interface metaphors for a
potentially very complex task. this is never easy, and doing it without
using the sensory input that the vast majority of programmers utilize
during their own interactions with a computer makes it even harder.
--p
7:30 a.m.
At 6:29 -0500 1/11/05, Paul Davis wrote:
On Tue, 2005-11-01 at 16:39 +1100, Jason White wrote:
well .. there is the SND sound editor, which is billed as 'the emacs
of sound editors' .. details here:
http://ccrma.stanford.edu/software/snd/
the interface for SND itself can be fully programmed in Scheme
(courtesy of Guile) or you can use Ruby too .. all of SND's edit
functionality can be broken out into scripts, and this means
extensive control over buffered edits, so it seems to me to be pretty
close to what Jason was looking for .. assuming it can build on his
system.
seems to me that, while its not exactly a 'set up and go' solution to
the problem of having an editor usable by vision-impaired folks, it
certainly has all the hooks and gubbins to bring such a thing into
existence ..
--
;
Jay Vaughan
Now to the software question: does there exist
any sound editor with a
non-graphical interface, i.e., one that can be operated from the
Linux console
for inserting, deleting, copying and otherwise
editing audio? Due to a
vision-related disability I can't use a graphical display and
therefore need a
text-only solution - but all the sound editors
appear to require
X11. Surely
it should be possible to design an audio
interface to a digital
sound editor.
i have no doubt that its possible. i also have no doubt that there is a
PhD waiting for the first person to do this. you are talking about
developing an entirely new set of user interface metaphors for a
potentially very complex task. this is never easy, and doing it without
using the sensory input that the vast majority of programmers utilize
during their own interactions with a computer makes it even harder.
8:31 a.m.
Now to the
software question: does there exist any sound editor with a
non-graphical interface, i.e., one that can be operated from the Linux console
for inserting, deleting, copying and otherwise editing audio? Due to a
vision-related disability I can't use a graphical display and therefore need a
text-only solution - but all the sound editors appear to require X11. Surely
it should be possible to design an audio interface to a digital sound editor.
i have no doubt that its possible.i also have no doubt that there is a
PhD waiting for the first person to do this. you are talking about
developing an entirely new set of user interface metaphors for a
potentially very complex task. this is never easy, and doing it without
using the sensory input that the vast majority of programmers utilize
during their own interactions with a computer makes it even harder.
--p
8:44 a.m.
it's easy for non-programing people to bring
"visions" regarding
interface design. (and i love do so :) as i know programers, it's quite
hard to establish a new standard. but imho the interface standards
(buttons, dropdown boxes, scrolling, menu-structure, etc.) are now a
couple of years old, and there might be better solutions for specific
tasks. audio seems to me like a good point to start.
i wasn't talking about such rudimentary stuff. of course there are
alternatives to these basic widgets and several audio applications (even
free ones) have begun to support them.
the point about a visual interface is that it acts as a "memory buffer"
for the user: you do not have to remember much about the structure of
the session because the structure is made visible on the screen. can't
remember precisely where you put a certain sound? how many copies of the
bridge riff did i put in? is the door slam before or after the creak?
its all there on the screen, just waiting for you to look at it.
as soon as you move away from a visual UI, you have to find some way to
avoid requiring the user to remember everything about the session. i
think this can be done, but i don't think its trivial or even easy.
the visual interface offers another hard-to-replicate feature as well:
trivially variable precision. if you try doing cut-n-paste based only on
audio feedback, you will find it quite hard/laborious to be as precise
as you might want to be. with the visual interface, its much easier to
use visual information to get the rough location of an edit and then
get to precisely where you want, without many steps. with audio feedback
based approaches, i think you will find yourself needing many more
iterations through the edit-play-edit-play cycle before you get the
location correct.
--p
5 Nov
5 Nov
11:01 a.m.
Paul Davis <paul(a)linuxaudiosystems.com> writes:
the point about a visual interface is that it acts as
a "memory
buffer"
As I understand it, ardour will be scriptable with OSC, which is
really great. A great deal would be simplified in my work when this is
working. (non-interactive interface).
I visualize much in my head, as the original author;) and I work very
quickly this way.
Tools for the blind and the deaf are the most powerful tools, in my
opinion;).
Don't get me wrong, I love a nice GUI too, but when I need to do
something quick, I have the steps in my head and need to get them out
of my head fast, giving a set of direct commands in a quick fashion,
is the best way, most often.
--
Esben Stien is b0ef@e s a
http://www. s t n m
irc://irc. b - i . e/%23contact
[sip|iax]: e e
jid:b0ef@ n n
1 Nov
1 Nov
8:58 a.m.
On Tue, 01 Nov, 2005 at 06:29AM -0500, Paul Davis spake thus:
--
"I'd crawl over an acre of 'Visual This++' and 'Integrated
Development
That' to get to gcc, Emacs, and gdb. Thank you."
(By Vance Petree, Virginia Power)
On Tue, 2005-11-01 at 16:39 +1100, Jason White wrote:
I don't think it needs to be *that* difficult. At least for a basic
editor for cutting, pasting, applying fades, etc.
After reading this post, I quickly posted the idea to my final year
students as a possible honours project for them. Some haven't yet
decided, and I thought this would be a good one. I was thinking of a
kind of "audio shell", with python-like slicing, but with
understanding of audio. This way, you could make the text very big
for people with reduced sight, or pipe output to a speech engine for
people with no sight. Or both.
I hope someone takes the project, because even though I don't think it
would necessarily be the big ground-breaking interface redesign you
thought it would require, it will give us something to work from -
usability data, and such.
Anyway, just my thoughts. You never know - it might be even pretty
handy for people like me that have 20/20 vision, but like to do
everything with the keyboard instead of the mouse.
Hmmm. I feel a grant application coming on.
Now to the software question: does there exist
any sound editor with a
non-graphical interface, i.e., one that can be operated from the Linux console
for inserting, deleting, copying and otherwise editing audio? Due to a
vision-related disability I can't use a graphical display and therefore need a
text-only solution - but all the sound editors appear to require X11. Surely
it should be possible to design an audio interface to a digital sound editor.
i have no doubt that its possible. i also have no doubt that there is a
PhD waiting for the first person to do this. you are talking about
developing an entirely new set of user interface metaphors for a
potentially very complex task. this is never easy, and doing it without
using the sensory input that the vast majority of programmers utilize
during their own interactions with a computer makes it even harder.
2 Nov
2 Nov
5:25 a.m.
On Tue, Nov 01, 2005 at 02:10:29PM +0000, james(a)dis-dot-dat.net wrote:
I don't think it needs to be *that* difficult. At
least for a basic
editor for cutting, pasting, applying fades, etc.
I agree, but others have
identified the challenging aspect - how to identify
with sufficient accuracy the point at which to apply an
insertion/deletion/block/cut/copy operation, and how to navigate through the
file with appropriate feedback. Audio feedback might be possible, but there
would have to be some provision for scaling the timing by different factors to
allow the desired moment to be pinpointed.
After reading this post, I quickly posted the idea to my final year
students as a possible honours project for them. Some haven't yet
decided, and I thought this would be a good one. I was thinking of a
kind of "audio shell", with python-like slicing, but with
understanding of audio. This way, you could make the text very big
for people with reduced sight, or pipe output to a speech engine for
people with no sight. Or both.
The latter part is handled by projects such as
Speakup, Yasr and BRLTTY which
provide, respectively, speech and braille display access at the console level.
There are also several screen magnification projects on offer, including the
Gnopernicus magnifier.
I hope someone takes the project, because even though I don't think it
would necessarily be the big ground-breaking interface redesign you
thought it would require, it will give us something to work from -
usability data, and such.
If someone does take the project I'de be interested
in discussing it further
and trying out whatever is developed.
3 Nov
3 Nov
3:52 p.m.
On Wed, 02 Nov, 2005 at 09:25PM +1100, Jason White spake thus:
No takers, I'm afraid. Maybe next year. I just don't have the time
to do it myself, although I might have a little play when I can.
--
"I'd crawl over an acre of 'Visual This++' and 'Integrated
Development
That' to get to gcc, Emacs, and gdb. Thank you."
(By Vance Petree, Virginia Power)
On Tue, Nov 01, 2005 at 02:10:29PM +0000,
james(a)dis-dot-dat.net wrote:
Yes, this is exactly why I love unix. All we need is to get something
text based and the rest is taken care of.
I don't think it needs to be *that*
difficult. At least for a basic
editor for cutting, pasting, applying fades, etc.
I agree, but others have
identified the challenging aspect - how to identify
with sufficient accuracy the point at which to apply an
insertion/deletion/block/cut/copy operation, and how to navigate through the
file with appropriate feedback. Audio feedback might be possible, but there
would have to be some provision for scaling the timing by different factors to
allow the desired moment to be pinpointed.
After reading this post, I quickly posted the idea to my final year
students as a possible honours project for them. Some haven't yet
decided, and I thought this would be a good one. I was thinking of a
kind of "audio shell", with python-like slicing, but with
understanding of audio. This way, you could make the text very big
for people with reduced sight, or pipe output to a speech engine for
people with no sight. Or both.
The latter part is handled by projects such as
Speakup, Yasr and BRLTTY which
provide, respectively, speech and braille display access at the console level.
There are also several screen magnification projects on offer, including the
Gnopernicus magnifier.
I hope someone takes the project, because even though I don't think it
would necessarily be the big ground-breaking interface redesign you
thought it would require, it will give us something to work from -
usability data, and such.
If someone does take the project I'de be interested
in discussing it further
and trying out whatever is developed. 
23 Dec
23 Dec
11:24 a.m.
Regrets that I didn't jump into this thread earlier--it is an old thread
...
james(a)dis-dot-dat.net writes:
Yes, this is exactly why I love unix. All we need is to get something
text based and the rest is taken care of.
No takers, I'm afraid. Maybe next year. I just don't have the time
to do it myself, although I might have a little play when I can.
--
"I'd crawl over an acre of 'Visual This++' and 'Integrated
Development
That' to get to gcc, Emacs, and gdb. Thank you."
(By Vance Petree, Virginia Power)
--
Janina Sajka Phone: +1.202.595.7777
Partner, Capital Accessibility LLC http://CapitalAccessibility.Com
Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada--Go to
http://ScreenlessPhone.Com to learn more.
Chair, Accessibility Workgroup Free Standards Group (FSG)
janina(a)freestandards.org http://a11y.org
On Wed, 02 Nov, 2005 at 09:25PM +1100, Jason White
spake thus:
> On Tue, Nov 01, 2005 at 02:10:29PM +0000, james(a)dis-dot-dat.net wrote:
> > I don't think it needs to be *that* difficult. At least for a basic
> > editor for cutting, pasting, applying fades, etc.
I am myself blind, and I also need to do this. I do my best with two
apps and am considering a third.
Ecasound does the fades and mixing for me quite well. See below.
The less familiar app, which I think you would find useful, Jason, is
Chuck Hallenbeck's wave editor, wedit:
http://www.mhcable.com/~chuckh/
There are other apps there which will be of interest, notably a
more speech friendly gramofile.
The other app I find promissing is Kirk Reiser's bsound available via
cvs from linux-speakup.org (if it's up).
> I agree, but others have identified the
challenging aspect - how to identify
> with sufficient accuracy the point at which to apply an
> insertion/deletion/block/cut/copy operation, and how to navigate through the
> file with appropriate feedback. Audio feedback might be possible, but there
> would have to be some provision for scaling the timing by different factors to
> allow the desired moment to be pinpointed.
I would agree that vision is extremely useful for this, but my
observations suggest vision alone is not sufficient. I've been in
editing sessions where some will say: "This looks like a good spot," and
then we listen and find there was some audible reason why it wasn't a
good spot after all. Ultimately, it's all about our ears, though sight
might help one zoom in more quickly.
My experience with both wedit and awe (bsound) is that finding candidate
starting points isn't too hard. What's missing is a hard stop somewhere
further in the file. I wish cI could define one, so that I could ask
some portion to play again and again while I decide if the starting
location is good, or not so good. What I find with both of these apps is
that I have to struggle to hit Ctrl-C, and then work my way back to the
start point to listen again. That's too much emphasis on stopping, in my
experience.
Guess I'll send Kirk and Chuck my RFE.
The other missing feature is some way to scrub meaningfully. The 104
isn't a great tool for scrubbing. Again, vision helps, but it's
ultimately about ears, so I should not think it too difficult to
interface some kind of wheel control for scrubbing. What do people use
with apps like Ardour?
Another thing I miss when working with wedit or awe is very precise
"Where Am I?" info, precise time, precise sample, etc. For editing
that's more important than a quick and dirty tool like wedit, this inof
would be quite important.
Now, if I extrapolate from what I can already do, and what I have
outlined above as missing, I see no reason why I shouldn't be able to do
similar precise things in a multi-track environment (like Ardour). The
only additional control would seemingly be identify the particular
track, or group of tracks, on which to operate.
Janina
After reading this post, I quickly posted the idea to my final year
students as a possible honours project for them. Some haven't yet
decided, and I thought this would be a good one. I was thinking of a
kind of "audio shell", with python-like slicing, but with
understanding of audio. This way, you could make the text very big
for people with reduced sight, or pipe output to a speech engine for
people with no sight. Or both.
The latter part is handled by projects such as
Speakup, Yasr and BRLTTY which
provide, respectively, speech and braille display access at the console level.
There are also several screen magnification projects on offer, including the
Gnopernicus magnifier.
I hope someone takes the project, because even though I don't think it
would necessarily be the big ground-breaking interface redesign you
thought it would require, it will give us something to work from -
usability data, and such.
If someone does take the project I'de be interested
in discussing it further
and trying out whatever is developed.
5 Nov
5 Nov
10:50 a.m.
james(a)dis-dot-dat.net writes:
I quickly posted the idea to my final year students as
a possible
honours project for them.
This is great;).
--
Esben Stien is b0ef@e s a
http://www. s t n m
irc://irc. b - i . e/%23contact
[sip|iax]: e e
jid:b0ef@ n n
1 Nov
1 Nov
10:56 a.m.
Jason White schrieb:
Now to the software question: does there exist any sound editor with a
non-graphical interface
Did someone already mentionend Ecasound?
http://www.eca.cx/ecasound/
Its a commandline tool for multitrack audio...
Cheers,
Malte
--
Malte Steiner
media art + development
-www.block4.com-
5 Nov
5 Nov
11:04 a.m.
Malte Steiner <steiner(a)block4.com> writes:
Did someone already mentionend Ecasound?
Might also be worth taking a look at GDAM.
--
Esben Stien is b0ef@e s a
http://www. s t n m
irc://irc. b - i . e/%23contact
[sip|iax]: e e
jid:b0ef@ n n
4 Nov
4 Nov
5:03 a.m.
I wish to thank mailing list participants for an informative discussion of my
software question.
Does anyone have any thoughts on the hardware question (reproduced below)
which I also raised?
On Tue, Nov 01, 2005 at 04:39:22PM +1100, Jason White wrote:
I am looking for suitable hardware to handle digital
i/o between a Linux
system and an RME ADI-2 ad/da converter that I just bought. I don't need lots
of channels, but reliability of the data transfer is important, including
jitter reduction. An RME card would be excellent but it is somewhat outside my
budget. Also, connectivity to a laptop would be desirable, suggesting either a
USB interface or waiting until http://freebob.sourceforge.net/ (the Alsa
firewire project) matures. I don't plan to run any OS besides Linux with this
hardware, so Alsa support is crucial. As this is for home/personal use I'm not
in a hurry. M-Audio hardware is high on my list of possibilities at the
moment.
10:50 p.m.
To clarify my hardware question, I am looking for a fully alsa-supported
device supporting reliable digital input and output using s/pdif, aes/ebu or
adat (optical or coaxial). S/pdif is most likely what I'll be using.
Connectivity to laptop computers id desirable but not indispensable.
The Core Sound Pdaudiocf (with a PCMCIA adapter) is reputedly good, but it
supports input only - no output.
Another option would be one of the M-Audio cards/devices, provided that Alsa
supports the s/pdif interface.
5 Nov
5 Nov
6:54 a.m.
HI
I use the M_Audio Audiophile on my master machine running Demundi
using the spdiff into and out of my DDX.
I lock the card to the Desk using envycontrol and found it fine
for digital work. No clicks or noise
cheers
Bob
PS I use RME for the multitrack machine and this is well suported in Linux.
Jason White wrote:
To clarify my hardware question, I am looking for a
fully alsa-supported
device supporting reliable digital input and output using s/pdif, aes/ebu or
adat (optical or coaxial). S/pdif is most likely what I'll be using.
Connectivity to laptop computers id desirable but not indispensable.
The Core Sound Pdaudiocf (with a PCMCIA adapter) is reputedly good, but it
supports input only - no output.
Another option would be one of the M-Audio cards/devices, provided that Alsa
supports the s/pdif interface.
--
Bearmusic
hearmymusic.co.uk <http:www.hearmymusic.co.uk>
7:06 a.m.
Jason White wrote:
I am looking for suitable hardware to handle digital
i/o between a Linux
system and an RME ADI-2 ad/da converter that I just bought. I don't need lots
of channels, but reliability of the data transfer is important, including
jitter reduction. An RME card would be excellent but it is somewhat outside my
budget.
Your requirements listed make me think that an RME card is definitely
the way to go. But you say that the budget is a problem.
Now, I always wanted a nice soundcard, with lots of inputs and proper
ALSA support. I always imagined myself getting a Delta 1010, or similar.
I would have preferred an RME card, but it just seemed way over my budget.
However, I was casually browsing eBay one day, and ended up buying a
second-hand RME DIGI9636 for £77 (I'm in the UK). Ok, I had to buy a
replacement EEPROM chip for it, (to make it work with PC hardware,
rather than MAC). But, even then, the overall cost came to less than £100.
I also had to buy a Behringer ADA-8000 to convert the ADAT lightpipe
connections to balanced analogue. But it sounds as though you already
have hardware to do this.
I appreciate that there are various reasons not to buy second-hand. It's
risky - I didn't even know that the card I bought was definitely going
to work! Also, there are no warranties, or hardware support.
For this reason, I find myself looking around for another cheap RME
card! Firstly, I could turn that other linux box into an addition to my
studio... Also, it's always nice to have a backup if something breaks.
I find all the software support I could ever need right here on this
list (Thanks Paul!)
Hope this helps
Michael Nelson
6582
days inactive
6999
days old
linux-audio-user@lists.linuxaudio.org
16 comments
10 participants
participants (10)
-
Esben Stien -
Gabriel Brachtel -
james＠dis-dot-dat.net -
Janina Sajka -
Jason White -
Jay Vaughan -
Malte Steiner -
Michael T D Nelson -
Paul Davis -
studio-64