23 Feb
2013
23 Feb
'13
5:06 p.m.
Usually when I want to send sysex dumps to midi hardware, I just use the
amidi command from the shell, but when QJackCtl is already running
(along with lots of other Jack apps), the raw device is already in use
by Jack and I can't connect to it at the raw Alsa level anymore.
Since it's kind of a pain to have to shut down my whole Jack session
just to send a sysex dump, is there an easy way I could just sysex
through Jack? Are there any shell commands I should know about that let
you do this through Jack Midi rather than Alsa Midi?
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ James Franck Institute + Shakespeare. Now, thanks to the Internet,
+ Materials Research Ctr + we know this is not true." -Robert Wilensky
23 Feb
23 Feb
5:16 p.m.
On Sat, 23 Feb 2013 10:06:16 -0600 (CST)
Brent Busby <brent(a)keycorner.org> wrote:
Usually when I want to send sysex dumps to midi
hardware, I just use the
amidi command from the shell, but when QJackCtl is already running
(along with lots of other Jack apps), the raw device is already in use
by Jack and I can't connect to it at the raw Alsa level anymore.
Since it's kind of a pain to have to shut down my whole Jack session
just to send a sysex dump, is there an easy way I could just sysex
through Jack? Are there any shell commands I should know about that let
you do this through Jack Midi rather than Alsa Midi?
I don't know if there's such a tool. But AFAIK jack would only block
the raw MIDI device when you use "-X raw" to use the raw MIDI driver in
jack. Do you need that driver? If you don't, you can use the "seq"
driver instead. I find that one more useful anyway. You can change that
in Setup -> Settings in qjackctl. (Also, checking "Enable client/port
aliases" in Setup -> Display shows you readable MIDI device names in
the qjackctl MIDI tab, instead of the useless JACK default names.)
5:27 p.m.
On Sat, 23 Feb 2013, Johannes Kroll wrote:
I don't know if there's such a tool. But AFAIK
jack would only block
the raw MIDI device when you use "-X raw" to use the raw MIDI driver
in jack. Do you need that driver? If you don't, you can use the "seq"
driver instead. I find that one more useful anyway. You can change
that in Setup -> Settings in qjackctl. (Also, checking "Enable
client/port aliases" in Setup -> Display shows you readable MIDI
device names in the qjackctl MIDI tab, instead of the useless JACK
default names.)
It's odd, but I'm already setup with the 'seq' driver...
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ James Franck Institute + Shakespeare. Now, thanks to the Internet,
+ Materials Research Ctr + we know this is not true." -Robert Wilensky
5:30 p.m.
Nevermind, it isn't jackd but rather Hydrogen that's locking the device.
Hydrogen seems to be trying to do some Alsa Midi...so I just have to
stop that.
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ James Franck Institute + Shakespeare. Now, thanks to the Internet,
+ Materials Research Ctr + we know this is not true." -Robert Wilensky
24 Feb
24 Feb
3:45 a.m.
On Sun, Feb 24, 2013 at 1:30 AM, Brent Busby <brent(a)keycorner.org> wrote:
Nevermind, it isn't jackd but rather Hydrogen
that's locking the device.
Hydrogen seems to be trying to do some Alsa Midi...so I just have to stop
that.
I guess you solved the problem, but there is Simple Sysexxer which can do
what you wanted I believe:
http://www.christeck.de/wp/products/simple-sysexxer/
23 Feb
23 Feb
7:08 p.m.
On Sat, February 23, 2013 8:16 am, Johannes Kroll wrote:
jack. Do you need that driver? If you don't, you
can use the "seq"
driver instead. I find that one more useful anyway. You can change that
in Setup -> Settings in qjackctl. (Also, checking "Enable client/port
aliases" in Setup -> Display shows you readable MIDI device names in
the qjackctl MIDI tab, instead of the useless JACK default names.)
Well, checking "Enable client/port aliases" didn't give me any nicer midi
names, but I was able to change the aliases. However these aliases seem to
be a qjackctl thing only. ardour, patchage, etc. still show them as the
original jack names.
On the upside, I was able to rename inputs 5 to 8 so they are obviously
not usable and rename my spdif ports as such. I have a delta66 and like
any ice1712 based IF it shows 12/10 i/o if they are usable or not. What
would be really nice would be to be able to tell jack not to show certain
ports at all and to add aliases at the jack level. This is not just a
ports number as the 6 ports are not contiguous.
Perhaps this is really an alsa driver issue. I am not sure about the
output ports... I have never done it, but the unused output channels can
still be used as inputs to the multi-mixer. I wouldn't think this would be
useful though as mixing input audio and output audio together might show
latency differences between channels. Changing the alsa driver to show
less than 12/10 might break mudita24 as well.
Really, the ice1712 pci cards seem to be one of the best audio solutions
around for stability. I would like to see an expanded version that works
for pcie (more ports, maybe the ability to gang them at the same port). It
seems that audio interface manufactures wait for the chip to come out
before making the IF.
--
Len Ovens
www.OvenWerks.net
7:35 p.m.
On Sat, 23 Feb 2013 10:08:50 -0800
"Len Ovens" <len(a)ovenwerks.net> wrote:
On Sat, February 23, 2013 8:16 am, Johannes Kroll wrote:
I have both "Enable client/port aliases" and "Enable client/port
aliases" checked and "Jack client/port aliases" set to First and that
does the automatic renaming for me.
See Paul Davis' comment on latency though.
jack. Do you need that driver? If you don't,
you can use the "seq"
driver instead. I find that one more useful anyway. You can change that
in Setup -> Settings in qjackctl. (Also, checking "Enable client/port
aliases" in Setup -> Display shows you readable MIDI device names in
the qjackctl MIDI tab, instead of the useless JACK default names.)
Well, checking "Enable client/port aliases" didn't give me any nicer midi
names, but I was able to change the aliases. However these aliases seem to
be a qjackctl thing only. ardour, patchage, etc. still show them as the
original jack names. 
7:09 p.m.
On Sat, Feb 23, 2013 at 11:16 AM, Johannes Kroll <jkroll(a)lavabit.com> wrote:
I don't know if there's such a tool. But AFAIK jack would only block
the raw MIDI device when you use "-X raw" to use the raw MIDI driver in
jack. Do you need that driver? If you don't, you can use the "seq"
to reiterate: if timing matters to you, do NOT use -X raw or -X seq.
use a2jmidid -e instead.
7:16 p.m.
On Sat, February 23, 2013 10:09 am, Paul Davis wrote:
use a2jmidid -e instead.
And a2j gives meaningful names by default that all apps can see.
--
Len Ovens
www.OvenWerks.net
7:43 p.m.
(sorry... should have gone to the list)
On Sat, 23 Feb 2013 13:09:28 -0500
Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Sat, Feb 23, 2013 at 11:16 AM, Johannes Kroll
<jkroll(a)lavabit.com> wrote:
Why is that btw? Is there any hard technical reason the drivers can't
give you the same latency as an external app?
I don't know if there's such a tool. But AFAIK jack would only block
the raw MIDI device when you use "-X raw" to use the raw MIDI driver in
jack. Do you need that driver? If you don't, you can use the "seq"
to reiterate: if timing matters to you, do NOT use -X raw or -X seq.
use a2jmidid -e instead.
8:47 p.m.
On Sat, Feb 23, 2013 at 1:43 PM, Johannes Kroll <jkroll(a)lavabit.com> wrote:
(sorry... should have gone to the list)
On Sat, 23 Feb 2013 13:09:28 -0500
Paul Davis <paul(a)linuxaudiosystems.com> wrote:
Why is that btw? Is there any hard technical reason the drivers can't
give you the same latency as an external app?
nothing to do with latency. everything to do with jitter. neither -X raw
nor -X seq are correctly implemented.
On Sat, Feb 23, 2013 at 11:16 AM, Johannes Kroll
<jkroll(a)lavabit.com>
wrote:
I don't know if there's such a tool. But AFAIK jack would only block
the raw MIDI device when you use "-X raw" to use the raw MIDI driver in
jack. Do you need that driver? If you don't, you can use the "seq"
to reiterate: if timing matters to you, do NOT use -X raw or -X seq.
use a2jmidid -e instead. 
8:59 p.m.
On February 23, 2013 01:09:28 PM Paul Davis wrote:
to reiterate: if timing matters to you, do NOT use -X
raw or -X seq.
use a2jmidid -e instead.
Paul, I read that some of the timing problems with
using seq had been (or was in the process of being) fixed
such that it was going to be more reliable now.
Is that true?
I couldn't notice much of a difference between seq and a2jmidid,
recently.
This issue came up for MusE recently because we
decided, based on that info I read, to start MusE
without listing ALSA devices, only Jack midi devices,
if Jack is running.
Thanks.
Tim.
9:11 p.m.
On Sat, Feb 23, 2013 at 2:59 PM, Tim E. Real <termtech(a)rogers.com> wrote:
On February 23, 2013 01:09:28 PM Paul Davis wrote:
devin anderson reimplemented the drivers for jack2 *only*.
i am not clear on whether -X seq gets his new implementation or not.
i do know that the coreaudio version of his new drivers *appears* to have
some bugs too, but have not had time to investigate further.
--p
to reiterate: if timing matters to you, do NOT
use -X raw or -X seq.
use a2jmidid -e instead.
Paul, I read that some of the timing problems with
using seq had been (or was in the process of being) fixed
such that it was going to be more reliable now.
Is that true?
24 Feb
24 Feb
3:26 a.m.
On Sat, Feb 23, 2013 at 12:11 PM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
devin anderson reimplemented the drivers for jack2
*only*.
i am not clear on whether -X seq gets his new implementation or not.
The '-X seq' argument does not load the 'alsarawmidi' driver. IIRC,
to load the 'alsarawmidi' driver, you add '-X alsarawmidi' to the
command line *before* the audio driver arguments.
i do know that the coreaudio version of his new
drivers *appears* to have
some bugs too, but have not had time to investigate further.
*Too*? I'm sure the software I write has a bug here and there, but
what exactly are you referring to?
Disclaimer: Regarding the CoreMidi driver, I've never tested it. I've
never even compiled it. I wrote the code, and others debugged and
tested it. I'm surprised that the code has changed as little as it
has. All I can do when bug reports come in is look at the code and
hope I see something obvious.
--
Devin Anderson
surfacepatterns (at) gmail (dot) com
blog - http://surfacepatterns.blogspot.com/
midisnoop - http://midisnoop.googlecode.com/
psinsights - http://psinsights.googlecode.com/
synthclone - http://synthclone.googlecode.com/
3:38 a.m.
On Sat, 2013-02-23 at 18:26 -0800, Devin Anderson wrote:
The '-X seq' argument does not load the
'alsarawmidi' driver. IIRC,
to load the 'alsarawmidi' driver, you add '-X alsarawmidi' to the
command line *before* the audio driver arguments.
That's correct, I often use it, but it's not a bridge, to replace
a2jmidi. I use it in combination with a2jmidi, to reduce hw MIDI jitter.
--
http://sacom.hk/mission
3:45 a.m.
On Sat, Feb 23, 2013 at 9:26 PM, Devin Anderson
<surfacepatterns(a)gmail.com>wrote;wrote:
On Sat, Feb 23, 2013 at 12:11 PM, Paul Davis
<paul(a)linuxaudiosystems.com>
wrote:
right. this is jack2 only though, am i right?
devin anderson reimplemented the drivers for
jack2 *only*.
i am not clear on whether -X seq gets his new implementation or not.
The '-X seq' argument does not load the 'alsarawmidi' driver. IIRC,
to load the 'alsarawmidi' driver, you add '-X alsarawmidi' to the
command line *before* the audio driver arguments.
i do know that the coreaudio version of his new
drivers *appears* to have
some bugs too, but have not had time to investigate further.
*Too*? I'm sure the software I write has a bug here and there, but
what exactly are you referring to?
devin, sorry, i should not have bought this up here. i don't have a solid
bug report yet. just some a3 testers on OS X reporting that they appear to
get double delivery of all/most incoming events from coremidi. i haven't
had time to investigate it enough to consider it clearly a bug.
3:52 a.m.
On Sat, Feb 23, 2013 at 6:45 PM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
It's okay. I can help with that:
https://github.com/jackaudio/jack2/commit/e6ab5e1803c5489acf9c2e0cbcce02903…
:)
--
Devin Anderson
surfacepatterns (at) gmail (dot) com
blog - http://surfacepatterns.blogspot.com/
midisnoop - http://midisnoop.googlecode.com/
psinsights - http://psinsights.googlecode.com/
synthclone - http://synthclone.googlecode.com/
On Sat, Feb 23, 2013 at 9:26 PM, Devin Anderson <surfacepatterns(a)gmail.com>
wrote:
Yes, you're right.
At one point, I had some plans to port it to JACK 1, but maintaining
code that interfaces with two different driver APIs in two languages
(C, C++) just didn't sound like fun. In retrospect, maybe I should
have considered writing a separate JACK client instead of a JACK
driver.
On Sat, Feb 23, 2013 at 12:11 PM, Paul Davis <paul(a)linuxaudiosystems.com>
wrote:
right. this is jack2 only though, am i right? devin anderson reimplemented the drivers for
jack2 *only*.
i am not clear on whether -X seq gets his new implementation or not.
The '-X seq' argument does not load the 'alsarawmidi' driver. IIRC,
to load the 'alsarawmidi' driver, you add '-X alsarawmidi' to the
command line *before* the audio driver arguments. i do know that
the coreaudio version of his new drivers *appears* to have
some bugs too, but have not had time to investigate further.
*Too*? I'm sure the software I write has a
bug here and there, but
what exactly are you referring to?
devin, sorry, i should not have bought this up here. i don't have a solid
bug report yet. just some a3 testers on OS X reporting that they appear to
get double delivery of all/most incoming events from coremidi. i haven't had
time to investigate it enough to consider it clearly a bug. 
23 Feb
23 Feb
9:19 p.m.
On Sat, Feb 23, 2013 at 01:09:28PM -0500, Paul Davis wrote:
On Sat, Feb 23, 2013 at 11:16 AM, Johannes Kroll
<jkroll(a)lavabit.com> wrote:
Are there any technical reasons why whatever method a2jmidi
is using is not adopted for the backend ? Maybe it's just a
matter of manpower, but OTOH this situation with the backend
failing to do 'the right thing' has existed for quite some
time now.
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)
I don't know if there's such a tool. But AFAIK jack would only block
the raw MIDI device when you use "-X raw" to use the raw MIDI driver in
jack. Do you need that driver? If you don't, you can use the "seq"
to reiterate: if timing matters to you, do NOT use -X raw or -X seq.
use a2jmidid -e instead.
9:48 p.m.
On Sat, 2013-02-23 at 20:19 +0000, Fons Adriaensen wrote:
On Sat, Feb 23, 2013 at 01:09:28PM -0500, Paul Davis
wrote:
So I can repeat myself ;).
a2jmidi + alsarawmidi for jack2 are a nice combination to get rid of hw
MIDI jitter.
Regards,
Ralf
OT PS: I didn't use audio with my new Arch install and while I wrote
this mail I noticed ...
[root@archlinux rocketmouse]# jackd --help
[snip]
Could not open component .so '/usr/lib/jack/jack_firewire.so':
libffado.so.2: cannot open shared object file: No such file or directory
Could not open component .so '/usr/lib/jack/jack_firewire.so':
libffado.so.2: cannot open shared object file: No such file or directory
jack_get_descriptor : dll jack_firewire.so is not a driver
Segmentation fault (core dumped)
[root@archlinux rocketmouse]# pacman -Qi jack2
Name : jack2
Version : 1.9.9.5-1
URL : http://jackaudio.org/
Licenses : GPL
Groups : None
Provides : jack jackmp jackdmp jackdbus
Depends On : libsamplerate celt
Optional Deps : libffado: FireWire support
dbus-core: jackdbus
python2: jack_control
Required By : None
Conflicts With : jack
Replaces : None
Installed Size : 3132.00 KiB
Packager : Rashif Rahman (Ray) <schiv(a)archlinux.org>
Architecture : x86_64
Build Date : Mon 10 Dec 2012 10:10:29 PM CET
Install Date : Tue 19 Feb 2013 06:17:18 AM CET
Install Reason : Explicitly installed
Install Script : No
Description : The next-generation JACK with SMP support
One issue fixed and the next appeared soon :D.
On Sat, Feb 23, 2013 at 11:16 AM, Johannes Kroll
<jkroll(a)lavabit.com> wrote:
Are there any technical reasons why whatever method a2jmidi
is using is not adopted for the backend ? Maybe it's just a
matter of manpower, but OTOH this situation with the backend
failing to do 'the right thing' has existed for quite some
time now.
I don't know if there's such a tool. But AFAIK jack would only block
the raw MIDI device when you use "-X raw" to use the raw MIDI driver in
jack. Do you need that driver? If you don't, you can use the "seq"
to reiterate: if timing matters to you, do NOT use -X raw or -X seq.
use a2jmidid -e instead.
9:51 p.m.
New subject: jackd2 Was: OT: sending sysex while jackd runs
On Sat, 2013-02-23 at 21:48 +0100, Ralf Mardorf wrote:
[root@archlinux rocketmouse]# jackd --help
[snip]
Could not open component .so '/usr/lib/jack/jack_firewire.so':
libffado.so.2: cannot open shared object file: No such file or directory
Could not open component .so '/usr/lib/jack/jack_firewire.so':
libffado.so.2: cannot open shared object file: No such file or directory
jack_get_descriptor : dll jack_firewire.so is not a driver
Segmentation fault (core dumped)
[root@archlinux rocketmouse]# pacman -Qi jack2
Name : jack2
Version : 1.9.9.5-1
URL : http://jackaudio.org/
Licenses : GPL
Groups : None
Provides : jack jackmp jackdmp jackdbus
Depends On : libsamplerate celt
Optional Deps : libffado: FireWire support
dbus-core: jackdbus
python2: jack_control
Required By : None
Conflicts With : jack
Replaces : None
Installed Size : 3132.00 KiB
Packager : Rashif Rahman (Ray) <schiv(a)archlinux.org>
Architecture : x86_64
Build Date : Mon 10 Dec 2012 10:10:29 PM CET
Install Date : Tue 19 Feb 2013 06:17:18 AM CET
Install Reason : Explicitly installed
Install Script : No
Description : The next-generation JACK with SMP support
One issue fixed and the next appeared soon :D.
[rocketmouse@archlinux ~]$ jackd --help
[snip]
Segmentation fault (core dumped)
I was working as root, so I run "help" as root, but jackd2 fails for the
user too.
24 Feb
24 Feb
1:21 p.m.
New subject: jackd2 Was: OT: sending sysex while jackd runs
On Sun, Feb 24, 2013 at 5:51 AM, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>wrote;wrote:
Optional Deps
I had the same problem with the newest jack2 under Arch when I reinstalled
a system recently. The solution was to install ffado, which was confusing
considering that it is listed as an optional depends. I'm sure there was a
bug report or forum entry about this but I can't seem to find it now.
1:35 p.m.
New subject: jackd2 Was: OT: sending sysex while jackd runs
On Sun, 2013-02-24 at 21:21 +0900, michael noble wrote:
On Sun, Feb 24, 2013 at 5:51 AM, Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net> wrote:
Optional Deps
I had the same problem with the newest jack2 under Arch when I
reinstalled a system recently. The solution was to install ffado,
which was confusing considering that it is listed as an optional
depends. I'm sure there was a bug report or forum entry about this but
I can't seem to find it now.
There are three reports, including my ticket, because by accident I
missed, that there already were two tickets.
When searching the bug tracker for "community" packages, you need to
select it in the upper left corner ;).
https://bugs.archlinux.org/task/33991
Yes, I could solve it too, but I still get a strange output
$ jackd --help
jackdmp 1.9.9.5
no message buffer overruns
no message buffer overruns
no message buffer overruns
[it continues with the wanted "help"]
*?*
I've got no time to test audio today.
23 Feb
23 Feb
9:57 p.m.
On Sat, Feb 23, 2013 at 3:19 PM, Fons Adriaensen <fons(a)linuxaudio.org>wrote;wrote:
On Sat, Feb 23, 2013 at 01:09:28PM -0500, Paul Davis
wrote:
Are there any technical reasons why whatever method a2jmidi
is using is not adopted for the backend ? Maybe it's just a
matter of manpower, but OTOH this situation with the backend
failing to do 'the right thing' has existed for quite some
time now.
it is just a question of manpower. i already did factor out most of the
a2j* code into an internal client that jackd could load. the problems
remaining:
* whether or not to provide a new way to load such clients (e.g. on the
jackd command line)
* what to do about the dbus integration that is used in a2jmidid to
pick up the arrival and departure of
new MIDI interfaces
I'm not sure that dbus is actually necessary for this - i think the
sequencer API has its own way of announcing new clients (and the departure
of existing ones) - but I have not investigated it enough to come to a
conclusion.
On Sat, Feb 23, 2013 at 11:16 AM, Johannes Kroll
<jkroll(a)lavabit.com>
wrote:
I don't know if there's such a tool. But AFAIK jack would only block
the raw MIDI device when you use "-X raw" to use the raw MIDI driver in
jack. Do you need that driver? If you don't, you can use the "seq"
to reiterate: if timing matters to you, do NOT use -X raw or -X seq.
use a2jmidid -e instead.
10:39 p.m.
On Sat, Feb 23, 2013 at 03:57:38PM -0500, Paul Davis wrote:
I'm not sure that dbus is actually necessary for
this - i think the
sequencer API has its own way of announcing new clients (and the departure
of existing ones) - but I have not investigated it enough to come to a
conclusion.
Currently '-X seq' seems to detect new clients, so would anything
new be required ?
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)
4291
days inactive
4292
days old
linux-audio-user@lists.linuxaudio.org
23 comments
9 participants
participants (9)
-
Brent Busby -
Devin Anderson -
Fons Adriaensen -
Johannes Kroll -
Len Ovens -
michael noble -
Paul Davis -
Ralf Mardorf -
Tim E. Real