[LAD] [ANN] lash-0.6.0 release candidate 2

Nedko Arnaudov nedko at arnaudov.name
Tue Nov 11 13:55:40 UTC 2008


"alex stone" <compose59 at gmail.com> writes:

> If you look closely at the system capture ports on the left of the second
> pic, you'll see midi represented firstly as ports 1-5 (which reflect midi
> through as 1 port, my first MK midi keyboard as 1 port, and three ports of
> my second, PCR midi keyboard. I assume this is seen as all "Hardware", and
> always appear as the primary ports in any system capture midi port list)
>
> After these 5 ports, there's a sudden jump to port 84, and so on from there.
> As i've opened and closed some apps while lpatchage is still open, i'm
> assuming here that the port numbers are not reset for each newly started
> app, but just continue on to next port number in sequence.
> In order to accurately reflect the correct Alsa2Jack port number, and using
> system playback midi ports, i would then have to recount port numbers in the
> hope that they would accurately correspond to the midi ports reflected in
> the newly opened app. This may be ok for a template with 4 or 5 ports, but
> as you can see in the pic, numerous ports present a challenge of cabling,
> counting, etc...
>
> It's only after a complete restart of all apps, and jackdbus stop/start,
> that system midi ports, both capture and playback, assume some orderly
> numerical sequence.
> A refresh of lpatchage doesn't produce any change, or reflect the 'new'
> state of apps, or ports.

I think you use both sequencer backend of JACK and a2jmidid, they both
handle "legacy" ALSA seq apps. I personally use raw midi backend for
handling hardware ports and a2jmidid for handling "legacy" ALSA seq
apps.

As for port numbering, your observations matches my knowledge about the
code, i.e. port numbers are increasing and reset to 0 on jack server
start.

BTW I'm surprised that you managed to connect Rosegarden trough
a2jmidid. I was under impression that it needs static alsa<->jack
bridges,

> The second challenge is LS audio outs to Ardour audio in. These do not
> appear as cabled. I've set LS audio in to Ardour tracks from within Ardour,
> they work, but are not shown in lpatchage, even with saving the state of all
> apps, closing everything, including stopping and restarting Jackdbus, then
> initiating all apps again. Not such a big problem if, like me, templates
> tend to stay fairly static, but for someone who relies on constant changes
> and adjustments, i can see this as a hill to climb.

This indeed sounds strange. Maybe it is some bug in jackdbus patchbay
code. As test, can you please check whether those audio connections
appear through libjack interface, either using qjackctl or jack_lsp with
-c option?

> The Ardour/Jackdbus stopping challenge is solved, with a reinstall of
> Ardour. (User error reigns supreme here....)

Still using "jack_lsp -c" next time may be helpgul ;)

-- 
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20081111/78da7bd3/attachment.pgp>


More information about the Linux-audio-dev mailing list