Re: [LAD] OT: mkdosfs as normal user

[Patrick Shirkey]

On Tue, 2008-11-11 at 23:30 -0600, David M. Creswick wrote:
> On Tue, 11 Nov 2008 09:53:17 +0700
> Patrick Shirkey <[EMAIL PROTECTED]> wrote:
> 
> > Joern Nettingsmeier wrote:
> > > Patrick Shirkey wrote:
> > >   
> > >> Hi,
> > >>
> > >> I can't find anything online that gives me a way to run /sbin/mkdosfs as
> > >> a normal user. 
> > >>
> > >> Is it just that I need to add the user to the mkdosfs group or something
> > >> similar?
> > >> 
> > >
> > > are you sure the program itself prevents that? my guess is it's the
> > > device you want to create the file on.
> > >
> > > should be a matter of creating a new group disk_removable or something,
> > > writing an udev rule to give it r/w access to all floppies and usb
> > > sticks and add yourself to that group.
> > >
> > >   
> > Thanks for the tip.
> > 
> > I'm working on it now.
> > 
> > However this seems like a major oversight from a Linux on the desktop 
> > perspective that you need to be root user to format a removable disk. It 
> > would make sense that Nautilus or Konqueror  would have built in support 
> > by now.
> > 
> > Does anyone have experience with any distros/apps allowing this as 
> > normal user?
> > 
> > It seems like it should be a no brainer.
> > 
> 
> I think Joern is correct in that all you need is read+write permissions
> on the device node. Under debian etch, the group is set to "floppy" for
> device nodes of removable usb storage devices. I imagine other distros
> do something similar. So the user should just have to be a member of
> the floppy (or equivalent) group to run mkdosfs on the device.
> 
> 

Thanks for the tip. I ran this command:

/usr/sbin/usermod -a -G floppy username

On Fedora9 at least the floppy group does not control removeable disks.

I also tried the disk group but nothing...

Any other suggestions?

Yesterday I was looking at adding an exception to hal but I couldn't
find the mode key syntax.

I was thinking of something like this:



   

  666

  






-- 
Patrick Shirkey
Boost Hardware Ltd

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] OT: mkdosfs as normal user

[David M. Creswick]

On Tue, 11 Nov 2008 09:53:17 +0700
Patrick Shirkey <[EMAIL PROTECTED]> wrote:

> Joern Nettingsmeier wrote:
> > Patrick Shirkey wrote:
> >   
> >> Hi,
> >>
> >> I can't find anything online that gives me a way to run /sbin/mkdosfs as
> >> a normal user. 
> >>
> >> Is it just that I need to add the user to the mkdosfs group or something
> >> similar?
> >> 
> >
> > are you sure the program itself prevents that? my guess is it's the
> > device you want to create the file on.
> >
> > should be a matter of creating a new group disk_removable or something,
> > writing an udev rule to give it r/w access to all floppies and usb
> > sticks and add yourself to that group.
> >
> >   
> Thanks for the tip.
> 
> I'm working on it now.
> 
> However this seems like a major oversight from a Linux on the desktop 
> perspective that you need to be root user to format a removable disk. It 
> would make sense that Nautilus or Konqueror  would have built in support 
> by now.
> 
> Does anyone have experience with any distros/apps allowing this as 
> normal user?
> 
> It seems like it should be a no brainer.
> 

I think Joern is correct in that all you need is read+write permissions
on the device node. Under debian etch, the group is set to "floppy" for
device nodes of removable usb storage devices. I imagine other distros
do something similar. So the user should just have to be a member of
the floppy (or equivalent) group to run mkdosfs on the device.



-- 
David M. Creswick
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

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

[Nedko Arnaudov]

"alex stone" <[EMAIL PROTECTED]> 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 


pgp9vEZd0hZOf.pgp
Description: PGP signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

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

[alex stone]

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 <[EMAIL PROTECTED]> wrote:

> "alex stone" <[EMAIL PROTECTED]> 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.
>
> > http://shup.com/Shup/80256/jack.png
>
> 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 
>
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

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

[Nedko Arnaudov]

"alex stone" <[EMAIL PROTECTED]> 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.

> http://shup.com/Shup/80256/jack.png

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 


pgp3DzV9b6rpR.pgp
Description: PGP signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

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

[alex stone]

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 <[EMAIL PROTECTED]> wrote:

> "alex stone" <[EMAIL PROTECTED]> writes:
>
> >> >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.
>
> lpatchage cannot patch ALSA. Thus I really dont how you did that :]
>
> >> >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.
>
> Can you please create simple test case for reproducing the issue?
>
> --
> Nedko Arnaudov 
>
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] Jack MTC/MMC slaving

[Nedko Arnaudov]

"Alex Montgomery" <[EMAIL PROTECTED]> writes:

>> I already have git repository for jackctlmmc. If you are interested I
>> can make it public. Before importing it to git, I had the source of the
>> quickly hacked tool in my local filesystem (no version control at all).
>>
>
> Yeah, if you could make it public via git that'd be very helpful. I
> personally won't have time to code until the weekend unfortunately.

http://repo.or.cz/w/jackctlmmc.git

-- 
Nedko Arnaudov 


pgpUudiaNHj09.pgp
Description: PGP signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

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

[Nedko Arnaudov]

"alex stone" <[EMAIL PROTECTED]> writes:

>> >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.

lpatchage cannot patch ALSA. Thus I really dont how you did that :]

>> >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.

Can you please create simple test case for reproducing the issue?

-- 
Nedko Arnaudov 


pgpvy1Ukq4Va0.pgp
Description: PGP signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] Jack MTC/MMC slaving

[Alex Montgomery]

> I already have git repository for jackctlmmc. If you are interested I
> can make it public. Before importing it to git, I had the source of the
> quickly hacked tool in my local filesystem (no version control at all).
>

Yeah, if you could make it public via git that'd be very helpful. I
personally won't have time to code until the weekend unfortunately.

> Currently jackctlmmc supports the "play", "stop", and "rewind"
> > messages from MMC, and I'm going to play with the code to see if I
>
> can add support for "locate" using jack_transport_locate() so that
> > players can have a primitive seek-to type of function.
>
> yeah, I was going to suggest you try. I went down that road trying to
> code a jack-transport-sequencer. Alas most of the jack-clients won't
> play fluid if you relocate the transport periodically to keep in sync.
>

For now I just want to add support for the MMC "Locate/Go to" message 44 (
http://en.wikipedia.org/wiki/MIDI_Machine_Control ), not use
jack_transport_locate to try to keep them in sync. I'm guessing there's a
better way to do that than jumping JACK around as you're experience seems to
indicate. Again, I'm new to this so I'm going to gather more information
from the web and you guys before I try to tackle something like clock drift.
I'm sure there are much more qualified people for this reading this email
thread.

> agreed. and it may be easier to remain that way if users want easy
> control over MMC ID and a few other parameters related to MMC handling.
> however the appeal of using some "parameter setting protocol" to set
> this in a client that is otherwise invisible is fairly apparent.

I'll try to convert any settings that the user might want to change to
command line parameters for now, and we can rewrite it quite easily when/if
we want to change it to an in-server JACK client.

-- Alex
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

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

[alex stone]

On Tue, Nov 11, 2008 at 4:55 PM, Nedko Arnaudov <[EMAIL PROTECTED]> wrote:

> "alex stone" <[EMAIL PROTECTED]> 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 
>
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

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

[Nedko Arnaudov]

"alex stone" <[EMAIL PROTECTED]> 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 


pgpftaAtesuyB.pgp
Description: PGP signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] Jack MTC/MMC slaving

[Robin Gareus]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Paul Davis wrote:
> On Sun, 2008-11-09 at 15:21 +, Alex Montgomery wrote:
>> Hello, I'm guessing from the research I've done online and from the
>> lack of responses to my LAU message (
>> http://www.nabble.com/Slaving-jack-to-MMC-MTC-to20357929.html )
>> that JACK does not currently support slaving to external (or
>> internal?) devices via MMC/MTC. I'm a C/C++ developer by trade, so
>> I'm happy to get my hands dirty, but I wanted to know what other
>> work, if any, has been done on this front. I've been told that both
>> Rosegarden and Ardour can sync to MTC, but that they cannot then
>> drive JACK transport in that mode. Would it be difficult to move
>> this code over to JACK? Is there a reason this in't desirable?
> 
> JACK does not and will not support varispeed. Therefore slaving to
> MTC is going to be pretty limited. MMC also sends some speed commands
> that could not be supported by JACK.

I have been addressing similar issues in a different context:

Jack could provide multiple transports mechanisms, additional transports
can be derived from the master-transport or generated from external input.

However this would only be available to newer applications supporting
this jack-transport2 interface and leave it to the client application
to decide what to do (resample, vari-speed or pitch-shift..)

I don't know if the jack-protocol can be changed to accommodate multiple
transports without breaking binary compatibility. So
Implementation wise this could be done my distributing MTC over
JACK-MIDI (sync to the master-transport) and provide some wrapper
functions with libjack to query (parse received data) and control (send
command to time-source/jack-server) it.

> Currently jackctlmmc supports the "play", "stop", and "rewind" 
> messages from MMC, and I'm going to play with the code to see if I
> can add support for "locate" using jack_transport_locate() so that
> players can have a primitive seek-to type of function. 

yeah, I was going to suggest you try. I went down that road trying to
code a jack-transport-sequencer. Alas most of the jack-clients won't
play fluid if you relocate the transport periodically to keep in sync.

> I think that
> even this limited subset of MMC functionality is very desirable for
> linux audio engineers. I just want to be able to sit at my 8-track
> with my guitar and play/stop, rewind, and maybe seek around without
> having to keep clicking a mouse on a JACK app.

Ardour has build in support for MMC and MTC. I've used it quite a lot to
get old recordings from a Roland VS890 into gnu/Linux. Scrub-wheel,
Faders, start/stop BTNS can all be mapped via MIDI.

For syncing to jack-transport: I've used the other way around: generate
MTC from JACK and feed it into the 8-track. - MMC (start/stop buttons on
the VS890) can still control JACK-transport, but the scrub-wheel (uses
MTC and some realtime sysex) does not work this way.

so long,
robin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkkZirEACgkQeVUk8U+VK0LmugCeOaEH9BqoXINnI419T/372KAE
HfAAnRYzhAbt1PQsQNDS4FnDMRP8kert
=RItW
-END PGP SIGNATURE-
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

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

[alex stone]

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 <[EMAIL PROTECTED]> 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 <
> [EMAIL PROTECTED]> 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.
>>
>>
>>
>>
>
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

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

[alex stone]

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 <[EMAIL PROTECTED]
> 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.
>
>
>
>
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] Jack MTC/MMC slaving

[Nedko Arnaudov]

Stéphane Letz <[EMAIL PROTECTED]> writes:

> Le 11 nov. 08 à 13:48, Nedko Arnaudov a écrit :
>
>> "Alex Montgomery" <[EMAIL PROTECTED]> writes:
>>
>>> Currently jackctlmmc supports the "play", "stop", and "rewind"
>>> messages from
>>> MMC, and I'm going to play with the code to see if I can add
>>> support for
>>> "locate" using jack_transport_locate() so that players can have a
>>> primitive
>>> seek-to type of function. I think that even this limited subset of
>>> MMC
>>> functionality is very desirable for linux audio engineers. I just
>>> want to be
>>> able to sit at my 8-track with my guitar and play/stop, rewind,
>>> and maybe
>>> seek around without having to keep clicking a mouse on a JACK app.
>>
>> I already have git repository for jackctlmmc. If you are interested I
>> can make it public. Before importing it to git, I had the source of
>> the
>> quickly hacked tool in my local filesystem (no version control at
>> all).
>>
>>> I'm surprised that jackctlmmc doesn't seem to be that widely used
>>> (I can't
>>> find any packages for it in the major linux distros, and it only
>>> seems to be
>>> distributed via source code) when it provides such useful
>>> functionality. I'd
>>> love to see it's functionality integrated into a GUI app like
>>> QJackCtl
>>> (which already has JACK transport buttons for play, rewind, fast-
>>> forward)
>>> instead of being a console application, but that's a subject for
>>> another
>>> email.
>>
>> I think jackctlmmc can be made to be compilable as inprocess client
>> too.
>
> Good idea.
>
>>
>> Paul, Stephane and others, do you think we should have different
>> directories for jack1 and jack2 drivers/internal clients?
>>
>>
>
> Drivera are definitively a lot different between  jack1 and jack2  and
> internal clients a bit (a new "jack_internal_initialize"  function to
> be used when internal clients are loaded using the new  jack2 control
> API (or jackdbus))
>
> So I don't see too much how they could *not* stay separated

So we should install jack2 drivers and internal clients in
/lib/jack2 instead of /lib/jack ?

Thus out of tree internal clients will work for version they were
compiled. Still this does not fix the issue binary interface changes
between versions.

-- 
Nedko Arnaudov 


pgpeSA7PNM2wq.pgp
Description: PGP signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] Jack MTC/MMC slaving

[Stéphane Letz]

Le 11 nov. 08 à 13:48, Nedko Arnaudov a écrit :

> "Alex Montgomery" <[EMAIL PROTECTED]> writes:
>
>> Currently jackctlmmc supports the "play", "stop", and "rewind"  
>> messages from
>> MMC, and I'm going to play with the code to see if I can add  
>> support for
>> "locate" using jack_transport_locate() so that players can have a  
>> primitive
>> seek-to type of function. I think that even this limited subset of  
>> MMC
>> functionality is very desirable for linux audio engineers. I just  
>> want to be
>> able to sit at my 8-track with my guitar and play/stop, rewind,  
>> and maybe
>> seek around without having to keep clicking a mouse on a JACK app.
>
> I already have git repository for jackctlmmc. If you are interested I
> can make it public. Before importing it to git, I had the source of  
> the
> quickly hacked tool in my local filesystem (no version control at  
> all).
>
>> I'm surprised that jackctlmmc doesn't seem to be that widely used  
>> (I can't
>> find any packages for it in the major linux distros, and it only  
>> seems to be
>> distributed via source code) when it provides such useful  
>> functionality. I'd
>> love to see it's functionality integrated into a GUI app like  
>> QJackCtl
>> (which already has JACK transport buttons for play, rewind, fast- 
>> forward)
>> instead of being a console application, but that's a subject for  
>> another
>> email.
>
> I think jackctlmmc can be made to be compilable as inprocess client  
> too.

Good idea.

>
> Paul, Stephane and others, do you think we should have different
> directories for jack1 and jack2 drivers/internal clients?
>
>

Drivera are definitively a lot different between  jack1 and jack2  
and  internal clients a bit (a new "jack_internal_initialize"  
function to be used when internal clients are loaded using the new  
jack2 control API (or jackdbus))

So I don't see too much how they could *not* stay separated

Stephane
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Re: [LAD] Jack MTC/MMC slaving

[Nedko Arnaudov]

"Alex Montgomery" <[EMAIL PROTECTED]> writes:

> Currently jackctlmmc supports the "play", "stop", and "rewind" messages from
> MMC, and I'm going to play with the code to see if I can add support for
> "locate" using jack_transport_locate() so that players can have a primitive
> seek-to type of function. I think that even this limited subset of MMC
> functionality is very desirable for linux audio engineers. I just want to be
> able to sit at my 8-track with my guitar and play/stop, rewind, and maybe
> seek around without having to keep clicking a mouse on a JACK app.

I already have git repository for jackctlmmc. If you are interested I
can make it public. Before importing it to git, I had the source of the
quickly hacked tool in my local filesystem (no version control at all).

> I'm surprised that jackctlmmc doesn't seem to be that widely used (I can't
> find any packages for it in the major linux distros, and it only seems to be
> distributed via source code) when it provides such useful functionality. I'd
> love to see it's functionality integrated into a GUI app like QJackCtl
> (which already has JACK transport buttons for play, rewind, fast-forward)
> instead of being a console application, but that's a subject for another
> email.

I think jackctlmmc can be made to be compilable as inprocess client too.

Paul, Stephane and others, do you think we should have different
directories for jack1 and jack2 drivers/internal clients?

-- 
Nedko Arnaudov 


pgpwIfbCYuvZt.pgp
Description: PGP signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

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

[alex stone]

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 <[EMAIL PROTECTED]
> 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.
>
>
>
>
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

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

[Patrick Shirkey]

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.



___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

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

[alex stone]

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 <[EMAIL PROTECTED]> wrote:

> "alex stone" <[EMAIL PROTECTED]> 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 
>
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

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

[Nedko Arnaudov]

"alex stone" <[EMAIL PROTECTED]> 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 


pgpdK61EsOSjP.pgp
Description: PGP signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

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

[alex stone]

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
anofficial way just yet.

Alex.

On Mon, Nov 10, 2008 at 11:30 PM, alex stone <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>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
>> http://download.savannah.gnu.org/releases/lash/lash-0.6.0~rc2.tar.bz2.sig
>>
>> --
>> Nedko Arnaudov 
>>
>> ___
>> Linux-audio-dev mailing list
>> Linux-audio-dev@lists.linuxaudio.org
>> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>>
>>
>
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev