9 Nov
2008
9 Nov
'08
6:12 p.m.
release candidate 2 has some important fixes:
* Fix for #46 - on first save of newly appeared clients, their state
was not correcttly recorded as being saved and thus was not being
restored on project load afterwards.
* Memory corruption fixes caused by bug in stdout/stderr handling
code. Was happening when lash client outputs lot of data to stdout or
stderr
* Improved handling of repeating lines sent to stdout/stderr
I would like to ask LASH beleivers and other interested parties to test
the 0.6.0 release candidate. Juuso Alasuutari and me have been doing
some major changes to the lash code. We have done lot of work, we've
fixed several big implementation issues and we need stable point before
doing more changes (0.6.1 and 1.0 milestones).
In the tarball there is simple lash_control script. One can also control
LASH through patchage-0.4.2 and through lpatchage (availabe through
git).
User visible changes since 0.5.4:
* Use jack D-Bus interface instead of libjack, enabled by default, can
be disabled. Ticket #1
* Allow controlling LASH through D-Bus. Ticket #2
* Use D-Bus autolaunching instead of old mechanism. Ticket #3
* Log file (~/.log/lash/lash.log) for LASH daemon. Ticket #4
* Client stdout/stderr are logged to lash.log, when clients are
launched by LASH daemon (project restore). Ticket #5
* Improved handling of misbehaved clients. Ticket #45
* Projects now can have comment and notes associated. Ticket #13
Download:
http://download.savannah.gnu.org/releases/lash/lash-0.6.0~rc2.tar.bz2
http://download.savannah.gnu.org/releases/lash/lash-0.6.0~rc2.tar.bz2.sig
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
10 Nov
10 Nov
4:30 p.m.
Nedko, it's installed and running, and perhaps a related note to a challenge
i was having with an Ingen runstate (segfaulted), Ingen now works, along
with Jackdbus, lpatchage, and now lash.
(Note to Dave Drobilla. I posted a ticket on your Trac showing the error
messages i got when starting ingen with $ ingen -eg.)
So far so good.
I have, in the lpatchage window, lash active, and a2jmidi active reflecting
the successful run state.
Not sure what else to include here. There's no hard crashing going on, or
odd behaviour so far. (And i'm pleased Ingen is running ok now, on F8,
CCRMA, 32bit. The 64bit boot is stable, with jackdbus, etc, but you know
that already, as you helped me 'tune' it, a little while ago. Thanks)
I've been out of the loop for a while, but there's a sizable 'coming
together' of all these components, and it shows.
I'll post more if i have a problem, or challenge, as i use it more.
Alex.
On Mon, Nov 10, 2008 at 1:12 AM, Nedko Arnaudov <nedko(a)arnaudov.name> wrote:
release candidate 2 has some important fixes:
* Fix for #46 - on first save of newly appeared clients, their state
was not correcttly recorded as being saved and thus was not being
restored on project load afterwards.
* Memory corruption fixes caused by bug in stdout/stderr handling
code. Was happening when lash client outputs lot of data to stdout or
stderr
* Improved handling of repeating lines sent to stdout/stderr
I would like to ask LASH beleivers and other interested parties to test
the 0.6.0 release candidate. Juuso Alasuutari and me have been doing
some major changes to the lash code. We have done lot of work, we've
fixed several big implementation issues and we need stable point before
doing more changes (0.6.1 and 1.0 milestones).
In the tarball there is simple lash_control script. One can also control
LASH through patchage-0.4.2 and through lpatchage (availabe through
git).
User visible changes since 0.5.4:
* Use jack D-Bus interface instead of libjack, enabled by default, can
be disabled. Ticket #1
* Allow controlling LASH through D-Bus. Ticket #2
* Use D-Bus autolaunching instead of old mechanism. Ticket #3
* Log file (~/.log/lash/lash.log) for LASH daemon. Ticket #4
* Client stdout/stderr are logged to lash.log, when clients are
launched by LASH daemon (project restore). Ticket #5
* Improved handling of misbehaved clients. Ticket #45
* Projects now can have comment and notes associated. Ticket #13
Download:
http://download.savannah.gnu.org/releases/lash/lash-0.6.0~rc2.tar.bz2<ht…
http://download.savannah.gnu.org/releases/lash/lash-0.6.0~rc2.tar.bz2.sig&l…
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
11 Nov
11 Nov
6:34 a.m.
Nedko,
A pic of a running setup.
http://shup.com/Shup/80177/Screenshot-Patchage.png
Linuxsampler (latest SVN) doing the soundengine work with a simple midi
keyboard in, and a fairly generic orchestral draft template in Ardour
2.6.1.Still to add Jconv and ingen to this pic, but so far so good.
(This is a sampler and recorder setup, not dissimilar to using a HW sampler
and tapedeck. Call me old fashioned...)
1 challenge has been shutting down Ardour. It takes jackdbus with it, but
that may well be user setup error, so i'm not submitting this in
an....official way just yet.
Alex.
On Mon, Nov 10, 2008 at 11:30 PM, alex stone <compose59(a)gmail.com> wrote:
Nedko, it's installed and running, and perhaps a
related note to a
challenge i was having with an Ingen runstate (segfaulted), Ingen now
works, along with Jackdbus, lpatchage, and now lash.
(Note to Dave Drobilla. I posted a ticket on your Trac showing the error
messages i got when starting ingen with $ ingen -eg.)
So far so good.
I have, in the lpatchage window, lash active, and a2jmidi active reflecting
the successful run state.
Not sure what else to include here. There's no hard crashing going on, or
odd behaviour so far. (And i'm pleased Ingen is running ok now, on F8,
CCRMA, 32bit. The 64bit boot is stable, with jackdbus, etc, but you know
that already, as you helped me 'tune' it, a little while ago. Thanks)
I've been out of the loop for a while, but there's a sizable 'coming
together' of all these components, and it shows.
I'll post more if i have a problem, or challenge, as i use it more.
Alex.
On Mon, Nov 10, 2008 at 1:12 AM, Nedko Arnaudov <nedko(a)arnaudov.name>wrote;wrote:
release candidate 2 has some important fixes:
* Fix for #46 - on first save of newly appeared clients, their state
was not correcttly recorded as being saved and thus was not being
restored on project load afterwards.
* Memory corruption fixes caused by bug in stdout/stderr handling
code. Was happening when lash client outputs lot of data to stdout or
stderr
* Improved handling of repeating lines sent to stdout/stderr
I would like to ask LASH beleivers and other interested parties to test
the 0.6.0 release candidate. Juuso Alasuutari and me have been doing
some major changes to the lash code. We have done lot of work, we've
fixed several big implementation issues and we need stable point before
doing more changes (0.6.1 and 1.0 milestones).
In the tarball there is simple lash_control script. One can also control
LASH through patchage-0.4.2 and through lpatchage (availabe through
git).
User visible changes since 0.5.4:
* Use jack D-Bus interface instead of libjack, enabled by default, can
be disabled. Ticket #1
* Allow controlling LASH through D-Bus. Ticket #2
* Use D-Bus autolaunching instead of old mechanism. Ticket #3
* Log file (~/.log/lash/lash.log) for LASH daemon. Ticket #4
* Client stdout/stderr are logged to lash.log, when clients are
launched by LASH daemon (project restore). Ticket #5
* Improved handling of misbehaved clients. Ticket #45
* Projects now can have comment and notes associated. Ticket #13
Download:
http://download.savannah.gnu.org/releases/lash/lash-0.6.0~rc2.tar.bz2<ht…
http://download.savannah.gnu.org/releases/lash/lash-0.6.0~rc2.tar.bz2.sig&l…
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
6:36 a.m.
"alex stone" <compose59(a)gmail.com> writes:
I have, in the lpatchage window, lash active, and
a2jmidi active reflecting
the successful run state.
Not sure what else to include here. There's no hard crashing going on, or
odd behaviour so far. (And i'm pleased Ingen is running ok now, on F8,
CCRMA, 32bit. The 64bit boot is stable, with jackdbus, etc, but you know
that already, as you helped me 'tune' it, a little while ago. Thanks)
I've been out of the loop for a while, but there's a sizable 'coming
together' of all these components, and it shows.
I'll post more if i have a problem, or challenge, as i use it more.
Alex, thank you for your report! Having "everything works" smoothly is
very encouraging! The only major LADI thing that I've not implemented
yet is support for liblash-less clients. Main target is ardour :) I hope
to fix this before the end of November.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
6:46 a.m.
Nedko,
No problem.
I recorded most of the day yesterday, and got 1 xrun with the simple setup
in the pic.
I'm not complaining.
Alex.
p.s. I'm going to give it all a hammering today with Rosegarden, and see if
some heavy duty midi trips anything up.
On Tue, Nov 11, 2008 at 1:36 PM, Nedko Arnaudov <nedko(a)arnaudov.name> wrote:
"alex stone" <compose59(a)gmail.com>
writes:
I have, in the lpatchage window, lash active, and
a2jmidi active
reflecting
the successful run state.
Not sure what else to include here. There's no hard crashing going on, or
odd behaviour so far. (And i'm pleased Ingen is running ok now, on F8,
CCRMA, 32bit. The 64bit boot is stable, with jackdbus, etc, but you know
that already, as you helped me 'tune' it, a little while ago. Thanks)
I've been out of the loop for a while, but there's a sizable 'coming
together' of all these components, and it shows.
I'll post more if i have a problem, or challenge, as i use it more.
Alex, thank you for your report! Having "everything works" smoothly is
very encouraging! The only major LADI thing that I've not implemented
yet is support for liblash-less clients. Main target is ardour :) I hope
to fix this before the end of November.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
6:58 a.m.
alex stone wrote:
Nedko,
No problem.
I recorded most of the day yesterday, and got 1 xrun with the simple
setup in the pic.
I'm not complaining.
Alex.
p.s. I'm going to give it all a hammering today with Rosegarden, and
see if some heavy duty midi trips anything up.
That image is quite beautiful.
Do you mind if I post it on the lau-guide?
Cheers.
--
Patrick Shirkey
Boost Hardware Ltd.
7:01 a.m.
Patrick, you are more than welcome to post this, or any other pics i post
here.
Alex.
On Tue, Nov 11, 2008 at 1:56 PM, Patrick Shirkey <pshirkey(a)boosthardware.com
wrote:
alex stone wrote:
Nedko,
No problem.
I recorded most of the day yesterday, and got 1 xrun with the simple setup
in the pic.
I'm not complaining.
Alex.
p.s. I'm going to give it all a hammering today with Rosegarden, and see
if some heavy duty midi trips anything up.
That image is quite beautiful.
Do you mind if I post it on the lau-guide?
Cheers.
--
Patrick Shirkey
Boost Hardware Ltd.
9:19 a.m.
Ok,some more observations.
The first pic is an overview of a Rosegarden midi driven generic orchestral
drafting setup. You'll note that RG midi connects to linuxsampler midi fine,
as LS midi for this template is Alsa.
http//shup.com/Shup/80213/Screenshot-Patchage-1.png
The second pic is a closeup of the jackmidi challenges that appear.
http//shup.com/Shup/80214/Screenshot-Patchage-2.png
To explain:
In an LS template, with Jack as midi, RG will not cable to LS in the above
pic. I see this as fairly obvious, as RG midi is alsa, and the A2Jbridge
handles the transaction between Alsa, and Jack midi.
Therein lies the challenge.
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.
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.
Not sure if any of the above will help, but it's observations at this time
of testing.
Patrick, if you want to use these pics as well, please do.
The Ardour/Jackdbus stopping challenge is solved, with a reinstall of
Ardour. (User error reigns supreme here....)
Alex.
On Tue, Nov 11, 2008 at 1:56 PM, Patrick Shirkey <pshirkey(a)boosthardware.com
wrote:
alex stone wrote:
Nedko,
No problem.
I recorded most of the day yesterday, and got 1 xrun with the simple setup
in the pic.
I'm not complaining.
Alex.
p.s. I'm going to give it all a hammering today with Rosegarden, and see
if some heavy duty midi trips anything up.
That image is quite beautiful.
Do you mind if I post it on the lau-guide?
Cheers.
--
Patrick Shirkey
Boost Hardware Ltd.
9:21 a.m.
Sorry, i messed up the pic links.
http://shup.com/Shup/80213/Screenshot-Patchage-1.png
http://shup.com/Shup/80214/Screenshot-Patchage-2.png
On Tue, Nov 11, 2008 at 4:19 PM, alex stone <compose59(a)gmail.com> wrote:
Ok,some more observations.
The first pic is an overview of a Rosegarden midi driven generic orchestral
drafting setup. You'll note that RG midi connects to linuxsampler midi fine,
as LS midi for this template is Alsa.
http//shup.com/Shup/80213/Screenshot-Patchage-1.png
The second pic is a closeup of the jackmidi challenges that appear.
http//shup.com/Shup/80214/Screenshot-Patchage-2.png
To explain:
In an LS template, with Jack as midi, RG will not cable to LS in the above
pic. I see this as fairly obvious, as RG midi is alsa, and the A2Jbridge
handles the transaction between Alsa, and Jack midi.
Therein lies the challenge.
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.
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.
Not sure if any of the above will help, but it's observations at this time
of testing.
Patrick, if you want to use these pics as well, please do.
The Ardour/Jackdbus stopping challenge is solved, with a reinstall of
Ardour. (User error reigns supreme here....)
Alex.
On Tue, Nov 11, 2008 at 1:56 PM, Patrick Shirkey <
pshirkey(a)boosthardware.com> wrote:
alex stone wrote:
Nedko,
No problem.
I recorded most of the day yesterday, and got 1 xrun with the simple
setup in the pic.
I'm not complaining.
Alex.
p.s. I'm going to give it all a hammering today with Rosegarden, and see
if some heavy duty midi trips anything up.
That image is quite beautiful.
Do you mind if I post it on the lau-guide?
Cheers.
--
Patrick Shirkey
Boost Hardware Ltd.
9:56 a.m.
"alex stone" <compose59(a)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>
10:24 a.m.
On Tue, Nov 11, 2008 at 4:55 PM, Nedko Arnaudov <nedko(a)arnaudov.name> wrote:
"alex stone" <compose59(a)gmail.com>
writes:
>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.
I didn't know this, i'll have a look. I've been using alsa seq for all, not
realising a2jmidid would 'duplicate' alsa legacy app ports.
>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.
No user error? I'm amazed...
>BTW I'm surprised that you managed to connect Rosegarden trough
>a2jmidid. I was under impression that it needs static alsa<->jack
>bridges,
I may not have explained this properly. In the pic you can see RG midi
cabled to LS midi. Both are Alsa. I couldn't use the a2jbridge.
>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?
Qjackctl confirms the ports are cabled together. They simply don't show as
connected in lpatchage, even with a refresh, or restart.
Still using "jack_lsp -c" next time may be helpgul ;)
I've written this down, O learned one .........
Alex.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
11:12 a.m.
"alex stone" <compose59(a)gmail.com> writes:
lpatchage cannot patch ALSA. Thus I really dont how you did that :]
Can you please create simple test case for reproducing the issue?
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
>BTW
I'm surprised that you managed to connect Rosegarden trough
>a2jmidid. I was under impression that it needs static alsa<->jack
>bridges,
I may not have explained this properly. In the pic you can see RG midi
cabled to LS midi. Both are Alsa. I couldn't use the a2jbridge. >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?
Qjackctl confirms the ports are cabled together. They simply don't show as
connected in lpatchage, even with a refresh, or restart.
11:58 a.m.
Nedko, if you're lost in this then i have no chance. :)
With everything still intact, and the visible cable connections still active
in the lpatchage pic i posted before, this is what qjackctl shows me.
http://shup.com/Shup/80256/jack1.png
http://shup.com/Shup/80256/jack.png
And here's the lpatchage pic of RG, my midi keyboard, and LS, all lashed
together, reflecting the connections shown in Qjackctl.
http://shup.com/Shup/80261/patch3.png
This tells me i have connections in both alsa, and a2j, at the same time.
If lpatchage shows me a connection(s) then what is it? a2j? You've already
written that lpatchage can't patch alsa, so it must be a2j, yes?
If lpatchage won't show me alsa connections at all, then all of what we see
is a2j midi, and raw. (nice advice, thanks.)
I will admit here i don't understand how i can connect RG in lpatchage, if
RG is static bridge and won't respond to a2j. The pics seem to say
otherwise, and the connection to Linuxsampler as well has me thoroughly
mystified, if this is the case. (And i'll be the first to admit i'm a
complete wizard at the gentle art of user error.)
Alex.
:)
On Tue, Nov 11, 2008 at 6:11 PM, Nedko Arnaudov <nedko(a)arnaudov.name> wrote:
"alex stone" <compose59(a)gmail.com>
writes:
lpatchage cannot patch ALSA. Thus I really dont how you did that :]
as
>BTW
I'm surprised that you managed to connect Rosegarden trough
>a2jmidid. I was under impression that it needs static alsa<->jack
>bridges,
I may not have explained this properly. In the pic you can see RG midi
cabled to LS midi. Both are Alsa. I couldn't use the a2jbridge. > >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?
Qjackctl confirms the ports are cabled together. They simply don't show connected in lpatchage, even with a refresh, or
restart.
Can you please create simple test case for reproducing the issue?
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
12:22 p.m.
"alex stone" <compose59(a)gmail.com> writes:
Nedko, if you're lost in this then i have no
chance. :)
With everything still intact, and the visible cable connections still active
in the lpatchage pic i posted before, this is what qjackctl shows me.
http://shup.com/Shup/80256/jack1.png
This shows you have JACK MIDI connections between rosegarden and
linuxsampler. both apps are alsa seq and midi goes:
rosegarden -> a2jmidid -> jack midi -> a2jmidid -> linuxsampler
qjackctl shows jack midi connections in midi tab, alsa seq connections
in alsa tab.
does not open here
And here's the lpatchage pic of RG, my midi
keyboard, and LS, all lashed
together, reflecting the connections shown in Qjackctl.
http://shup.com/Shup/80261/patch3.png
Those are JACK MIDI connections.
This tells me i have connections in both alsa, and
a2j, at the same time.
If lpatchage shows me a connection(s) then what is it? a2j? You've already
written that lpatchage can't patch alsa, so it must be a2j, yes?
yes ;)
I will admit here i don't understand how i can
connect RG in lpatchage, if
RG is static bridge and won't respond to a2j. The pics seem to say
otherwise, and the connection to Linuxsampler as well has me thoroughly
mystified, if this is the case. (And i'll be the first to admit i'm a
complete wizard at the gentle art of user error.)
RG is not static bridge. I was refering to alsaseq-jackmidi static
bridges. a2jmidid is dynamic bridge, dynamic means, it automatically
creates JACK MIDI ports for ALSA seq midi ports. I've tried to exmpain
things in a2jmidid README:
http://home.gna.org/a2jmidid/README
My confusion about RG is, that I was under impression that rosegarden
does not create output alsa seq midi ports but just sends midi events to
exisiting alsa seq midi input ports. I think i've checked this but maybe
I just got it wrong. I dont really use RG.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
12:32 p.m.
Ok, now i have it (Sorry, it takes a while)
The lpatchage connections are jackmidi (bridged) from RG and LS. I've turned
off midi-seq, and i'm using raw for these pics. I can't connect RG midi to
LS 'straight' jack midi, but i CAN connect RG alsamidi, to LS alsamidi,
using the bridge. I can live with that. :)
All well and good, and i'll just need to be careful when hooking RG to LS,
that i don't connect things twice. (By connecting RG to LS in RG port
settings, AND in lpatchage)
But i'm still at a loss as to why i can't connect LS audio out, to Ardour
audio in, in lpatchage, visibly.
It works in Qjackctl, but stubbornly refuses to connect in lpatchage, even
though the actual connections are made in Ardour, and most importantly,
work.
Still, it's all working, not crashing, doesn't twitch, etc...
There is good news. :)
Alex.
On Tue, Nov 11, 2008 at 7:22 PM, Nedko Arnaudov <nedko(a)arnaudov.name> wrote:
"alex stone" <compose59(a)gmail.com>
writes:
Nedko, if you're lost in this then i have no
chance. :)
With everything still intact, and the visible cable connections still
active
in the lpatchage pic i posted before, this is
what qjackctl shows me.
http://shup.com/Shup/80256/jack1.png
This shows you have JACK MIDI connections between rosegarden and
linuxsampler. both apps are alsa seq and midi goes:
rosegarden -> a2jmidid -> jack midi -> a2jmidid -> linuxsampler
qjackctl shows jack midi connections in midi tab, alsa seq connections
in alsa tab.
does not open here
And here's the lpatchage pic of RG, my midi
keyboard, and LS, all lashed
together, reflecting the connections shown in Qjackctl.
http://shup.com/Shup/80261/patch3.png
Those are JACK MIDI connections.
This tells me i have connections in both alsa,
and a2j, at the same time.
If lpatchage shows me a connection(s) then what is it? a2j? You've
already
written that lpatchage can't patch alsa, so
it must be a2j, yes?
yes ;)
I will admit here i don't understand how i
can connect RG in lpatchage,
if
RG is static bridge and won't respond to a2j.
The pics seem to say
otherwise, and the connection to Linuxsampler as well has me thoroughly
mystified, if this is the case. (And i'll be the first to admit i'm a
complete wizard at the gentle art of user error.)
RG is not static bridge. I was refering to alsaseq-jackmidi static
bridges. a2jmidid is dynamic bridge, dynamic means, it automatically
creates JACK MIDI ports for ALSA seq midi ports. I've tried to exmpain
things in a2jmidid README:
http://home.gna.org/a2jmidid/README
My confusion about RG is, that I was under impression that rosegarden
does not create output alsa seq midi ports but just sends midi events to
exisiting alsa seq midi input ports. I think i've checked this but maybe
I just got it wrong. I dont really use RG.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
1:56 p.m.
"alex stone" <compose59(a)gmail.com> writes:
But i'm still at a loss as to why i can't
connect LS audio out, to Ardour
audio in, in lpatchage, visibly.
It works in Qjackctl, but stubbornly refuses to connect in lpatchage, even
though the actual connections are made in Ardour, and most importantly,
work.
Do you get any errors in jackdbus log file when you are trying to
connect using lpatchage?
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
5851
days inactive
5853
days old
linux-audio-dev@lists.linuxaudio.org
15 comments
3 participants
participants (3)
-
alex stone -
Nedko Arnaudov -
Patrick Shirkey