aconnect no longer accepts truncated clientnames ?

[Peter Billam]

Greetings, I hope you're all still here...

I've just upgraded from debian squeeze to wheezy, and suddenly
all my scripts are failing :-(
$ aconnect Pro Rol
invalid sender address Pro
$ aconnect 'ProKeys Sono 88' Rol
invalid destination address Rol
$ aconnect 'ProKeys Sono 88' 'Roland XV-2020'
$

That's unergonomic. I don't want to have to type these long names
with quote marks all the time, there's no tab-completion available
because they're not filenames.

Of course there are workarounds; in .bash_profile I could define
export V1='Virtual Raw MIDI 1-0'
export K='Keystation 49e'
and change all my scripts; or, neater, I could move /usr/bin/aconnect
aside and put a little perl wrapper-script in place.

And yet, man aconnect says:
% aconnect External:0 Emu8000:1
Then the port 0 of the client matching with the string "External" is
connected to the port 1 of the client matching with the "Emu8000".
Note "matching with"... so it's almost as if the man page
thinks that start-of-string matching is still available !?

I'm not sure what aconnect version this, because
aconnect --version ; aconnect -v
don't tell me, but it's /usr/bin/aconnect in debian wheezy.

Any ideas ?

Regards, Peter

--
Peter Billam www.pjb.com.au www.pjb.com.au/comp/contact.html

[Peter Billam]

On 2013-05-12, Peter Billam <pe...@www.pjb.com.au> wrote:
> Greetings, I hope you're all still here...
> I've just upgraded from debian squeeze to wheezy, and suddenly
> all my scripts are failing :-(
> $ aconnect Pro Rol
> invalid sender address Pro
> $ aconnect 'ProKeys Sono 88' Rol
> invalid destination address Rol
> $ aconnect 'ProKeys Sono 88' 'Roland XV-2020'
> $

The problem is down at the alsa library level in the parse_address
routine, so it also affects all my own software, like the Perl
CPAN module MIDI::ALSA ...

#! /usr/bin/perl
use MIDI::ALSA;
my $c = MIDI::ALSA::client('a_name',1,1,0);
for my $s (qw(TiM TiMidity)) {
my ($a,$b) = MIDI::ALSA::parse_address($s);
print "parse_address($s) is ($a,$b)\n";
}
prints:
parse_address(TiM) is (,)
parse_address(TiMidity) is (128,0)

but that routine just calls the C routine, thus:
snd_seq_addr_t *addr;
addr = alloca(sizeof(snd_seq_addr_t));
int rc = snd_seq_parse_address(seq_handle, addr, port_name);

[Clemens Ladisch]

Peter Billam wrote:
> I've just upgraded from debian squeeze to wheezy, and suddenly
> all my scripts are failing :-(
> $ aconnect Pro Rol
> invalid sender address Pro

> $ aconnect 'ProKeys Sono 88' 'Roland XV-2020'

This change was made three years ago, in alsa-lib 1.0.24:
<http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=19892334499e>

> it's almost as if the man page
> thinks that start-of-string matching is still available !?

Not only the man page. Two years later(!), the old behaviour was
documented:
<http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=193724743965>
(And the aplaymidi/arecordmidi man pages explicitly say this.)

I consider this regression a bug.
I'll change it to match the longest prefix.


Regards,
Clemens

[Pete]

In article <slrnkp05l2...@box8.pjb.com.au>,

Peter Billam <contac...@www.pjb.com.au> wrote:
>Greetings, I hope you're all still here...

Me, anyway... (:-))

>
>I've just upgraded from debian squeeze to wheezy, and suddenly
>all my scripts are failing :-(
> $ aconnect Pro Rol
> invalid sender address Pro
> $ aconnect 'ProKeys Sono 88' Rol
> invalid destination address Rol
> $ aconnect 'ProKeys Sono 88' 'Roland XV-2020'
> $
>

Hah! Thank You...! (:-/)

I *thought* that was the way it used to work, but I haven't used it
for quite a while, and I typically just use the client-number:port
scheme, rather than names, anyway.

However, I've just got myself an Axiom 49 (v2), which seems pretty
nice, *except* for one somewhat severe bug. The MIDI-IN port on the
back doesn't really work! It's fine as long as it's the only MIDI
stream, but if you try to use the Axiom's own keys (especially
Aftertouch) at the same time it just stops dead...

Trying to have as rational conversation as possible with the tech
support zombie, I decided a command-line recipe would be good, so
I went into Ubuntu on my laptop and tried setting up an example
aseqdump command. As you say, the abbreviation I thought I'd use
doesn't work. I have to use the full "Axiom 49:2" form.

When I saw your post, I went back to my sturdy but slow old machine
still running Hardy Heron (!) and sure enough the abbreviation works.

In either form, I still think it's a bit of a strange mixture.
I see the list:

...
client 24: 'Axiom 49' [type=kernel]
0 'Axiom 49 MIDI 1 '
1 'Axiom 49 MIDI 2 '
2 'Axiom 49 MIDI 3 '
...

where the port labels -- which I can't use in either version --
go 1,2,3, but the ports are actually 0..2. So to get 'Axiom 49 MIDI 3 ',
I have to type, say, (old scheme) Ax:2.

Oh, well...

-- Pete --

[Looks from the parts of your post I snipped that you have some M-Audio
stuff, too. How do you find it? More by chance than anything, almost
all my MIDI stuff is theirs -- since they were "MidiMan", with my original
"GMan" synth box that I bought for the Amiga, and that still soldiers on.
This in fact is the first time I've had any problems with them.]

--
============================================================================
The address in the header is a Spam Bucket -- replies will not be seen...
(If you do need to email, replace the account name with my true name.)
============================================================================

[Peter Billam]

On 2013-05-14, Pete <neve...@GOODEVEca.net> wrote:
> In either form, I still think it's a bit of a strange mixture.
> I see the list:

> client 24: 'Axiom 49' [type=kernel]
> 0 'Axiom 49 MIDI 1 '
> 1 'Axiom 49 MIDI 2 '
> 2 'Axiom 49 MIDI 3 '

> where the port labels -- which I can't use in either version --
> go 1,2,3, but the ports are actually 0..2.

Well, the "Axiom 49 MIDI 1 " strings are just labels, just strings,
they could also be "Thribglookrithwoknipug". But the 0,1,2 are
genuine numbers, in the natural order that numbers really are in.

> [Looks from the parts of your post I snipped that you have some
> M-Audio stuff, too. How do you find it?

Pretty good; the 'ProKeys Sono 88' is the main workhorse, cheap
and light, and has an inbuilt synth so can run independently.
The 'Keystation 49e' is older (10 years?) and often its
patch-change doesn't do anything :-( but I like the way it has
no knobs up on that surface beyond the keys, because then I can
stack keyboards one behind the other like organ-keyboards.

But I'm still looking for a keyboard which has not just a no-knob
top-panel, but also an undercut at the the front (beneath the front
edge of the keys) of the same depth, let's say 60mm. That would
allow me to stack three keyboards and still reach the third easily.

I also have an Oxygen 25 and an Oxygen 49, but they have too many
knobs so are unstackable except at the back (when you can't see the
labels on the knobs), and are too bulky beneath front-edge-of-the-keys
and therefore unstackable except at the front of the stack;
so they don't fit anywhere and I don't use them much.

> More by chance than anything, almost all my MIDI stuff is theirs

All my keyboards are. My workhorse synth 'Roland XV-2020'
has been really good, no audible latency and uncrashable.
Like once, I connected the output of a 'Midi Through' client back
to its input, so as soon as you play the first note it generates
an infinite number of events in zero time; the synth made a
slightly unusual high-pitched sound but never lost its composure.

I wrote:
> neater, I could move /usr/bin/aconnect aside
> and put a little perl wrapper-script in place.

My $PATH starts with /usr/local/bin, so I did a little
/usr/local/bin/aconnect (symlinked to aplaymidi and arecordmidi)
which is a primitive hack but it means all my scripts and
Makefiles work again, so I think I'll run like this:

#! /usr/bin/perl
use File::Basename;
my @new_argv = ("/usr/bin/".basename($0));
foreach (@ARGV) {
if (/^Pro(:\d)?/) { push @new_argv, "ProKeys Sono 88$1";
} elsif (/^Key(:\d)?/) { push @new_argv, "Keystation 49e$1";
} elsif (/^Rol(:\d)?/) { push @new_argv, "Roland XV-2020$1";
} elsif (/^TiM(:\d)?/) { push @new_argv, "TiMidity$1";
} elsif (/^Midi(:\d)?/) { push @new_argv, "Midi Through$1";
} else { push @new_argv, $_;
}
}
exec @new_argv;

Clemens wrote:
> This change was made three years ago, in alsa-lib 1.0.24:
> <http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=19892334499e>

It's sad that it takes 3 years to work its way into debian stable.

[Pete]

In article <slrnkp4422...@box8.pjb.com.au>,

Peter Billam <contac...@www.pjb.com.au> wrote:
>On 2013-05-14, Pete <neve...@GOODEVEca.net> wrote:
>> In either form, I still think it's a bit of a strange mixture.
>> I see the list:
>> client 24: 'Axiom 49' [type=kernel]
>> 0 'Axiom 49 MIDI 1 '
>> 1 'Axiom 49 MIDI 2 '
>> 2 'Axiom 49 MIDI 3 '
>> where the port labels -- which I can't use in either version --
>> go 1,2,3, but the ports are actually 0..2.
>
>Well, the "Axiom 49 MIDI 1 " strings are just labels, just strings,
>they could also be "Thribglookrithwoknipug". But the 0,1,2 are
>genuine numbers, in the natural order that numbers really are in.

Yes, but those labels are not from the device, but generated by ALSA
(as far as I can tell), which tags on the 'MIDI 1', etc. So for
consistency I think they should also start 'MIDI 0'. Same sort of
dilemma as with Program Change numbers...

>
>> [Looks from the parts of your post I snipped that you have some
>> M-Audio stuff, too. How do you find it?
>
>Pretty good; the 'ProKeys Sono 88' is the main workhorse, cheap
>and light, and has an inbuilt synth so can run independently.
>The 'Keystation 49e' is older (10 years?) and often its
>patch-change doesn't do anything :-( but I like the way it has
>no knobs up on that surface beyond the keys, because then I can
>stack keyboards one behind the other like organ-keyboards.

Sounds like you have the same sort of constraints I do. (:-/)
I had to do some thinking before I bought the 49, to make sure I could
*handle* two keyboards! I haven't the space for the sort of stands
that folks use on stage, and the table the piano is on really has to
be wheeled, so I can move it aside to get at things. Fortunately,
with an old printer base of just about the right height as a back
support, the 49 sits nicely on the back edge of the piano.

>
>But I'm still looking for a keyboard which has not just a no-knob
>top-panel, but also an undercut at the the front (beneath the front
>edge of the keys) of the same depth, let's say 60mm. That would
>allow me to stack three keyboards and still reach the third easily.

I wonder if there's a market for a "Home Studio Keyboard Stacking
System"? (:-)) Hold several K/Bs (with some access space between
them) but without needing the floor space of the stage scheme...

>
>I also have an Oxygen 25 and an Oxygen 49, but they have too many
>knobs so are unstackable except at the back (when you can't see the
>labels on the knobs), and are too bulky beneath front-edge-of-the-keys
>and therefore unstackable except at the front of the stack;
>so they don't fit anywhere and I don't use them much.

Of course the reason I wanted the Axiom was *because* of all its
buttons, sliders, and knobs! The piano's voice buttons and display
are compactly above the keys, so the Axiom fits without blocking them.

With the computer's help, I'm not sure how many keyboards one actually
*needs*. As I say the main point of the Axiom is all the extra controllers
it gives me access to. Though I must say it's nice to be able to play
a voice with each hand without having to split the piano K/B...

>
>
>I wrote:
>> neater, I could move /usr/bin/aconnect aside
>> and put a little perl wrapper-script in place.

> [....]

That seems a neat solution.

Cheers,

-- Pete --