2 Mar
2014
2 Mar
'14
2:16 a.m.
Hi!
A visually impaired Linux user here. I recently came across this great
thread[1] and decided to write this message. My goal is a little
different from the original topic author (generating MIDI via code VS.
recording via a keyboard) so I decided to start a new discussion.
Here's my situation (warning: very long post!):
First of all, I'm just an amateur and a beginner with nearly zero
knowledge about music production. I had very little contact with DAWs,
even in Windows... The closest I've gotten to a "DAW" that I tried to
use was Anvil Studio (many years ago), which wasn't accessible either.
The little that I know about MIDI editors and DAWs is from what I read
looking for such programs in Linux.
I'm using Slackware Linux, with Speakup[2] as my console screen reader
(with Espeak[3] through the Espeakup[4] connector, because I don't
have a hardware voice synth), and Orca[5] as the screen reader for X
(note: I use only ALSA, without Pulseaudio).
I'm trying to create some kind of audio setup for quite some time
(since around 2010). Back then, I read everywhere that it was needed
to recompile the kernel with a realtime patch. Then I found the
courage and did just that, but:
* I never got JACK to really work. It complained that the soundcard
was already being used, probably because of my screen readers which
are softsynths (again, I don't have a hardware synth nor a Braille
display), and I suspect they take all the soundcard for themselves.
JACK only got to start if I used a second soundcard, an M-Audio Fast
Track Pro (which I bought because it seemed to work on Linux), but it
didn't go too well either. Only much later (last year, 2013) I came
across this post
http://joegiampaoli.blogspot.com/2011/06/m-audio-fast-track-pro-for-debian-…
It seems the Fast Track Pro is already supported on newer (3.X)
kernels, but I still didn't test that.
* Most audio related apps were (and still are) made with QT GUIs.
Though QT's accessibility API exists for a long time (and is well
documented[6]), there were no means for Orca to communicate with it
yet, so all those apps were completely inaccessible.
* With the recompiled kernel, my video driver installation broke (I
wasn't even using proprietary drivers or anything). X only showed a
blinking cursor on the screen. Orca worked just fine, but it was a
problem when a sighted person needed to use the computer.
So, I went back to the stock kernel (where the video driver worked)
and gave up, for the most part. I settled on doing everything from my
keyboard (which requires some sighted assistance), then sending the
result as a wav file to my computer, then processing it with SoX[7]
(which I use all the time) and/or Ecasound[8]. But recently I began
thinking of using sounds from softsynths or other programs (for
example, LinuxSampler[9]) instead of my keyboard's internal sounds,
and for that, I think it would be best if I could record MIDI directly
into my computer. So, the search started again, and I began testing
some command line applications (most of which were already mentioned
on the thread in [1]):
* CuSe[10]: stands for "Cursed Sequencer", and like the name suggests,
is Curses based. Interestingly, it was made specifically with visually
impaired users in mind. Some features look interesting, like punch
in/out, a step sequencer, and (the most interesting of all) a "remote
control" like thing, where it's possible to configure key combinations
for controlling the software through the hardware synth's keyboard
(avoiding the need to run back and forth between the synth and the
computer). But it doesn't seem to have some features I want, like
adding/editing lyrics to the notes, MIDI CCs and SysEx events.
Unfortunately, I was never able to get any sound from it (be it
through FluidSynth or my MIDI keyboard).
* Midish[11]: already mentioned on the thread in [1], it supports
recording and playing MIDI, adding events and SysEx messages, and it
has nice filtering features, making it possible to split the keyboard
or transform one event into another. It only supports raw MIDI ports
and it took me a lot of time to figure that to make it work, I needed
to "modprobe snd_virmidi", then (a)connect the virmidi ports to my
synth's ports, then configure the inputs and outputs via the
"~/.midishrc" file. It was the program I got working more
successfully, and I placed my hopes on Midish for a long time, reading
and rereading the manual to see if I could make it do what I wanted. I
was able to record MIDI via my keyboard (though I wish there was a
"remote control" feature or something similar). However, sometimes I
also wanted to insert notes manually, and as already pointed out in
this message from the thread in [1]
http://lists.linuxaudio.org/pipermail/linux-audio-user/2014-February/096120…
that isn't the most intuitive task, and Midish doesn't seem to let me
add lyrics or edit notes (only cut/copy/paste measures)... Well,
unless I save the song to Midish's format and open it in a text
editor, but I don't want to have to memorize which note numbers are
which :P. Or unless I'm missing something else.
* Midiedit[12]: contrary to Midish, this only edits and doesn't
record. It's contained in only one file and is a Perl script. It has
two interfaces: a Curses based one and a "text editor" based one. With
the Curses interface, it can playback MIDI files (I used Aconnect to
hook its ports to FluidSynth and the sounds played), and as the name
suggests, edit. Events (notes, CCs, program changes etc.) can be
inserted, edited and deleted. They're displayed sequentially in a
list, one per line, with their starting position in ticks, duration
and channel. They can be navigated by using the Up and Down arrows,
then edited (the bottom screen shows the available actions and which
keys do what). One thing I love about it is that it plays back the
notes when the cursor focuses on them. Another thing is that it treats
each note as a single event, by matching the note ons with their
respective note offs, which makes managing notes much easier. So far
so good, but everything always has some "cons". I wish it could mute
or solo tracks, and have a separate view for each track. The search
function can be used to jump straight to the notes from a specific
channel, and cycle through the results with "n" and "N" (similar to
Vi/Vim), but the notes from the other tracks are still there and it
gets confusing easily (at least for me). It doesn't seem to have an
action implemented on the interface to handle lyrics and text events,
but these still can be edited through the "text editor" interface,
which is called "dump mode". In this mode, it opens your text editor
of choice (the one in the "$EDITOR" environment variable) and
represents the MIDI file's contents as readable Perl code (based on
the dump output from the MIDI::Perl[13] module). All events (including
text events, lyrics and SysEx) can be edited this way, (although
obviously it doesn't play back the notes, and we don't have the luxury
of the unification of note ons and offs). After saving and closing the
editor, the Perl code is processed and the content is written back to
the MIDI file.
* From the same author of Midiedit, there are other interesting Curses
based MIDI tools[14], like Midifade[15], which generates "sliders"
for controlling MIDI events through the PC keyboard (on the command
line, we specify how many sliders to generate, the ALSA port, the MIDI
channel and which event each slider will control), and can, for
example, change Ecasound's controller parameters, or the "knob"
parameters from a softsynth.
That's it for the CLI apps I tested. Midish and Midiedit are the ones
I had most "luck" with, but my attempts with them weren't that
productive either.
My search for an accessible MIDI editor or DAW continues. Recently, I
updated Slackware to 14.1. I'm using the stock kernel, no realtime
patches or anything yet. First I want to know if I really need it (I
read that because of changes in recent kernels, RT patches aren't
strictly necessary anymore), and if there's some app that I'm able to
use (if not, there's no point to even try compiling a realtime kernel
:P). I finally got the QT-AT-SPI[16] bridge to compile, meaning I can
access QT GUI apps to some degree now. So, I decided to test some of
the most popular Linux DAWs, those QT based audio apps that taunted me
since I first read about audio production on Linux (basically, the
only options that were available and which I couldn't use).
From the list of features I read, the one that appealed
to me the most
was MusE[17]:
* The possibility of mixing MIDI with audio (samples, loops, vocals etc.).
* Instrument definition files for various brands of keyboards that
ease the use of those synthesizers, making it so that we don't need
to memorize patch names/numbers and controller numbers.
* MIDI recording.
* Editing of all types of MIDI events. Besides the visual editor,
there's a "event list editor" (I suppose it's something like in
Midiedit), so maybe it could work for me.
* A few internal instruments (some synths and a FluidSynth frontend).
* DSSI support.
* (apparently) native VST support too (and I assume, a few Windows
VSTs through DSSI-VST).
* And the "remote control" feature :D!
Of course there's the multitude of functions that depend on the mouse
(which I can't use), but it seems to have customizable shortcuts. It's
a graphical application, obviously very far from being text-based, but
I read that it also has some Python bindings, so maybe a few things
can be scripted...?
However, sadly, all isn't as good as it sounds. I installed MusE 2.1.2
and opened the interface. The menus work fine, but the screen reader
has problems reporting the interface elements (for example, it says
"spinbox" or "checkbox" but doesn't specify wish item that
control
corresponds to. The "MusE Settings -> Global Settings" screen is full
of these examples and unreadable through the screen reader). I just
took a quick "look" at the interface to have an idea of what the
screen reader could read. I didn't test recording or anything yet,
mainly because of the aforementioned problem with JACK, nor could sort
out the setup part about "/dev/rtc"...
While we're on the subject of MusE, a question for the "MusErs": if I
don't use JACK (or use the "-a" switch), won't MusE ever play anything
through the PC's speakers (imported audio, internal instruments,
FluidSynth soundfont sounds)? Or will it just be unable to communicate
with JACK aware applications?
I'm thinking if I'll insist on MusE for a bit more, and if I do, maybe
I'll contact the developers about the accessibility issues.
Based on my limited knowledge of MIDI editors and DAWs which I
acquired from what I've tested or read about so far, desired features
for my dream DAW would be:
* Curses based interface.
* Both JACK and some form of ALSA Seq support (even if it's only with
raw MIDI ports, or some workaround involving sending commands through
Amidi :P). JACK would be for more complicated setups. ALSA would be
for when I only want to do some quick MIDI editing and don't want to
use a second soundcard just because of JACK (I need my screen reader,
so I can't turn it off to free the first card).
* Playback of MIDI files.
* Support of a metronome click, and a "count in" feature for recording.
* A "remote control" feature, or a way to start recording (or the
count in) only when I press a key on my hardware instrument.
* Each note shown as only one event, by matching the note on with it's
respective note off. This way we don't need to struggle scrolling
through the events trying to match the ons and offs.
* Possibility of inserting/editing/deleting all types of events,
including text events, lyrics and SysEx messages.
* A way to select a track to be "active".
* A separate list of MIDI events for each track (only showing the
contents of the "active" track), where events can be browsed with
arrow keys and be edited or deleted. Also, the possibility of
inserting new events through the interface (without using the MIDI
keyboard).
* Playback of notes when the cursor focuses on them.
* Ability to mute and solo tracks.
* Support for instrument definition files, to ease the use of hardware
synths (maybe some softsynths too). With that, I'd be able to select
the patches and controllers specific to my hardware synth directly
from the computer and with help of my screen reader, reducing the need
of asking for sighted assistance to know the patch names.
* DSSI support, or the possibility of interacting with some command
line based DSSI host.
* The ability to assign the MIDI channel and an instrument
(ALSA/JACK/whatever ports and patch names) to each track (or is this a
work better suited to a "patchbay" like app?).
* Rendering of MIDI tracks to audio with the used synths' sounds.
* Customizable keyboard shortcuts.
* Some form of scripting support, like Perl or Python or Lua bindings,
and the ability to assign user scripted functions to some keybinding
in the editor.
Some more complex features:
* The ability to have both MIDI and audio in the same project. The
audio doesn't need to be editable (just "importable"), only needs to
have its starting position adjustable to be in sync with the MIDI
tracks (triggered via some MIDI event maybe?).
* Recording of MIDI while playing back the audio tracks, keeping them in sync.
* Maybe a pattern editor, where the lists of events become a phrase,
chains of phrases make patterns and chains of patterns make a song
(but maybe it's too complex and is a discussion for another day :P).
And that was my utopic idea for an accessible Linux DAW. I don't know
how hard it is to implement all of that, specially the "MIDI alongside
audio" part. Unfortunately I understand nothing about audio
programming (honestly, I already tried :P) and very little about music
production, so a lot of features I pointed out might be complete
nonsense, or might be accomplished in a much better way (if anyone
knows a way, preferably via command line, please let me know).
As for the "patchbay" (with "jack_connect" etc.), I think even a
simple Shell Script with Dialog based menus would be fine.
As for post processing and mixing (applying LADSPA/LV2 effects etc.),
it can be left to some other app (Ecasound for example) after all
tracks are rendered to audio.
And last but not least, on the thread in [1], I found Teqqer[18]. I
couldn't test it yet because of the JACK problem (I seriously need to
sort that out), but I took a look at the default config variables in
the Python source code, and it looks like scripting support and
customizable shortcuts are mostly taken care of. From what I
understand from the shortcuts, the interface for inserting/editing
MIDI events is a bit similar to Midiedit (Up/Down to cycle through
events, although note ons and offs are separate) and it seems to have
one view for each track (Left/Right to cycle through tracks), and it
even supports patterns! :D So, minus the recording part (from what I
understood, it wasn't made for that), the lack of ALSA (without JACK)
support, I think it has the potential to become something like what
I'm looking for (plus, I always wanted to try a tracker, but never
found a "screen reader friendly" one). I'll definitely be watching
Teqqer to see where it goes!
While my dream DAW doesn't come true, does anyone know a command line
way to record MIDI while simultaneously playing an audio file and
keeping both in sync (even if it involves JACK)? I think Ecasound can
be setup to do the opposite, playing back a MIDI file while recording
audio (but it doesn't support MIDI recording, just playback... Or does
it? :P).
Well, that's it. Sorry for the overly long post. Thanks for your time!
[1]: http://lists.linuxaudio.org/pipermail/linux-audio-user/2014-January/095910.…
[2]: http://www.linux-speakup.org/
[3]: http://espeak.sourceforge.net/
[4]: https://github.com/williamh/espeakup
[5]: https://wiki.gnome.org/Projects/Orca
[6]: http://qt-project.org/doc/qt-4.8/accessible.html
[7]: http://sox.sourceforge.net/
[8]: http://nosignal.fi/ecasound/
[9]: http://www.linuxsampler.org/
[10]: http://pi4.informatik.uni-mannheim.de/~haensel/cuse/index_en.html
[11]: http://www.midish.org/
[12]: http://www.pjb.com.au/midi/midiedit.html
[13]: http://search.cpan.org/perldoc?MIDI
[14]: http://www.pjb.com.au/midi/index.html
[15]: http://www.pjb.com.au/midi/midifade.html
[16]: http://projects.kde.org/qtatspi
[17]: http://www.muse-sequencer.org/
[18]: https://github.com/fps/teqqer
--
____________________
Blog: http://aiyumi.warpstar.net/
2 Mar
2 Mar
4:51 a.m.
Your post was very long and my response will not directly address what you
wrote. I am quoting something I wrote a couple of years ago about
interfaces for this blind people. It makes a single but I think critical
point.
-------------
years ago someone paid me to do a text-based UI for ardour. it was centered
on very efficient use of the keyboard and using a screen-reader.
the code probably still exists. i don't think it was very successful,
partly for the reasons identified in the text you sent. but i think there
is a more important reason.
working with audio tends to involve the use of the screen to act as a kind
of memory. there are a ton of parameters in play, and its a huge barrier if
you constantly need to remember what they are all set to. the 2d expanse of
the screen represents a kind of 2nd level cache of this information, where
a sighted person can simply glance around and discover what they need to
know about the current state of things.
reproducing this functionality without the information-dense medium that
the screen represents is a HUGE challenge. i've thought about it on and off
every since the "ksi" interface for ardour was done. i have no ideas on how
anyone could make progress on this. i think its a very interesting, very,
very hard problem. i have no time to work on it.
as a practical note, if someone wants to do something like this, it would
obviously be quite likely that basing their efforts on an open source tool
is likely to offer a lot of possibilities that are simply not available
when using closed source tools.
-----------------
5:31 a.m.
On Sat, 2014-03-01 at 22:51 -0500, Paul Davis wrote:
working with audio tends to involve the use of the
screen to act as a
kind of memory. there are a ton of parameters in play, and its a huge
barrier if you constantly need to remember what they are all set to.
True for most of us, who have the ability to verify memory by taking a
look to a screen or notes written on a paper. The mnemonics of blind
audio engineers likely will work a little bit different. I guess the
"weak" point is "editing". When I was young we used analog recording
and
IMO the missing abilities to edit audio productions wasn't a
disadvantage. I prefer music recordings without editing. To push a
record and stop key can be done by blind and seeing engineers. Mixing is
another "issue". I'm not blind, but I anyway prefer an analog mixer over
digital mixing with a mouse. Is there really the need for blind (and
seeing) engineers to have all the options that a GUI is able to provide?
6:38 a.m.
Yet we have a member of the list who is blind and works with audio ...
On 03/01/2014 05:51 PM, Paul Davis wrote:
Your post was very long and my response will not
directly address what
you wrote. I am quoting something I wrote a couple of years ago about
interfaces for this blind people. It makes a single but I think critical
point.
-------------
years ago someone paid me to do a text-based UI for ardour. it was
centered on very efficient use of the keyboard and using a screen-reader.
the code probably still exists. i don't think it was very successful,
partly for the reasons identified in the text you sent. but i think
there is a more important reason.
working with audio tends to involve the use of the screen to act as a
kind of memory. there are a ton of parameters in play, and its a huge
barrier if you constantly need to remember what they are all set to. the
2d expanse of the screen represents a kind of 2nd level cache of this
information, where a sighted person can simply glance around and
discover what they need to know about the current state of things.
reproducing this functionality without the information-dense medium that
the screen represents is a HUGE challenge. i've thought about it on and
off every since the "ksi" interface for ardour was done. i have no ideas
on how anyone could make progress on this. i think its a very
interesting, very, very hard problem. i have no time to work on it.
as a practical note, if someone wants to do something like this, it
would obviously be quite likely that basing their efforts on an open
source tool is likely to offer a lot of possibilities that are simply
not available when using closed source tools.
--
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
9:48 a.m.
A question to the OP, sorry, your mail was to long to read right now,
perhaps I'll read it later.
Do you prefer speech synth or braille?
On Sat, 2014-03-01 at 19:38 -1000, david wrote:
Yet we have a member of the list who is blind and
works with audio ...
IIRC we have more than one member. Julien unfortunately for us,
fortunately for him, is on an adventure. IIRC there are some other
members visually impaired. Apart from Julien I only remember one other
member too, but not his name.
On musician forums there are likely several blind users, because even
Linux GUIs oven provide text based configs, blind user are able to use.
IIRC using Linux audio is more comfortable when the blind users prefer
braille over speech synth.
A blind formal member of this community: http://juliencoder.de/
I had some phone calls with him, he's very smart and has got knowledge
about the things he's talking about.
I never read the interview with Julien, perhaps there is some useful
information too. http://www.zthmusic.com/julien-claassen/
Regards,
Ralf
2:29 p.m.
On Sun, Mar 2, 2014 at 12:38 AM, david <gnome(a)hawaii.rr.com> wrote:
Yet we have a member of the list who is blind and
works with audio ...
I wasn't saying that it was impossible. I was saying that a huge part of
how GUI-driven programs work is based on a feature that is very very very
hard to replicate in non-GUI-driven programs.
3 Mar
3 Mar
11:37 a.m.
Hey hey, (sorry for replying to the thread in general, my mail archive is
broken.)
I'm not blind yet but on the way. I inherited some software tips and tricks from a
friend.
Nama is a DAW with good audio support and limited MIDI support. It's based on Ecasound
and Midish. It can be remote controlled with a USB footswitch, a piece of gaming
equipment. One blind guy on the Nama mailinglist uses it to great effect. Nama can be
synchronised to MIDI with a little script I inherited as well.
Midish connects easily to ALSA sequencer ports. If you're still interested, I can pass
a file of convenience commands that I've been working on. It's not finished yet.
There are also commands for connecting Midish to hardware and software synthesizers via
ALSA sequencer.
JACK can run on any reasonably modern system without a realtime kernel. Use it on your
second soundcard - the Fast Track Pro. There are commandline patchbays as well like esjit
or jackctl.py and others. Despite their names, most can also handle ALSA sequencer MIDI
ports too.
Ta-ta
----
Ffanci
* Internet: http://freeshell.de/~silvain
4 Mar
4 Mar
12:48 a.m.
2014-03-03 7:36 GMT-03:00, F. Silvain <silvain(a)freeshell.de>de>:
Nama is a DAW with good audio support and limited MIDI
support. It's based
on Ecasound and Midish. It can be remote controlled with a USB footswitch, a
piece of gaming equipment. One blind guy on the Nama mailinglist uses it to
great effect. Nama can be synchronised to MIDI with a little script I
inherited as well.
I hadn't tried Nama because Ecasound was already meeting my non-MIDI
needs. Before this discussion, I didn't know that Nama was integrated
with Midish. Now that I know, I'll give it a try.
Midish connects easily to ALSA sequencer ports. If
you're still interested,
I can pass a file of convenience commands that I've been working on.
Oh, please :D.
[...] There are commandline
patchbays as well like esjit or jackctl.py and others. Despite their names,
most can also handle ALSA sequencer MIDI ports too.
I didn't know of these. I'll check them out.
2014-03-03 8:15 GMT-03:00, Florian Paul Schmidt <mista.tapas(a)gmx.net>et>:
Hi,
as the author of the (unfinished) teqqer I have to add that recording
MIDI is definitely on the agenda for the future.
Really? That's great!
[...] I do not plan to support recording of audio
though, as
I don't really know how to represent that in a tracker format. Sure
one could use a "generic" audio event type and associated track type.
But I'm not sure on how well that would work.. Input appreciated..
Actually, what I really wanted was MIDI recording (what I thought of
audio was just for playback along with the MIDI tracks), so that'd be
good enough for me. That makes Teqqer a strong candidate for becoming
my MIDI editor of choice :D. Until then, I'll see what I can do with
Nama and Midish.
Once again, thank you everyone!
--
____________________
Blog: http://aiyumi.warpstar.net/
7 Apr
7 Apr
8:59 p.m.
Paul Davis writes:
Your post was very long and my response will not
directly address what you
wrote. I am quoting something I wrote a couple of years ago about
interfaces for this blind people. It makes a single but I think critical
point.
-------------
years ago someone paid me to do a text-based UI for ardour. it was centered
on very efficient use of the keyboard and using a screen-reader.
the code probably still exists. i don't think it was very successful,
partly for the reasons identified in the text you sent. but i think there
is a more important reason.
working with audio tends to involve the use of the screen to act as a kind
of memory. there are a ton of parameters in play, and its a huge barrier if
you constantly need to remember what they are all set to. the 2d expanse of
the screen represents a kind of 2nd level cache of this information, where
a sighted person can simply glance around and discover what they need to
know about the current state of things.
reproducing this functionality without the information-dense medium that
the screen represents is a HUGE challenge. i've thought about it on and off
every since the "ksi" interface for ardour was done. i have no ideas on how
anyone could make progress on this. i think its a very interesting, very,
very hard problem. i have no time to work on it.
If you are in a position to rely on the screen, you have no reason to
become adept at remembering all those details. The converse also holds.
It's the same learning a score to play from memory, vs knowing that you
will always be able to rely on a printed score on the music stand, i.e.
it's not about the ability to see, but about the operational
sassumptions.
Concert pianists (and other concert soloists) memorize concertos. Chamber players tend to
play from
scores, as do vocal accompanyists.
PS: The problems I had with the keyboard interface to Ardour was that it
didn't work in any packaged version I was able to install. Ideally, any
such command input overlay would persist as the underlying application
is versioned up. But, as I recall, your work was outside of any a11y
supporting framework, so was probably bound encounter problems.
as a practical note, if someone wants to do something
like this, it would
obviously be quite likely that basing their efforts on an open source tool
is likely to offer a lot of possibilities that are simply not available
when using closed source tools.
Well, the blind musicians community appears to be pretty happy with Avid
products just now, specifically ProTools v. 11 and up.
It's regretable that desktop F/OSS has underperformed for AT users,
especially as the successful API-based approach was first developed on
F/OSS. Linux might have enjoyed "first out of the box a11y support" on
the desktop, but never got it quite together, so that bragging point
went to Apple.
Then there's the pulseaudio travesty which was foisted into Linux
without a11y requirements considerations. One could go on and on.
Janina
-----------------
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
--
Janina Sajka, Phone: +1.443.300.2200
sip:janina@asterisk.rednote.net
Email: janina(a)rednote.net
Linux Foundation Fellow
Executive Chair, Accessibility Workgroup: http://a11y.org
The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Protocols & Formats http://www.w3.org/wai/pf
Indie UI http://www.w3.org/WAI/IndieUI/
10:32 p.m.
On Mon, Apr 07, 2014 at 02:57:03PM -0400, Janina Sajka wrote:
If you are in a position to rely on the screen, you
have no reason to
become adept at remembering all those details. The converse also holds.
I've seen blind people cut and splice tape, and very accurately.
It depends probably on the kind of editing you want to do.
If it isn't too complex (such as moving fragments in time
AND between tracks at the same time while keeping those
tracks aligned), it surely can be done without having the
visual representation.
The real problem here is probably that the type of editing
operations that Ardour supports are more visual than logical.
Things like 3-pt and 4-pt editing can be done easily without
having a visual representation - I've done a lot of that.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
11:56 p.m.
On Mon, Apr 7, 2014 at 11:32 PM, Fons Adriaensen <fons(a)linuxaudio.org>wrote;wrote:
On Mon, Apr 07, 2014 at 02:57:03PM -0400, Janina Sajka
wrote:
If you are in a position to rely on the screen,
you have no reason to
become adept at remembering all those details. The converse also holds.
[... ]
It depends probably on the kind of editing you want to do.
If it isn't too complex (such as moving fragments in time
AND between tracks at the same time while keeping those
tracks aligned), it surely can be done without having the
visual representation.
actually i wasn't thinking of editing as much as mixing. you can remember
the solo, mute, gain, and FX state of a moderately sized session in your
head without a visual reminder?
editing is actually easier for many cases precisely for the reasons you
outlined.
8 Apr
8 Apr
12:49 a.m.
On 08/04/14 07:55, Paul Davis wrote:
On Mon, Apr 7, 2014 at 11:32 PM, Fons
Adriaensen<fons(a)linuxaudio.org>wrote;wrote:
it depends on what you are practiced at, in a different but related field ...
plotting lighting cues in a theatre ... it is very common to be the designer and
have someone else operating the desk, then keeping large sets of channel numbers
and existing states in your head makes it a lot quicker and easier to
communicate as you walk around the space. Casual observers find this dialogue
very strange. Interestingly operating audio you often look down at the desk,
operating lights the effect is visual and not looking at the desk is important.
On Mon, Apr 07, 2014 at 02:57:03PM -0400, Janina
Sajka wrote:
If you are in a position to rely on the screen,
you have no reason to
become adept at remembering all those details. The converse also holds.
[... ]
It depends probably on the kind of editing you want to do.
If it isn't too complex (such as moving fragments in time
AND between tracks at the same time while keeping those
tracks aligned), it surely can be done without having the
visual representation.
actually i wasn't thinking of editing as much as mixing. you can remember
the solo, mute, gain, and FX state of a moderately sized session in your
head without a visual reminder?
editing is actually easier for many cases precisely for the reasons you
outlined.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
7:03 a.m.
On Tue, Apr 8, 2014 at 1:49 AM, Simon Wise <simonzwise(a)gmail.com> wrote:
it depends on what you are practiced at, in a different but related field
... plotting lighting cues in a theatre ... it is very common to be the
designer and have someone else operating the desk, then keeping large sets
of channel numbers and existing states in your head makes it a lot quicker
and easier to communicate as you walk around the space. Casual observers
find this dialogue very strange. Interestingly operating audio you often
look down at the desk, operating lights the effect is visual and not
looking at the desk is important.
Understood, but I'm not sure of the relevance of this observation/behaviour
to a situation where the lights themselves function as a "visual
memory/display" of the current state.
11:10 a.m.
On 08/04/14 15:03, Paul Davis wrote:
On Tue, Apr 8, 2014 at 1:49 AM, Simon
Wise<simonzwise(a)gmail.com> wrote:
no more than the sound does, you can hear what's playing just as easily ... it
is not easier to know which light needs tweaking on a stage than which
instrument in a mix, and no more obvious which channel to adjust from the look
than which channel to adjust from the sound.
Simon
it depends on what you are practiced at, in a different but related field
... plotting lighting cues in a theatre ... it is very common to be the
designer and have someone else operating the desk, then keeping large sets
of channel numbers and existing states in your head makes it a lot quicker
and easier to communicate as you walk around the space. Casual observers
find this dialogue very strange. Interestingly operating audio you often
look down at the desk, operating lights the effect is visual and not
looking at the desk is important.
Understood, but I'm not sure of the relevance of this observation/behaviour
to a situation where the lights themselves function as a "visual
memory/display" of the current state.
11:22 a.m.
On Tue, Apr 08, 2014 at 07:10:36PM +1000, Simon Wise wrote:
no more than the sound does, you can hear what's
playing just as
easily ... it is not easier to know which light needs tweaking on a
stage than which instrument in a mix, and no more obvious which
channel to adjust from the look than which channel to adjust from
the sound.
Based on my very limited experience in controlling lights I'd
say it's even more difficult. If what you see is the combined
effect of many lights it's not obvious at all what is the
contribution of each individual one.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
11:57 a.m.
On 08/04/14 19:22, Fons Adriaensen wrote:
On Tue, Apr 08, 2014 at 07:10:36PM +1000, Simon Wise
wrote:
just as with a sound rig ... if you have selected, placed and focussed them
carefully in the first place, if you have in mind how you built the scene, if
you have planned the kinds of presets you have recorded, and if you have done it
many times before, and know what each instrument could do and what light looks
like on a body or in a space ... then you can see what is going on, and know
what needs changing. Otherwise it is very difficult. I started with sound, but
for many years did a lot more lighting than sound.
Simon
no more than the sound does, you can hear
what's playing just as
easily ... it is not easier to know which light needs tweaking on a
stage than which instrument in a mix, and no more obvious which
channel to adjust from the look than which channel to adjust from
the sound.
Based on my very limited experience in controlling lights I'd
say it's even more difficult. If what you see is the combined
effect of many lights it's not obvious at all what is the
contribution of each individual one.
1:58 a.m.
On Tue, Apr 08, 2014 at 12:55:56AM +0300, Paul Davis wrote:
actually i wasn't thinking of editing as much as
mixing. you can remember
the solo, mute, gain, and FX state of a moderately sized session in your
head without a visual reminder?
Sure. As can every audio engineer who has done his share of
live mixing. Of course on a 'real' mixer some settings are
visible, but if you depend on that you'll be in trouble before
you know it - at least if you're dealing with 30+ channels.
Much of that depends on ergonomic design of the mixer, which
is what sets the real top class apart from the rest. In my
experience Neve was the best at that - you could reach for
any control and have the right one every time, even when the
the only lights were the level meters and a candle or two,
as was often the case.
I *do* remember the first time I had to do anything on this
scale 'on air' - it was quite scary. Studio 1 in Brussels,
big band, 20 or so players + solos, Harrison console, live
broadcast and 24-track recording. All levels carefully set
before turned out wrong because the band had been drinking
between the rehearsal and the concert, and they were 'in
the mood'. But after a few times you get your grips on the
situation and you can relax.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
7:19 a.m.
On Tue, Apr 8, 2014 at 2:58 AM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Tue, Apr 08, 2014 at 12:55:56AM +0300, Paul Davis
wrote:
This doesn't fit with what I've seen in live mixing situations. I
understand the importance of the ergonomics, but I would suggest that if
you were using the best designed mixer and it was altered in one small way,
my question above would remain rhetorically on target.
The modification would be to (a) remove all value indicators from the mixer
(b) replace all the knobs with "endless v-pots".
Even in live sound, engineers are making constant visual inspection of the
mixer controls and state displays. I don't doubt that it is *possible* to
get so good at the job that you really could memorize the entire state of
the console, and I certainly do not doubt the importance of ergonomic
design, but I strongly suspect that most people continue to rely on the
state of the mixer as represented by the visual state to avoid having to
actually perform this full memorization.
In addition, live sound and the editing+mixing workflow are two different
things, related by a common set of concepts and tools. This is easily
demonstrated by the existence of consoles built specifically for live
sound. Certainly one could make a studio console work, but the workflow is
sufficiently differentiated that people have pressed for changes to make
things easier.
I think this discussion has reminded me also of why I think this applies to
editing as well. Although it is true that things like 4- and 3-point edit
ops can be performed without visual feedback, my original point was that
the visual aspects of a DAW or NLE act as a kind of memory for the user,
not as a means of enabling operations. What matters about the DAW display
is not that it allows you to perform an edit, but that it shows you very
easily "what is where".
To be honest, I think that if I were a blind user and needed to edit, I
would probably be looking at tools that used the same kind of workflow as
RTCmix or something similar. A fully text-based representation of the
operations/mix that can be easily manipulated without any visual
presentation. RTCmix has the downside that (if I recall correctly) it can
only play back the entire mix, but I would have thought that this sort of
thing would be a better starting point for a "music editor for blind users"
than Ardour.
Finally, to the Janina, I would note that Ardour KSI was created early in
Ardour's life when we barely had an edittor at all. The interface allowed
control of the mixer and not of editing operations. And as for why it did
not participate in any a11y standards: the blind user who paid me to
develop it did not like them and wanted something radically different.
--p
actually i wasn't thinking of editing as much
as mixing. you can remember
the solo, mute, gain, and FX state of a moderately sized session in your
head without a visual reminder?
Sure. As can every audio engineer who has done his share of
live mixing. Of course on a 'real' mixer some settings are
visible, but if you depend on that you'll be in trouble before
you know it - at least if you're dealing with 30+ channels.
Much of that depends on ergonomic design of the mixer, which
is what sets the real top class apart from the rest. In my
experience Neve was the best at that - you could reach for
any control and have the right one every time, even when the
the only lights were the level meters and a candle or two,
as was often the case.
I *do* remember the first time I had to do anything on this
scale 'on air' - it was quite scary. Studio 1 in Brussels,
big band, 20 or so players + solos, Harrison console, live
broadcast and 24-track recording. All levels carefully set
before turned out wrong because the band had been drinking
between the rehearsal and the concert, and they were 'in
the mood'. But after a few times you get your grips on the
situation and you can relax.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
10:50 a.m.
On Tue, Apr 08, 2014 at 12:55:56AM +0300, Paul Davis wrote:
This doesn't fit with what I've seen in live
mixing situations. I
understand the importance of the ergonomics, but I would suggest that if
you were using the best designed mixer and it was altered in one small way,
my question above would remain rhetorically on target.
modification would be to (a) remove all value indicators from the mixer
(b) replace all the knobs with "endless v-pots".
It would no longer be 'the best designed mixer'.
You need to see values when setting things up. With a bit
of experience you know e.g. what sort of EQ will be needed
for a particular channel, and being able to prepare such
things or set them very quickly without too much trial and
error makes all the difference. If you need half the sound-
check or rehearsal time to do that there's a problem.
Once the show is running you typically only make small
changes. What is important then is being able to find all
controls quicly without having to search for them, and
preferably without having to take your eyes from the stage
for longer than a split second. Which is where the ergonomics
come in. Of course it's reassuring to be able to see all
settings. But you don't need to see all of them all the
time, what matters is how and how quickly you get acces
to them.
In addition, live sound and the editing+mixing
workflow are two different
things, related by a common set of concepts and tools. This is easily
demonstrated by the existence of consoles built specifically for live
sound. Certainly one could make a studio console work, but the workflow is
sufficiently differentiated that people have pressed for changes to make
things easier.
That is very clear today, when a DAW is used not just to record
and mix (by a sound engineer) but to actually 'compose' a piece
(by a musician), and the whole workflow is essentially based on
random acess on the time axis.
In the 'tape' days there was much less difference between 'live'
and 'studio' work. The mixers we used (Neve, Harrison, SSL) where
all 'studio' ones, and they were perfectly suited to this kind
of work. Consoles like Digico are different because they are
build for PA which has its own requirements. But I wouldn't want
to use those to mix a live broadcast.
...
To be honest, I think that if I were a blind user and needed to edit, I
would probably be looking at tools that used the same kind of workflow as
RTCmix or something similar. A fully text-based representation of the
operations/mix that can be easily manipulated without any visual
presentation. RTCmix has the downside that (if I recall correctly) it can
only play back the entire mix, but I would have thought that this sort of
thing would be a better starting point for a "music editor for blind users"
than Ardour.
It will all depend on the type of editing that is required.
Blind users could easily edit tape, and also use the early
generation of hard disk recorders before these developed
into full-featured DAWs. These couldn't do the sort of thing
a DAW can do today, but for some types of work they were
actually better.
Ciaom,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
2 Mar
2 Mar
6:40 a.m.
On Sat, 1 Mar 2014, Aiyumi Moriya wrote:
A visually impaired Linux user here. I recently came
across this great
thread[1] and decided to write this message. My goal is a little
different from the original topic author (generating MIDI via code VS.
recording via a keyboard) so I decided to start a new discussion.
Here's my situation (warning: very long post!):
OK
I'm using Slackware Linux, with Speakup[2] as my console screen reader
(with Espeak[3] through the Espeakup[4] connector, because I don't
have a hardware voice synth), and Orca[5] as the screen reader for X
(note: I use only ALSA, without Pulseaudio).
As you require the audio reading tools, you need to do one of two
things... use two audio devices one for the screen reader and one for
audio i/o and jack. Or use pulse and jackd(bus) bridged together. Lots of
people don't like pulse for political/personal/performance reasons. It
seems pulse just ignores dropouts in audio, but that probably doesn't
matter in your case as you would only use it so your screen could talk to
you. Pulse uses about twice the cpu that jack does at any latency setting
(so far as I can tell on my machine).
Sorry, there is a third option. You can create an alsa device that is
really just connected to a jack port. This uses less cpu than pulse. You
have to have all this set up before the screen reader starts. You will
want to tell the system this is the default audio card. I haven't used
this method because I just use pulse the few times I need the
functionality and turn it off otherwise. But you may be able to set the
extra alsa device before hand. Others on the list use this method all the
time and can tell you better than I.
I'm trying to create some kind of audio setup for
quite some time
(since around 2010). Back then, I read everywhere that it was needed
to recompile the kernel with a realtime patch. Then I found the
courage and did just that, but:
Not so sure about slackware's stock kernels, but the patch is not really
needed so long as the preempt switch is on. In ubuntu it is the
-lowlatency kernel and uses all the same video drivers as stock. Slackware
may have something similar, but even if not, rolling your own kernel on
the same source tree with no patch but the option changed should work with
the stock video too. You may also be able to use a command line switch at
system start to turn this on at boot time. It would be possible to have
two grub menu options one to start with it enabled and another without...
quite honestly I run with it turned on all the time just fine so I would
just default it that way. It is important no matter what kernel you use to
have no USB ports sharing interupts with your sound card.
* Each note shown as only one event, by matching the
note on with it's
respective note off. This way we don't need to struggle scrolling
through the events trying to match the ons and offs.
All the gui based midi editors do this, so it is not an unreasonable
request. Notes have a start time and length rather than a start time and
an end time.
* Possibility of inserting/editing/deleting all types
of events,
including text events, lyrics and SysEx messages.
Just work to add it. But remember most authors do this stuff as a hobby
too.
Same with most of the things you want.
Some more complex features:
* The ability to have both MIDI and audio in the same project. The
audio doesn't need to be editable (just "importable"), only needs to
have its starting position adjustable to be in sync with the MIDI
tracks (triggered via some MIDI event maybe?).
* Recording of MIDI while playing back the audio tracks, keeping them in sync.
Nama works well with midish and plays them synced. I don't think it
triggers from midi events, but uses the same transport. triggering audio
to midi events is really extended sample playback, so one of the sample
players may do this already. nana's web page is a bit old and the author
has done more work than the web page would sugest. The web page is 2009,
but the latest update is 2013.
production, so a lot of features I pointed out might
be complete
nonsense, or might be accomplished in a much better way (if anyone
knows a way, preferably via command line, please let me know).
There are some other blind people on here who do wonderful production from
commandline. It can be done. I think Julien ( http://juliencoder.de/nama/
) does mostly keyboard to audio using nama, but some of his stuff
uses midi recording too (I think).
--
Len Ovens
www.ovenwerks.net
4:47 p.m.
2014-03-02 5:48 GMT-03:00, Ralf Mardorf <ralf.mardorf(a)rocketmail.com>om>:
A question to the OP, sorry, your mail was to long to
read right now,
perhaps I'll read it later.
Do you prefer speech synth or braille?
I can only use speech synth via software. I don't have a Braille
display nor a hardware voice synth.
2014-03-02 2:36 GMT-03:00, Len Ovens <len(a)ovenwerks.net>et>:
As you require the audio reading tools, you need to do
one of two
things... use two audio devices one for the screen reader and one for
audio i/o and jack. Or use pulse and jackd(bus) bridged together. Lots of
people don't like pulse for political/personal/performance reasons.
I read complaints of it affecting screen reader performance too, among
other problems (in fact, most things I found about it were
complaints), so I prefer not to use it.
Sorry, there is a third option. You can create an alsa
device that is
really just connected to a jack port. This uses less cpu than pulse. You
have to have all this set up before the screen reader starts.
Meaning that I won't have any audio feedback until I get that setup
right. Maybe the easiest option is really to use a second device...
Not so sure about slackware's stock kernels, but
the patch is not really
needed so long as the preempt switch is on. In ubuntu it is the
-lowlatency kernel and uses all the same video drivers as stock. Slackware
may have something similar, but even if not, rolling your own kernel on
the same source tree with no patch but the option changed should work with
the stock video too.
Here, it's kernel 3.10.17. The threadirqs and 1000Hz options are on,
but the preempt option (out of all things) is not :(.
Aiyumi Moriya wrote:
Of course.
If I had the knowledge/skills, I would do it.
2014-03-02 3:51 GMT-03:00, Joel Roth <joelz(a)pobox.com>om>:
* Each note shown as only one event, by matching
the note on with it's
respective note off. This way we don't need to struggle scrolling
through the events trying to match the ons and offs.
All the gui based midi editors do this, so it is not an unreasonable
request. Notes have a start time and length rather than a start time and
an end time.
* Possibility of inserting/editing/deleting all
types of events,
including text events, lyrics and SysEx messages.
Just work to add it. But remember most authors do this stuff as a hobby
too. Aiyumi Moriya wrote:
Oh, that's great to know. I probably wouldn't have guessed.
Everyone, thank you all for the tips :).
--
____________________
Blog: http://aiyumi.warpstar.net/
While my dream DAW doesn't come true, does
anyone know a command line
way to record MIDI while simultaneously playing an audio file and
keeping both in sync (even if it involves JACK)?
Nama[2] is a command-line application that uses Ecasound for
recording and editing audio. Although it is currently
oriented toward audio, Nama can send commands to a midish
process, and has been used with midish and a2jmidi[3] for
combined audio/MIDI recording under JACK.
A simple hack for starting audio and MIDI in sync was to put
midish and ecasound commands in the same line:
nama> midish-command r; start # For midish, "r" means "record"
I expect we'll eventually add in a MidiTrack class that
would handle MIDI recording and playback. For now, you
would have to issue all the midish commands yourself.
5:27 p.m.
On Sun, 2014-03-02 at 12:47 -0300, Aiyumi Moriya wrote:
Maybe the easiest option is really to use a second
device...
I suspect it's the only serious option ;), a blind user hopefully will
chime in and correct us/me.
For Orca or whatever you are using, you don't need a good audio device.
Stay away from pulseaudio :D (just my opinion ;).
7:51 a.m.
Aiyumi Moriya wrote:
Hi!
Hi Aiyumi,
A visually impaired Linux user here. I recently came
across this great
thread[1] and decided to write this message. My goal is a little
different from the original topic author (generating MIDI via code VS.
recording via a keyboard) so I decided to start a new discussion.
Here's my situation (warning: very long post!):
I'm trying to create some kind of audio setup for
quite some time
(since around 2010)... but:
* I never got JACK to really work.
JACK is pretty useful. You may be able to configure
/etc/asoundrc or $HOME/.asoundrc so that ALSA I/O is routed
to JACK[1].
While my dream DAW doesn't come true, does anyone
know a command line
way to record MIDI while simultaneously playing an audio file and
keeping both in sync (even if it involves JACK)?
Nama[2] is a command-line application that uses Ecasound for
recording and editing audio. Although it is currently
oriented toward audio, Nama can send commands to a midish
process, and has been used with midish and a2jmidi[3] for
combined audio/MIDI recording under JACK.
A simple hack for starting audio and MIDI in sync was to put
midish and ecasound commands in the same line:
nama> midish-command r; start # For midish, "r" means "record"
I expect we'll eventually add in a MidiTrack class that
would handle MIDI recording and playback. For now, you
would have to issue all the midish commands yourself.
Joel
Well, that's it. Sorry for the overly long post.
Thanks for your time!
1. http://jackaudio.org/routing_alsa
2. https://freeshell.de/~bolangi/cgi1/nama.cgi/00home.html
http://github.com/bolangi/nama
3. http://home.gna.org/a2jmidid/README
The need for this appears to be partially if not fully
obsoleted by the latest jack1: http://comments.gmane.org/gmane.comp.audio.jackit/27914
--
Joel Roth
3 Mar
3 Mar
12:15 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02.03.2014 02:16, Aiyumi Moriya wrote:
Hi!
And last but not least, on the thread in [1], I found Teqqer[18].
I couldn't test it yet because of the JACK problem (I seriously
need to sort that out), but I took a look at the default config
variables in the Python source code, and it looks like scripting
support and customizable shortcuts are mostly taken care of. From
what I understand from the shortcuts, the interface for
inserting/editing MIDI events is a bit similar to Midiedit (Up/Down
to cycle through events, although note ons and offs are separate)
and it seems to have one view for each track (Left/Right to cycle
through tracks), and it even supports patterns! :D So, minus the
recording part (from what I understood, it wasn't made for that),
the lack of ALSA (without JACK) support, I think it has the
potential to become something like what I'm looking for (plus, I
always wanted to try a tracker, but never found a "screen reader
friendly" one). I'll definitely be watching Teqqer to see where it
goes!
Hi,
as the author of the (unfinished) teqqer I have to add that recording
MIDI is definitely on the agenda for the future. I have to find some
time to work on it again and fix the long issues list before I can
make a proper release. And I also still ponder how to integrate a
modular synth like Carla into it so it becomes an integrated music
making package. I do not plan to support recording of audio though, as
I don't really know how to represent that in a tracker format. Sure
one could use a "generic" audio event type and associated track type.
But I'm not sure on how well that would work.. Input appreciated..
Have fun,
Flo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTFGROAAoJEA5f4Coltk8ZdtgH/0xerQPjxAm+rQD1wQ+FYAOS
FoP5ViFeiVDqmEZq+wWn02Q8pDV8/iZLxNuImvtz9YuCSWKaSthkig+pfDgQ5G/0
L/tNQ7ZocS0skVURRwWBuBoj/9mHvHcdWcBMK0XX1aMYmOO9R+JlNu8Sd/Q+8toD
MaCS3u4lk5L968n7LVPI0GeN7l+/OlF0JatpHzF7VuqEtUysxeKNeD0MtBfgcOWA
/FinZkSaje43yG1tlm8ZLTAxgRbj5VzlJtLal/cfl2dDHByjYq1napEmx74qVeOB
oSoP6ShWB7iKOxCxoCLHNwvvP69LKAVzqHUfkLm5z7JkshQcYtj2VrHxSRU8lwc=
=MM0L
-----END PGP SIGNATURE-----
3910
days inactive
3947
days old
linux-audio-user@lists.linuxaudio.org
23 comments
11 participants
participants (11)
-
Aiyumi Moriya -
david -
F. Silvain -
Florian Paul Schmidt -
Fons Adriaensen -
Janina Sajka -
Joel Roth -
Len Ovens -
Paul Davis -
Ralf Mardorf -
Simon Wise