From gbertis@yahoo.com.br Mon Apr  2 16:09:03 2012
From: Guilherme Bertissolo <gbertis@yahoo.com.br>
To: linux-audio-dev@lists.linuxaudio.org
Subject: [LAD] (no subject)
Date: Mon, 02 Apr 2012 16:09:03 +0000
Message-ID: <1333382938.39266.YahooMailMobile@web126002.mail.ne1.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5013673776687597539=="

--===============5013673776687597539==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<a href=3D"http://enacte.cl/components/02efpk.html"> http://enacte.cl/compone=
nts/02efpk.html</a>



--===============5013673776687597539==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PHRhYmxlIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgYm9yZGVyPSIwIj48dHI+PHRk
IHZhbGlnbj0idG9wIiBzdHlsZT0iZm9udDogaW5oZXJpdDsiPjxkaXY+PGEgaHJlZj0iaHR0cDov
L2VuYWN0ZS5jbC9jb21wb25lbnRzLzAyZWZway5odG1sIj4gaHR0cDovL2VuYWN0ZS5jbC9jb21w
b25lbnRzLzAyZWZway5odG1sPC9hPjwvZGl2PjwvdGQ+PC90cj48L3RhYmxlPg==

--===============5013673776687597539==--


From rosea.grammostola@gmail.com Mon Apr  2 16:12:19 2012
From: "rosea.grammostola" <rosea.grammostola@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Mon, 02 Apr 2012 16:12:19 +0000
Message-ID: <4F79CFBE.1070007@gmail.com>
In-Reply-To:
 <CAFa_cKk0xfzoNU9y=_ZUvH7X3+aWhSQRw86FEWQoiZwo2Mr2Tw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6727205496274555228=="

--===============6727205496274555228==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 03/30/2012 12:27 PM, Paul Davis wrote:
> re: the "central" media location  - in rui's defense i'd like to point
> out that it took cubase more than 10 years to move away from something
> fairly close to his model.

Ok, that will be 5 yrs for Rui then ;)

Serious though. What does this mean for Qtractor and NSM in theory?

Qtractor can't apply to the strict session saving rules of NSM atm and 
not in the near future? If so, is there a solution for this from the 
perspective of Qtractor and NSM?
Are there other applications with this same 'problem'?

Best regards,

\r


--===============6727205496274555228==--


From malnourite@gmail.com Mon Apr  2 17:17:15 2012
From: "J. Liles" <malnourite@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Mon, 02 Apr 2012 17:17:15 +0000
Message-ID:
 <CAGhWSSb__qcS1zhG+mTr24EBgNa3H1PfHT5r6a1AZxFjBkAqQA@mail.gmail.com>
In-Reply-To: <4F79CFBE.1070007@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4014554006806493013=="

--===============4014554006806493013==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Mon, Apr 2, 2012 at 9:11 AM, rosea.grammostola
<rosea.grammostola(a)gmail.com> wrote:
> On 03/30/2012 12:27 PM, Paul Davis wrote:
>>
>> re: the "central" media location  - in rui's defense i'd like to point
>> out that it took cubase more than 10 years to move away from something
>> fairly close to his model.
>
>
> Ok, that will be 5 yrs for Rui then ;)
>
> Serious though. What does this mean for Qtractor and NSM in theory?

It wouldn't be a problem if qtractor either kept all new media in its
per-application area of the session directory when running under NSM
or at least symlinked to the external files. There is precedent for
applications using completely different project formats when under SM
(for example, Yoshimi's ".state" files [although that functionality
appears to be broken in the stable release of yoshimi]). A session is
something that applications /participate/ in, and participation means
having to do some things differently in order to cooperate with the
session manager for the user's benefit, so IMHO none of this is asking
too much.

And, anyway, it's not /really/ a problem in practice until you want to
trasnport a session, and in that case you'd just have to follow
whatever qtractor's procedure is for doing that.

It's an interesting point and one that I'll need to state explicitly
in the next version of the API.

> Qtractor can't apply to the strict session saving rules of NSM atm and not
> in the near future? If so, is there a solution for this from the perspective
> of Qtractor and NSM?
> Are there other applications with this same 'problem'?

There are probably a few. I think Freewheeling also tries to store all
recorded loops in a central place in the users home directory. It's a
pretty unusual thing to do though and the truth is that the vast
majority of applications don't have heavy state and keep all project
information in memory and save/restore it from a single file. Anyway,
from my perspective, correcting the problem is as simple as adding a
rule to the NSM API that states:

* When connected to a session, the client *MUST* store all new media
(recorded audio, etc.) related to the open project in the project path
provided by the `open` message.

I can't imagine why Rui or anyone else would have a problem with this,
as it is exactly equivalent to the user saying "Please store my
precious data somewhere predictable that I have predefined instead of
in whatever random place the application developer thought would be
good."

--===============4014554006806493013==--


From rncbc@rncbc.org Mon Apr  2 18:29:27 2012
From: Rui Nuno Capela <rncbc@rncbc.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Mon, 02 Apr 2012 18:29:27 +0000
Message-ID: <4F79F025.5020600@rncbc.org>
In-Reply-To: <4F79CFBE.1070007@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3287220729731868492=="

--===============3287220729731868492==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/02/2012 05:11 PM, rosea.grammostola wrote:
> On 03/30/2012 12:27 PM, Paul Davis wrote:
>> re: the "central" media location - in rui's defense i'd like to point
>> out that it took cubase more than 10 years to move away from something
>> fairly close to his model.
>
> Ok, that will be 5 yrs for Rui then ;)
>
> Serious though. What does this mean for Qtractor and NSM in theory?
>
> Qtractor can't apply to the strict session saving rules of NSM atm and
> not in the near future? If so, is there a solution for this from the
> perspective of Qtractor and NSM?

it's just unlikely, not that it won't apply to the rules :)

for instance, qtractor doesn't apply to the jack-session and ladish 
rules on 100% but it works on both as long as you don't EVER mix 
qtractor sessions directories with SM's session directories. that is, it 
is always possible to use qtractor's gui file menu save/save as... to 
replace any SM session directory but not recommended though, ever.
depending on "unpredictable circumstances", one will sooner or later 
break either or both session states (qtractor session and/or the SM's 
one) when you try to load any later on

point is, in qtractor terms at least, saving a managed-session takes a 
different and specific code path. read that like a managed-session save 
operation is kind of a instant snapshot, which doesn't even change the 
current qtractor session title, path or dirty flag at all, if any

nb. all this applies whether the "external files symlinking" are 
implemented or not (will that be an option or shall be mandatory by SM 
protocol design?); it's about session state integrity and not session 
directory "centrality" or "portability"

in conclusion. qtractor may be always made to work as a NSM client. 
that's orthogonal to the "session directory dilemma", which i think this 
is what Paul's referring to

alas, all is just not *my* top priority atm. meanwhile, any patch would 
be welcome, of course ;)

byee
-- 
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org

--===============3287220729731868492==--


From xbran@web.de Mon Apr  2 18:29:54 2012
From: Emanuel Rumpf <xbran@web.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Mon, 02 Apr 2012 18:29:54 +0000
Message-ID:
 <CAGQuJFKxguLUTzXCpyi19cB5OVaHtMjn2d+_qx2v-5orNouz4g@mail.gmail.com>
In-Reply-To:
 <CAGhWSSb__qcS1zhG+mTr24EBgNa3H1PfHT5r6a1AZxFjBkAqQA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0097466294601949035=="

--===============0097466294601949035==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Am 2. April 2012 19:17 schrieb J. Liles <malnourite(a)gmail.com>:

> Anyway,
> from my perspective, correcting the problem is as simple as adding a
> rule to the NSM API that states:
>
> * When connected to a session, the client *MUST* store all new media
> (recorded audio, etc.) related to the open project in the project path
> provided by the `open` message.
>

I thought - that's what we would not want: store large files in the
session dir !?
....because duplicating a session should stay a "light" and fast process.

That is, why I had been proposing an "nsm-large-files" directory
(outside of the session-folder), for those,
but actually, it doesn't matter, _where_ NSM-clients store their "large-files=
",
as long as they create symlinks for them in the session folder.

(maybe the sub-directory for symlinks should be defined as part of the
API. proposition: "external-file-links").


-- -- -- --
Remember my definitions:

What is a large-file ?
 - every (larger) file, that is not required to immediately be
   copied if, a session is cloned.
 - every file, where a reference is enough in the first place

What is NO-large-file ?
 - data that is required to access large-files (references, symlinks)
 - that is lightweight (~ below 1MB) (some config-values)
 - has to be read by the SM to initialize the client
-- -- -- --


> I can't imagine why Rui or anyone else would have a problem with this,
> as it is exactly equivalent to the user saying
>
> "Please store my
> precious data somewhere predictable that I have predefined instead of
> in whatever random place the application developer thought would be
> good."

My exact intention.


Regards, Emanuel
--=20
E.R.

--===============0097466294601949035==--


From pgiblox@gmail.com Mon Apr  2 18:39:36 2012
From: Paul Giblock <pgiblox@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Mon, 02 Apr 2012 18:39:36 +0000
Message-ID:
 <CACSaQFn1UGv-YqTtKsz=NngTPQeHKvtB830rVucfFEHLMF1VRQ@mail.gmail.com>
In-Reply-To: <4F79F025.5020600@rncbc.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4596647681460531792=="

--===============4596647681460531792==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

> nb. all this applies whether the "external files symlinking" are
implemented or not (will that be an option or shall be mandatory by SM
protocol design?);

Do all target filesystems support symbolic links?



--===============4596647681460531792==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PHA+PGJyPgomZ3Q7IG5iLiBhbGwgdGhpcyBhcHBsaWVzIHdoZXRoZXIgdGhlICZxdW90O2V4dGVy
bmFsIGZpbGVzIHN5bWxpbmtpbmcmcXVvdDsgYXJlIGltcGxlbWVudGVkIG9yIG5vdCAod2lsbCB0
aGF0IGJlIGFuIG9wdGlvbiBvciBzaGFsbCBiZSBtYW5kYXRvcnkgYnkgU00gcHJvdG9jb2wgZGVz
aWduPyk7PC9wPgo8cD5EbyBhbGwgdGFyZ2V0IGZpbGVzeXN0ZW1zIHN1cHBvcnQgc3ltYm9saWMg
bGlua3M/PGJyPgo8L3A+Cg==

--===============4596647681460531792==--


From xbran@web.de Mon Apr  2 18:51:50 2012
From: Emanuel Rumpf <xbran@web.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Mon, 02 Apr 2012 18:51:50 +0000
Message-ID:
 <CAGQuJFL7hLxFkC4c-73+YUw+C=AwGNMjtcHi5oypQvrkv6u8wQ@mail.gmail.com>
In-Reply-To:
 <CACSaQFn1UGv-YqTtKsz=NngTPQeHKvtB830rVucfFEHLMF1VRQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3705302615412719150=="

--===============3705302615412719150==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Am 2. April 2012 20:39 schrieb Paul Giblock <pgiblox(a)gmail.com>:
> Do all target filesystems support symbolic links?
>

yeah ? what would happen to the links, if one copied the session
folder to his/her fat32 usb-stick ?
simply don't !! ?

or de-reference...

-- 
E.R.

--===============3705302615412719150==--


From pgiblox@gmail.com Mon Apr  2 19:07:08 2012
From: Paul Giblock <pgiblox@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Mon, 02 Apr 2012 19:07:08 +0000
Message-ID:
 <CACSaQFnu=VPQQ+eFB4_Zz6+HpCJsx+5rPMPHO_joFF2ooWNtHg@mail.gmail.com>
In-Reply-To:
 <CAGQuJFL7hLxFkC4c-73+YUw+C=AwGNMjtcHi5oypQvrkv6u8wQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3481252779813886339=="

--===============3481252779813886339==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

> > Do all target filesystems support symbolic links?
> >
>
> yeah ? what would happen to the links, if one copied the session
> folder to his/her fat32 usb-stick ?
> simply don't !! ?
> or de-reference...

I didn't necessarily mean for transport or archival. I imagine "just
dereference it" is one of the motivations for links in the first place.  I
was more concerned about windows users, or people with large external
(fat32) drives who wish to use this filesystem for their live session
storage.  I just checked and NTFS at least supports symlinks.

-- Paul



--===============3481252779813886339==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PHA+PGJyPgomZ3Q7ICZndDsgRG8gYWxsIHRhcmdldCBmaWxlc3lzdGVtcyBzdXBwb3J0IHN5bWJv
bGljIGxpbmtzPzxicj4KJmd0OyAmZ3Q7PGJyPgomZ3Q7PGJyPgomZ3Q7IHllYWggPyB3aGF0IHdv
dWxkIGhhcHBlbiB0byB0aGUgbGlua3MsIGlmIG9uZSBjb3BpZWQgdGhlIHNlc3Npb248YnI+CiZn
dDsgZm9sZGVyIHRvIGhpcy9oZXIgZmF0MzIgdXNiLXN0aWNrID88YnI+CiZndDsgc2ltcGx5IGRv
biYjMzk7dCAhISA/PGJyPgomZ3Q7IG9yIGRlLXJlZmVyZW5jZS4uLiA8L3A+CjxwPkkgZGlkbiYj
Mzk7dCBuZWNlc3NhcmlseSBtZWFuIGZvciB0cmFuc3BvcnQgb3IgYXJjaGl2YWwuIEkgaW1hZ2lu
ZSAmcXVvdDtqdXN0IGRlcmVmZXJlbmNlIGl0JnF1b3Q7IGlzIG9uZSBvZiB0aGUgbW90aXZhdGlv
bnMgZm9yIGxpbmtzIGluIHRoZSBmaXJzdCBwbGFjZS6gIEkgd2FzIG1vcmUgY29uY2VybmVkIGFi
b3V0IHdpbmRvd3MgdXNlcnMsIG9yIHBlb3BsZSB3aXRoIGxhcmdlIGV4dGVybmFsIChmYXQzMikg
ZHJpdmVzIHdobyB3aXNoIHRvIHVzZSB0aGlzIGZpbGVzeXN0ZW0gZm9yIHRoZWlyIGxpdmUgc2Vz
c2lvbiBzdG9yYWdlLqAgSSBqdXN0IGNoZWNrZWQgYW5kIE5URlMgYXQgbGVhc3Qgc3VwcG9ydHMg
c3ltbGlua3MuPC9wPgoKPHA+LS0gUGF1bDxicj4KPC9wPgo=

--===============3481252779813886339==--


From malnourite@gmail.com Mon Apr  2 19:11:16 2012
From: "J. Liles" <malnourite@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Mon, 02 Apr 2012 19:11:16 +0000
Message-ID:
 <CAGhWSSZ9y5=ahq7NSYF3o+z1nx3eJu_3oDkDEoyuT=_bPRi_Zg@mail.gmail.com>
In-Reply-To:
 <CACSaQFnu=VPQQ+eFB4_Zz6+HpCJsx+5rPMPHO_joFF2ooWNtHg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0010407293984836801=="

--===============0010407293984836801==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Mon, Apr 2, 2012 at 12:07 PM, Paul Giblock <pgiblox(a)gmail.com> wrote:
> I didn't necessarily mean for transport or archival. I imagine "just
> dereference it" is one of the motivations for links in the first place.  I
> was more concerned about windows users, or people with large external
> (fat32) drives who wish to use this filesystem for their live session
> storage.  I just checked and NTFS at least supports symlinks.

Anyone attempting to store their production audio sessions on a fat32
filesystem is certifiably insane anyway...

--===============0010407293984836801==--


From malnourite@gmail.com Mon Apr  2 19:23:01 2012
From: "J. Liles" <malnourite@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Mon, 02 Apr 2012 19:23:01 +0000
Message-ID:
 <CAGhWSSaUSAd6fYRUJTGtOSgk2wkusF6aya=-QrDuPK97o3AS5Q@mail.gmail.com>
In-Reply-To:
 <CAGQuJFKxguLUTzXCpyi19cB5OVaHtMjn2d+_qx2v-5orNouz4g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8593622330688714792=="

--===============8593622330688714792==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 2, 2012 at 11:29 AM, Emanuel Rumpf <xbran(a)web.de> wrote:
> I thought - that's what we would not want: store large files in the
> session dir !?
> ....because duplicating a session should stay a "light" and fast process.

Personally, I'm fine with having large files in my session
directories. In fact, that's exactly where I want them. Why would one
one to duplicate a session with a lot of pre-recorded audio? And,
anyway, this could be made to work by just storing that common audio
wherever you want and making 'external' references to it in the
session (and hopefully the application involved uses the symlink
technique we've discussed for referring to external files)--all
without the SM having to know anything about it.

> That is, why I had been proposing an "nsm-large-files" directory
> (outside of the session-folder), for those,
> but actually, it doesn't matter, _where_ NSM-clients store their "large-fil=
es",
> as long as they create symlinks for them in the session folder.

Right. As long as there are symlinks it's fine, except that I think it
should be the user deciding where things are stored rather than
individual applications.

Remember, you can always write a simple shell script that moves WAVE
files etc. into a central location outside of the session directories
and replaces them with symlinks. Again, this would be the user
deciding what to do and the SM or the application doesn't have to know
anything about it.

I think this is very much a corner case anyway. Normally, one wants
all the project data and media to be stored on the same filesystem, as
close together as possible, and doesn't care about being able to
duplicate a session with gigabytes of audio data (because... why are
you doing that anyway and why are you doing it so frequently that just
creating the symlinks yourself is too much trouble). Unless the use
case is very compelling, it's hard to justify adding any complexity or
requirements to either the SM or the client applications. Remember,
this is Unix--we don't have to stuff all the functionality into one
tool.

--===============8593622330688714792==--


From seablaede@gmail.com Mon Apr  2 19:34:09 2012
From: Thomas Vecchione <seablaede@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Mon, 02 Apr 2012 19:34:09 +0000
Message-ID:
 <CANo8TMrXzc4YV_-5m_TqANeA0bg7dB9NdBajMwh93UqMxPEhqg@mail.gmail.com>
In-Reply-To:
 <CAGhWSSZ9y5=ahq7NSYF3o+z1nx3eJu_3oDkDEoyuT=_bPRi_Zg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6756767351645835432=="

--===============6756767351645835432==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Mon, Apr 2, 2012 at 3:11 PM, J. Liles <malnourite(a)gmail.com> wrote:

> On Mon, Apr 2, 2012 at 12:07 PM, Paul Giblock <pgiblox(a)gmail.com> wrote:
> > I didn't necessarily mean for transport or archival. I imagine "just
> > dereference it" is one of the motivations for links in the first place.
> I
> > was more concerned about windows users, or people with large external
> > (fat32) drives who wish to use this filesystem for their live session
> > storage.  I just checked and NTFS at least supports symlinks.
>
> Anyone attempting to store their production audio sessions on a fat32
> filesystem is certifiably insane anyway...
>

Can't agree with that.  USB Thumb Drives for instance are still one of the
most common ways to transport sessions and other data and are often
formatted FAT32 for interoperability purposes.

          Seablade



--===============6756767351645835432==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PGJyPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gTW9uLCBBcHIgMiwgMjAxMiBhdCAz
OjExIFBNLCBKLiBMaWxlcyA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzptYWxu
b3VyaXRlQGdtYWlsLmNvbSI+bWFsbm91cml0ZUBnbWFpbC5jb208L2E+Jmd0Ozwvc3Bhbj4gd3Jv
dGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAg
MCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPgo8ZGl2
IGNsYXNzPSJpbSI+T24gTW9uLCBBcHIgMiwgMjAxMiBhdCAxMjowNyBQTSwgUGF1bCBHaWJsb2Nr
ICZsdDs8YSBocmVmPSJtYWlsdG86cGdpYmxveEBnbWFpbC5jb20iPnBnaWJsb3hAZ21haWwuY29t
PC9hPiZndDsgd3JvdGU6PGJyPgomZ3Q7IEkgZGlkbiYjMzk7dCBuZWNlc3NhcmlseSBtZWFuIGZv
ciB0cmFuc3BvcnQgb3IgYXJjaGl2YWwuIEkgaW1hZ2luZSAmcXVvdDtqdXN0PGJyPgomZ3Q7IGRl
cmVmZXJlbmNlIGl0JnF1b3Q7IGlzIG9uZSBvZiB0aGUgbW90aXZhdGlvbnMgZm9yIGxpbmtzIGlu
IHRoZSBmaXJzdCBwbGFjZS6gIEk8YnI+CiZndDsgd2FzIG1vcmUgY29uY2VybmVkIGFib3V0IHdp
bmRvd3MgdXNlcnMsIG9yIHBlb3BsZSB3aXRoIGxhcmdlIGV4dGVybmFsPGJyPgomZ3Q7IChmYXQz
MikgZHJpdmVzIHdobyB3aXNoIHRvIHVzZSB0aGlzIGZpbGVzeXN0ZW0gZm9yIHRoZWlyIGxpdmUg
c2Vzc2lvbjxicj4KJmd0OyBzdG9yYWdlLqAgSSBqdXN0IGNoZWNrZWQgYW5kIE5URlMgYXQgbGVh
c3Qgc3VwcG9ydHMgc3ltbGlua3MuPGJyPgo8YnI+CjwvZGl2PkFueW9uZSBhdHRlbXB0aW5nIHRv
IHN0b3JlIHRoZWlyIHByb2R1Y3Rpb24gYXVkaW8gc2Vzc2lvbnMgb24gYSBmYXQzMjxicj4KZmls
ZXN5c3RlbSBpcyBjZXJ0aWZpYWJseSBpbnNhbmUgYW55d2F5Li4uPGJyPjwvYmxvY2txdW90ZT48
L2Rpdj48YnI+Q2FuJiMzOTt0IGFncmVlIHdpdGggdGhhdC6gIFVTQiBUaHVtYiBEcml2ZXMgZm9y
IGluc3RhbmNlIGFyZSBzdGlsbCBvbmUgb2YgdGhlIG1vc3QgY29tbW9uIHdheXMgdG8gdHJhbnNw
b3J0IHNlc3Npb25zIGFuZCBvdGhlciBkYXRhIGFuZCBhcmUgb2Z0ZW4gZm9ybWF0dGVkIEZBVDMy
IGZvciBpbnRlcm9wZXJhYmlsaXR5IHB1cnBvc2VzLjxicj4KPGJyPqCgoKCgoKCgoCBTZWFibGFk
ZTxicj4K

--===============6756767351645835432==--


From iondiode@yahoo.com Mon Apr  2 19:48:45 2012
From: Tim Westbrook <iondiode@yahoo.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Mon, 02 Apr 2012 19:48:45 +0000
Message-ID:
 <CAL6vFXNp+zret8CtoXQie8+9vzyRe8zkYh5ADDqQ3Y8hUh+X3w@mail.gmail.com>
In-Reply-To:
 <CANo8TMrXzc4YV_-5m_TqANeA0bg7dB9NdBajMwh93UqMxPEhqg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4026422343605548872=="

--===============4026422343605548872==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

> Can't agree with that.  USB Thumb Drives for instance are still one of the
> most common ways to transport sessions and other data and are often
> formatted FAT32 for interoperability purposes.
>
>           Seablade

Luckily tar files do support symlinks. Some folks even create a ext2
fs formatted loopback file on the fat32 partition.

Of course it's a problem if you try to extract that tar file onto a fat32.

Cheers,
Tim

--===============4026422343605548872==--


From xbran@web.de Mon Apr  2 20:05:23 2012
From: Emanuel Rumpf <xbran@web.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Mon, 02 Apr 2012 20:05:23 +0000
Message-ID:
 <CAGQuJFL1TwrucrOCHSKVVOA=KxEwdYc7HS9ht2jPrEQNrX5aVA@mail.gmail.com>
In-Reply-To:
 <CAGhWSSaUSAd6fYRUJTGtOSgk2wkusF6aya=-QrDuPK97o3AS5Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6797647177102552811=="

--===============6797647177102552811==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Am 2. April 2012 21:22 schrieb J. Liles <malnourite(a)gmail.com>:
>
> Personally, I'm fine with having large files in my session
> directories. In fact, that's exactly where I want them.

> Why would one
> want to duplicate a session with a lot of pre-recorded audio?
Maybe with recorded audio, you wouldn't
- although maybe you would (see below).

If you work with samples, OTHO, why would you
want the (same!) samples to be stored in the sessions folder
and even in duplications ?
To waste some space ?


> And,
> anyway, this could be made to work by just storing that common audio
> wherever you want and making 'external' references to it in the
> session

That was our conclusion for using symlinks.
The clients would be advised, to create them
in "../nsm-session/external-file-links/"

> (and hopefully the application involved uses the symlink
> technique we've discussed for referring to external files)--all
> without the SM having to know anything about it.

right

>
> ..., except that I think it
> should be the user deciding where things are stored rather than
> individual applications.
>
Most applications allow that anyway, and if not - it would not hurt much
to change this.

> Remember, you can always write a simple shell script

We can always create shell scripts for anything,
but aren't we talking about some kind of "management" !?

NSM has some nice rules already, to make things behave smooth.
Now add a few sensible rules, to make sure that
audio-file management works equally well.

These are really very simple points, I say.


example:
- clients MUST create symlinks for all external files used - in the
directory "../session/external-file-links/"
- clients are ADVISED to store large-files in "/nsm/large-files/" (and
create symlinks for them as in previous point)


> I think this is very much a corner case anyway.

I think no, but very much depends on personal work-flow.

I use to do different Versions of _the same_ project,
with some minor or major differences.
So my workflow would be:
- create a session
- if happy with a state, duplicate
- continue work with the duplicate.

since many/most files stay the same, there is no reason
to copy the files over different session directories.


-- 
E.R.

--===============6797647177102552811==--


From xbran@web.de Mon Apr  2 20:22:21 2012
From: Emanuel Rumpf <xbran@web.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Mon, 02 Apr 2012 20:22:21 +0000
Message-ID:
 <CAGQuJF+WB8YC=M15pkD1uAnxgKWEuGnMgUFHwtTyBVapPv6LkQ@mail.gmail.com>
In-Reply-To:
 <CAL6vFXNp+zret8CtoXQie8+9vzyRe8zkYh5ADDqQ3Y8hUh+X3w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7364617533608325635=="

--===============7364617533608325635==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

A new thought:

Lets say we did store the session as tar.gz,
and we de-referenced the symlinks.
Means: We have all files related to the session th the tar.gz.
So far, so good.


Now we re-import the session to NSM:
We extract that tar.gz in the NSM sessions-folder.
Note: instead of symlinks we have now real files in the symlinks
directory (because we de-referenced before creating the tar.gz).

Real files should not go to the symlinks directory.
But we could have a simple script, to move these files
to the "nsm-large-files/" folder and re-create the symlinks.

Now we should have a state very similar to where we began.
(exception: we did not restore the file-paths we've had originally,
but symlinked to the nsm-large-files folder instead)

I think this is acceptable
- the session stayed valid at least.

-- 
E.R.

--===============7364617533608325635==--


From rosea.grammostola@gmail.com Mon Apr  2 21:33:26 2012
From: "rosea.grammostola" <rosea.grammostola@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] Non Session Management
Date: Mon, 02 Apr 2012 21:33:26 +0000
Message-ID: <4F7A1AFD.3010105@gmail.com>
In-Reply-To: <1333045249.21680.5.camel@verne.drobilla.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5807108976169275158=="

--===============5807108976169275158==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Apart from the Qtractor scenario (which seems not to be an impossible 
hurdle to take), there is one question left for me and that is:

*Is it needed to remove JackSession support, in order to add NSM support?*

I don't expect this to be true, but afaik JackSession is disabled in the 
NSM Yoshimi patch. I suspect that distro maintainers wants all available 
session options to be enabled for their users.

Other question might be if NSM is able to run crossplatform, but I 
believe the answer is YES (correct me if I'm wrong).

Then of course you have the issue whether devs wants to apply to the 
strict NSM rules, but apart from issues reported by Rui, I didn't hear 
any arguments against it from developers yet.

Regards,

\r



--===============5807108976169275158==--


From joelz@pobox.com Tue Apr  3 05:49:03 2012
From: Joel Roth <joelz@pobox.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Tue, 03 Apr 2012 05:49:03 +0000
Message-ID: <20120403054905.GB3415@sprite>
In-Reply-To:
 <CAGQuJF+TCathtHfXu-pwPJ-taZNPoohW9b2R89EPw5L-qpQsWw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7056164163971648994=="

--===============7056164163971648994==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Thu, Mar 29, 2012 at 03:44:17PM +0200, Emanuel Rumpf wrote:
 
> Back to life - back to reality
> 
> 1. We start qtractor as part of a session, create some midi-tracks,
> include some external wav-files.
> 
> Should the SM "know" about these external files, as I suggested ?
> (Allowing the user to find out basic info about it. )
> Or leave it completely to qtractor ?

As a developer of limited abilities, I would like the bar
of integrating Nama with other programs to be as low
as possible. :-)

As I understand it, the primary motivation for a session
manager is to be able to save and restore the state of an
audio project[1] that consists of multiple interconnected
programs running on a multiprocessing Linux system.

In other words, the minimum capability sufficient to be
useful would be some sort of checkpointing mechanism.

A secondary goal, discussed extensively here, is that it
would be nice to be able to copy a session or export a
session. This is where all the contentious issues with
handling filesystem objects comes up. 

The latter goal should be optional, IMO, rather than required.

Managing files, seems relatively simple in the case of 
of Nama, which is a purely non-destructive editor,

Once recorded, Nama *never* modifies or deletes audio files,
so these files don't need to be involved in checkpointing.
(If a user wants to delete WAV files associated with a bad
take, that is her responsibility.)

All the mutable state information for a project is
serialized and stored as JSON. State files for a project
can be named. In future they will be placed under
VCS to add branching (and possibly
merging) abilities.

If Nama (or Qtractor, Ardour, etc.) is to clone a project,
that concern is internal to the app: I wouldn't expect a
session manager to know it should link the files in the .wav
directory and copy the other files. (Straight copying of
files might not even be appropriate if those files are
under a VCS.)

> 2. We record a new file in qtractor. Where would it be stored ?
> 
> Should the SM "know" about this file ?

There could be advantages to knowing, however if the aim is
to integrate multiple apps, it will be simpler if the SM and
app only need to communicate the project name and checkpoint
ID. (It gets more complicated than that since the SM 
will need to know that Nama should be responsible for
configuring Ecasound and for either connecting Ecasound to
JACK clients or reporting when Ecasound is ready to be
connected.)

> 3. A session is duplicated.
> How does the SM handle the recorded and external files?

Branching a project (assuming VCS, which I believe is the
future :-) would be cheaper than duplicating a project.

If the SM wants an app to duplicate a project, I would
expect the SM to ask the app to create a new project as a
copy of an existing project. Whether the app chooses to use
symlinking, hardlinking, copying files or branching under a
VCS seems to be the app's internal concern.

> 4. A session is exported.
> Jonathan said, current practice is a simple directory copy.
> Well ! Simple and not bad at all.
> But what about the external files ?
> Just make some symlinks for them ?

The state files and audio files for a Nama project
are in a single directory, easy to copy.

However the .namarc config file specifying the ALSA devices
to be used, the audio recording format, the mixdown format
and many other program behaviors currently exists only
in $HOME.

Even if this file were linked or copied into the project
directory, it may not be seamlessly portable to the
audio hardware and configuration of another system. 

If the process of exporting cannot be defined unambiguously,
or involves vast complexity, we might be more successful by
initially restricting our *first* steps to checkpointing
functionality.

Minimizing complexity seems important, as 
the Linux audio world has already gone through
several session management APIs, with none yet
widely adopted.

Regards,

Joel

1. I use the terms "project" and "session" interchangeably.
 
> 
> -- 
> E.R.
-- 
Joel Roth

--===============7056164163971648994==--


From xbran@web.de Tue Apr  3 06:59:35 2012
From: Emanuel Rumpf <xbran@web.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Tue, 03 Apr 2012 06:59:35 +0000
Message-ID:
 <CAGQuJFJtPCJ=mVWGmzC=jqyGbv6kK7WVo_9mB3LoQC-HcB-qZw@mail.gmail.com>
In-Reply-To:
 <CAGQuJFL1TwrucrOCHSKVVOA=KxEwdYc7HS9ht2jPrEQNrX5aVA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3016581473123444027=="

--===============3016581473123444027==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Am 2. April 2012 20:05 schrieb Emanuel Rumpf <xbran(a)web.de>:
>
> NSM has some nice rules already, to make things behave smooth.
> Now add a few sensible rules, to make sure that
> audio-file management works equally well.
>
> These are really very simple points, I say.
>

Proposing a few simple non-intrusive rules:

- clients MUST create symlinks for all external files used - in the
   directory "nsm/ sessions/ mysession/ myapp/ external-file-links/"

 - clients are ADVISED to store large-files in "/nsm/ large-files/"
   (and create symlinks for them as in previous point)

- all NSM-clients treat all files, as if they were inside their
session-directory
   (means: they access all external files over the symlinks)

- if a file must be external, apps create a symlink in
   their external-file-links/ folder and access the file through that link


Without obtruding much on the application, nor on the SM
 (clients just create the symlinks and use them),
this would - for the first version :

 - offer accaptable integrity.

 - ensure all files are either referenced-from or contained-in the session dir

 - ensure, if a file or link in the session-dir is modified or replaced,
   the new version is used by the nsm-client


-- 
E.R.

--===============3016581473123444027==--


From xbran@web.de Tue Apr  3 07:05:00 2012
From: Emanuel Rumpf <xbran@web.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Tue, 03 Apr 2012 07:05:00 +0000
Message-ID:
 <CAGQuJFL-COfCJaa+BAFANJtdbvz4DfwnXXa-jgJf_9CGxn9DVA@mail.gmail.com>
In-Reply-To:
 <CAGQuJFJtPCJ=mVWGmzC=jqyGbv6kK7WVo_9mB3LoQC-HcB-qZw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1327358210724335227=="

--===============1327358210724335227==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

>
>  - offer accaptable integrity.
>

All further, extended functionality (export, import, copy, ...)
could then become part of a script or of version 2.0 of NSM.

--===============1327358210724335227==--


From rncbc@rncbc.org Tue Apr  3 09:05:04 2012
From: rncbc <rncbc@rncbc.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Tue, 03 Apr 2012 09:05:04 +0000
Message-ID: <9264a665805b61a7c3ef4d8d2521ce07@rncbc.org>
In-Reply-To: <20120403054905.GB3415@sprite>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0196510600943441313=="

--===============0196510600943441313==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 03.04.2012 06:49, Joel Roth wrote:
> On Thu, Mar 29, 2012 at 03:44:17PM +0200, Emanuel Rumpf wrote:
>
>> Back to life - back to reality
>>
>> 1. We start qtractor as part of a session, create some midi-tracks,
>> include some external wav-files.
>>
>> Should the SM "know" about these external files, as I suggested ?
>> (Allowing the user to find out basic info about it. )
>> Or leave it completely to qtractor ?
>
<snip>
>
> As I understand it, the primary motivation for a session
> manager is to be able to save and restore the state of an
> audio project[1] that consists of multiple interconnected
> programs running on a multiprocessing Linux system.
>
> In other words, the minimum capability sufficient to be
> useful would be some sort of checkpointing mechanism.
>
> A secondary goal, discussed extensively here, is that it
> would be nice to be able to copy a session or export a
> session. This is where all the contentious issues with
> handling filesystem objects comes up.
>
> The latter goal should be optional, IMO, rather than required.
>
</snip>

this is exactly what i've been trying to tell (only that my english 
wording leaves a lot to be desired)

thanks Joel :)

the primary goal is already achieved by qtractor on jack-session and 
ladish; the second goal is the one i called "utopian".

speaking from a developer's pov. i find it very unlikely that NSM will 
ever get broader acceptance than jack-session and/or ladish, given the 
"utopian" restrictions it poses on client application design.

i wonder for a while: modifying an application to participate in 
jack-session, for instance, is dead simple and costs only a small amount 
of developer time and effort, provided he/she has the proper motivation 
;)

otoh. i have this creepy feeling that, to comply to NSM, one has to 
compromise a lot of the application design and behavior--gui 
restrictions, file location restrictions, osc managing interface, to 
name a few--not that they are bad ideas at all, quite the contrary, but 
they impose a kind of non-negligible (pun intended;) change into 
application workings, unless coded to comply to the NSM-client-logo from 
day zero.

i keep wondering: if that ever flies above its toes then i'll certainly 
call it "The linux-audio revolution" (or miracle, scnr:)

cheers
--
rncbc aka Rui Nuno Capela

--===============0196510600943441313==--


From list@nilsgey.de Tue Apr  3 09:21:32 2012
From: Nils <list@nilsgey.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Tue, 03 Apr 2012 09:21:32 +0000
Message-ID: <20120403112114.4fdb7d8f@nilsgey.de>
In-Reply-To:
 <CAGQuJFL-COfCJaa+BAFANJtdbvz4DfwnXXa-jgJf_9CGxn9DVA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4974497243930367076=="

--===============4974497243930367076==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Tue, 3 Apr 2012 07:04:55 +0000
Emanuel Rumpf <xbran(a)web.de> wrote many things.

Emanuel,

why don't you write your own Session Manager (Protocol)?
You seem to be very knowledgable.

Nils

--===============4974497243930367076==--


From rosea.grammostola@gmail.com Tue Apr  3 09:39:15 2012
From: "rosea.grammostola" <rosea.grammostola@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Tue, 03 Apr 2012 09:39:15 +0000
Message-ID: <4F7AC51E.7070507@gmail.com>
In-Reply-To: <9264a665805b61a7c3ef4d8d2521ce07@rncbc.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7742159837109174042=="

--===============7742159837109174042==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/03/2012 10:05 AM, rncbc wrote:
> On 03.04.2012 06:49, Joel Roth wrote:
>> On Thu, Mar 29, 2012 at 03:44:17PM +0200, Emanuel Rumpf wrote:
>>
>>> Back to life - back to reality
>>>
>>> 1. We start qtractor as part of a session, create some midi-tracks,
>>> include some external wav-files.
>>>
>>> Should the SM "know" about these external files, as I suggested ?
>>> (Allowing the user to find out basic info about it. )
>>> Or leave it completely to qtractor ?
>>
> <snip>
>>
>> As I understand it, the primary motivation for a session
>> manager is to be able to save and restore the state of an
>> audio project[1] that consists of multiple interconnected
>> programs running on a multiprocessing Linux system.
>>
>> In other words, the minimum capability sufficient to be
>> useful would be some sort of checkpointing mechanism.
>>
>> A secondary goal, discussed extensively here, is that it
>> would be nice to be able to copy a session or export a
>> session. This is where all the contentious issues with
>> handling filesystem objects comes up.
>>
>> The latter goal should be optional, IMO, rather than required.
>>
> </snip>
>
> this is exactly what i've been trying to tell (only that my english
> wording leaves a lot to be desired)
>
> thanks Joel :)
>
> the primary goal is already achieved by qtractor on jack-session and
> ladish; the second goal is the one i called "utopian".

As far as I understood, to have everything saved in the session folder 
was designed to make the behavior of the session manager more 
predictable and more simple to avoid errors and misbehavior.
To be able to export the session was *not* the primary choice for this 
(correct me if I am wrong).

>
> speaking from a developer's pov. i find it very unlikely that NSM will
> ever get broader acceptance than jack-session and/or ladish, given the
> "utopian" restrictions it poses on client application design.
>
> i wonder for a while: modifying an application to participate in
> jack-session, for instance, is dead simple and costs only a small amount
> of developer time and effort, provided he/she has the proper motivation ;)
>
> otoh. i have this creepy feeling that, to comply to NSM, one has to
> compromise a lot of the application design and behavior--gui
> restrictions, file location restrictions, osc managing interface, to
> name a few--not that they are bad ideas at all, quite the contrary, but
> they impose a kind of non-negligible (pun intended;) change into
> application workings, unless coded to comply to the NSM-client-logo from
> day zero.

Feelings are important, especially when dealing with something like 
session management which success depends more or less by the adoption by 
others. But I think we need to know the *facts* here. Is it really that 
way as you think it is, or is it just your initial resistance (which one 
can understand) to comply to the strict rules of NSM and isn't it that 
bad when having a closer look at it?
It's a reasonable point to discuss though...

>
> i keep wondering: if that ever flies above its toes then i'll certainly
> call it "The linux-audio revolution" (or miracle, scnr:)
>
> cheers
> --
> rncbc aka Rui Nuno Capela
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev


--===============7742159837109174042==--


From rosea.grammostola@gmail.com Tue Apr  3 09:42:30 2012
From: "rosea.grammostola" <rosea.grammostola@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Tue, 03 Apr 2012 09:42:30 +0000
Message-ID: <4F7AC5E3.8020904@gmail.com>
In-Reply-To: <4F7AC51E.7070507@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6410271970016003504=="

--===============6410271970016003504==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/03/2012 11:38 AM, rosea.grammostola wrote:
> On 04/03/2012 10:05 AM, rncbc wrote:
>> On 03.04.2012 06:49, Joel Roth wrote:
>>> On Thu, Mar 29, 2012 at 03:44:17PM +0200, Emanuel Rumpf wrote:
>>>
>>>> Back to life - back to reality
>>>>
>>>> 1. We start qtractor as part of a session, create some midi-tracks,
>>>> include some external wav-files.
>>>>
>>>> Should the SM "know" about these external files, as I suggested ?
>>>> (Allowing the user to find out basic info about it. )
>>>> Or leave it completely to qtractor ?
>>>
>> <snip>
>>>
>>> As I understand it, the primary motivation for a session
>>> manager is to be able to save and restore the state of an
>>> audio project[1] that consists of multiple interconnected
>>> programs running on a multiprocessing Linux system.
>>>
>>> In other words, the minimum capability sufficient to be
>>> useful would be some sort of checkpointing mechanism.
>>>
>>> A secondary goal, discussed extensively here, is that it
>>> would be nice to be able to copy a session or export a
>>> session. This is where all the contentious issues with
>>> handling filesystem objects comes up.
>>>
>>> The latter goal should be optional, IMO, rather than required.
>>>
>> </snip>
>>
>> this is exactly what i've been trying to tell (only that my english
>> wording leaves a lot to be desired)
>>
>> thanks Joel :)
>>
>> the primary goal is already achieved by qtractor on jack-session and
>> ladish; the second goal is the one i called "utopian".
>
> As far as I understood, to have everything saved in the session folder
> was designed to make the behavior of the session manager more
> predictable and more simple to avoid errors and misbehavior.
> To be able to export the session was *not* the primary choice for this
> (correct me if I am wrong).

* not the primary reason for this choice
>
>>
>> speaking from a developer's pov. i find it very unlikely that NSM will
>> ever get broader acceptance than jack-session and/or ladish, given the
>> "utopian" restrictions it poses on client application design.
>>
>> i wonder for a while: modifying an application to participate in
>> jack-session, for instance, is dead simple and costs only a small amount
>> of developer time and effort, provided he/she has the proper
>> motivation ;)
>>
>> otoh. i have this creepy feeling that, to comply to NSM, one has to
>> compromise a lot of the application design and behavior--gui
>> restrictions, file location restrictions, osc managing interface, to
>> name a few--not that they are bad ideas at all, quite the contrary, but
>> they impose a kind of non-negligible (pun intended;) change into
>> application workings, unless coded to comply to the NSM-client-logo from
>> day zero.
>
> Feelings are important, especially when dealing with something like
> session management which success depends more or less by the adoption by
> others. But I think we need to know the *facts* here. Is it really that
> way as you think it is, or is it just your initial resistance (which one
> can understand) to comply to the strict rules of NSM and isn't it that
> bad when having a closer look at it?
> It's a reasonable point to discuss though...
>
>>
>> i keep wondering: if that ever flies above its toes then i'll certainly
>> call it "The linux-audio revolution" (or miracle, scnr:)
>>
>> cheers
>> --
>> rncbc aka Rui Nuno Capela
>> _______________________________________________
>> Linux-audio-dev mailing list
>> Linux-audio-dev(a)lists.linuxaudio.org
>> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>


--===============6410271970016003504==--


From rncbc@rncbc.org Tue Apr  3 10:55:56 2012
From: rncbc <rncbc@rncbc.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Tue, 03 Apr 2012 10:55:56 +0000
Message-ID: <5e25fdd113b7a6d1b04d4dbf8253787d@rncbc.org>
In-Reply-To: <4F7AC51E.7070507@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2436182833889563463=="

--===============2436182833889563463==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 03.04.2012 10:38, rosea.grammostola wrote:
> On 04/03/2012 10:05 AM, rncbc wrote:
>> On 03.04.2012 06:49, Joel Roth wrote:
>>> On Thu, Mar 29, 2012 at 03:44:17PM +0200, Emanuel Rumpf wrote:
>>>
>>>> Back to life - back to reality
>>>>
>>>> 1. We start qtractor as part of a session, create some 
>>>> midi-tracks,
>>>> include some external wav-files.
>>>>
>>>> Should the SM "know" about these external files, as I suggested ?
>>>> (Allowing the user to find out basic info about it. )
>>>> Or leave it completely to qtractor ?
>>>
>> <snip>
>>>
>>> As I understand it, the primary motivation for a session
>>> manager is to be able to save and restore the state of an
>>> audio project[1] that consists of multiple interconnected
>>> programs running on a multiprocessing Linux system.
>>>
>>> In other words, the minimum capability sufficient to be
>>> useful would be some sort of checkpointing mechanism.
>>>
>>> A secondary goal, discussed extensively here, is that it
>>> would be nice to be able to copy a session or export a
>>> session. This is where all the contentious issues with
>>> handling filesystem objects comes up.
>>>
>>> The latter goal should be optional, IMO, rather than required.
>>>
>> </snip>
>>
>> this is exactly what i've been trying to tell (only that my english
>> wording leaves a lot to be desired)
>>
>> thanks Joel :)
>>
>> the primary goal is already achieved by qtractor on jack-session and
>> ladish; the second goal is the one i called "utopian".
>
> As far as I understood, to have everything saved in the session
> folder was designed to make the behavior of the session manager more
> predictable and more simple to avoid errors and misbehavior.
> To be able to export the session was *not* the primary choice for
> this (correct me if I am wrong).
>

but is this one i complain about. nb. getting the full application 
state saved under one SM session directory is a lot different than 
saving everything an application state refers to under the same SM 
session directory.

i'll gently recall you can actually have sort of both with qtractor 
under jack-session management: you just choose which of qtractor's 
default session file format you want: either the regular xml state file 
(.qtr) or the complete bundle, self-contained archive/zip file (.qtz). 
note that if your files are huge, saving in this latter format might 
just take more time :)

however, please note, that's just a qtractor's user 
preference/convenience option, not mandated by any permanent rule of the 
SM API.

byee
--
rncbc aka Rui Nuno Capela

--===============2436182833889563463==--


From rosea.grammostola@gmail.com Tue Apr  3 12:56:00 2012
From: "rosea.grammostola" <rosea.grammostola@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Tue, 03 Apr 2012 12:56:00 +0000
Message-ID: <4F7AF338.7080605@gmail.com>
In-Reply-To: <5e25fdd113b7a6d1b04d4dbf8253787d@rncbc.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5417853607575598604=="

--===============5417853607575598604==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/03/2012 11:51 AM, rncbc wrote:
> On 03.04.2012 10:38, rosea.grammostola wrote:
>> On 04/03/2012 10:05 AM, rncbc wrote:
>>> On 03.04.2012 06:49, Joel Roth wrote:
>>>> On Thu, Mar 29, 2012 at 03:44:17PM +0200, Emanuel Rumpf wrote:
>>>>
>>>>> Back to life - back to reality
>>>>>
>>>>> 1. We start qtractor as part of a session, create some midi-tracks,
>>>>> include some external wav-files.
>>>>>
>>>>> Should the SM "know" about these external files, as I suggested ?
>>>>> (Allowing the user to find out basic info about it. )
>>>>> Or leave it completely to qtractor ?
>>>>
>>> <snip>
>>>>
>>>> As I understand it, the primary motivation for a session
>>>> manager is to be able to save and restore the state of an
>>>> audio project[1] that consists of multiple interconnected
>>>> programs running on a multiprocessing Linux system.
>>>>
>>>> In other words, the minimum capability sufficient to be
>>>> useful would be some sort of checkpointing mechanism.
>>>>
>>>> A secondary goal, discussed extensively here, is that it
>>>> would be nice to be able to copy a session or export a
>>>> session. This is where all the contentious issues with
>>>> handling filesystem objects comes up.
>>>>
>>>> The latter goal should be optional, IMO, rather than required.
>>>>
>>> </snip>
>>>
>>> this is exactly what i've been trying to tell (only that my english
>>> wording leaves a lot to be desired)
>>>
>>> thanks Joel :)
>>>
>>> the primary goal is already achieved by qtractor on jack-session and
>>> ladish; the second goal is the one i called "utopian".
>>
>> As far as I understood, to have everything saved in the session
>> folder was designed to make the behavior of the session manager more
>> predictable and more simple to avoid errors and misbehavior.
>> To be able to export the session was *not* the primary choice for
>> this (correct me if I am wrong).
>>
>
> but is this one i complain about. nb. getting the full application state
> saved under one SM session directory is a lot different than saving
> everything an application state refers to under the same SM session
> directory.
>
> i'll gently recall you can actually have sort of both with qtractor
> under jack-session management: you just choose which of qtractor's
> default session file format you want: either the regular xml state file
> (.qtr) or the complete bundle, self-contained archive/zip file (.qtz).
> note that if your files are huge, saving in this latter format might
> just take more time :)
>
> however, please note, that's just a qtractor's user
> preference/convenience option, not mandated by any permanent rule of the
> SM API.

But Qtractor seems to be special case here. Jonathan said in this thread 
that there are not many apps with the same behavior when it comes to 
saving and using files/ sessions.

So saying that this isn't ideal for Qtractor-like-applications, doesn't 
say that other developers have problems with the strict saving rules of 
NSM.
(I have the *feeling* that these rules are in general harder to accept 
for developers of big applications like Qtractor, Ardour, Muse etc, then 
it is for small applications. The first have the unconscious urge of 
being in charge I can imagine, but I could be wrong).

However, it might be fair to take a look at how JackSession does this 
and answer the question why it is or why it is not a problem to not have 
these saving restrictions.

Regards,
\r



--===============5417853607575598604==--


From rosea.grammostola@gmail.com Tue Apr  3 13:35:44 2012
From: "rosea.grammostola" <rosea.grammostola@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Tue, 03 Apr 2012 13:35:44 +0000
Message-ID: <4F7AFC8A.4060401@gmail.com>
In-Reply-To: <4F7AF338.7080605@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============9218530948479331562=="

--===============9218530948479331562==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/03/2012 02:55 PM, rosea.grammostola wrote:
> On 04/03/2012 11:51 AM, rncbc wrote:
>> On 03.04.2012 10:38, rosea.grammostola wrote:
>>> On 04/03/2012 10:05 AM, rncbc wrote:
>>>> On 03.04.2012 06:49, Joel Roth wrote:
>>>>> On Thu, Mar 29, 2012 at 03:44:17PM +0200, Emanuel Rumpf wrote:
>>>>>
>>>>>> Back to life - back to reality
>>>>>>
>>>>>> 1. We start qtractor as part of a session, create some midi-tracks,
>>>>>> include some external wav-files.
>>>>>>
>>>>>> Should the SM "know" about these external files, as I suggested ?
>>>>>> (Allowing the user to find out basic info about it. )
>>>>>> Or leave it completely to qtractor ?
>>>>>
>>>> <snip>
>>>>>
>>>>> As I understand it, the primary motivation for a session
>>>>> manager is to be able to save and restore the state of an
>>>>> audio project[1] that consists of multiple interconnected
>>>>> programs running on a multiprocessing Linux system.
>>>>>
>>>>> In other words, the minimum capability sufficient to be
>>>>> useful would be some sort of checkpointing mechanism.
>>>>>
>>>>> A secondary goal, discussed extensively here, is that it
>>>>> would be nice to be able to copy a session or export a
>>>>> session. This is where all the contentious issues with
>>>>> handling filesystem objects comes up.
>>>>>
>>>>> The latter goal should be optional, IMO, rather than required.
>>>>>
>>>> </snip>
>>>>
>>>> this is exactly what i've been trying to tell (only that my english
>>>> wording leaves a lot to be desired)
>>>>
>>>> thanks Joel :)
>>>>
>>>> the primary goal is already achieved by qtractor on jack-session and
>>>> ladish; the second goal is the one i called "utopian".
>>>
>>> As far as I understood, to have everything saved in the session
>>> folder was designed to make the behavior of the session manager more
>>> predictable and more simple to avoid errors and misbehavior.
>>> To be able to export the session was *not* the primary choice for
>>> this (correct me if I am wrong).
>>>
>>
>> but is this one i complain about. nb. getting the full application state
>> saved under one SM session directory is a lot different than saving
>> everything an application state refers to under the same SM session
>> directory.
>>
>> i'll gently recall you can actually have sort of both with qtractor
>> under jack-session management: you just choose which of qtractor's
>> default session file format you want: either the regular xml state file
>> (.qtr) or the complete bundle, self-contained archive/zip file (.qtz).
>> note that if your files are huge, saving in this latter format might
>> just take more time :)
>>
>> however, please note, that's just a qtractor's user
>> preference/convenience option, not mandated by any permanent rule of the
>> SM API.
>
> But Qtractor seems to be special case here. Jonathan said in this thread
> that there are not many apps with the same behavior when it comes to
> saving and using files/ sessions.
>
> So saying that this isn't ideal for Qtractor-like-applications, doesn't
> say that other developers have problems with the strict saving rules of
> NSM.
> (I have the *feeling* that these rules are in general harder to accept
> for developers of big applications like Qtractor, Ardour, Muse etc, then
> it is for small applications. The first have the unconscious urge of
> being in charge I can imagine, but I could be wrong).
>
> However, it might be fair to take a look at how JackSession does this
> and answer the question why it is or why it is not a problem to not have
> these saving restrictions.

When searching for an answer, you find at least two quotes which tell 
you that it is important:

[Quote=Fons]
3. Clearly defining the way an app should behave w.r.t. its
    File menu entries (when managed). This is quite intrusive
    to existing clients, but it is IMHO absolutley essential.
    Kudos to the designer(s) for the having the courage to do
    this instead of allowing application developers to take
    the 'least effort' way (which would of course be better
    marketing, but invite later misery).
[/Quote=Fons]

*Why* this is essential isn't elaborated by Fons though.


[quote=Liles]
Currently one of the strong points of NSM is that applications with 
heavy state (e.g. large audio files) know *exactly* where to put the 
state at the time they join the session. This eliminates the need for 
undesirable hacks with just storing a link to the heavy state (as was 
generally required with LASH). I felt like this was one of the primary 
requirements of Non-DAW which was not addressed by other session managers.
[/quote=Liles]

(Assuming that this ^ is because of the strict opening and saving rules 
of NSM).
Liles compares here with LASH, undesirable hacks are not needed anymore.
Why is this a primary requirement?
Moreover LASH isn't seen as a serious candidate anyway these days. I 
would rather see a comparison with JackSession in this area. In other words:

How JackSession does this and why is it, or why it is not, a problem to 
not have these strict rules for applications which are in a session.


Regards,
\r


--===============9218530948479331562==--


From xbran@web.de Tue Apr  3 13:44:50 2012
From: Emanuel Rumpf <xbran@web.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Tue, 03 Apr 2012 13:44:50 +0000
Message-ID:
 <CAGQuJFKJYDS+s55=-2u=a9eyyZPZt6sf8S+Cc6z0zqZx5zhP1A@mail.gmail.com>
In-Reply-To: <20120403112114.4fdb7d8f@nilsgey.de>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7813849327148101457=="

--===============7813849327148101457==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Am 3. April 2012 09:21 schrieb Nils <list(a)nilsgey.de>:
>
> why don't you write your own Session Manager (Protocol)?
> You seem to be very knowledgable.
>

I did not write a whole sequencer app yet, that's why I don't call
that utopian  ;)
But Riu did.

- I'm not able to do it better than NSM
- we do not need 20 SMs, just one, that does it
- NSM is here already, and is usable and is great

There are many reasons to NOT write a SM, such
as endless discussions on LAD about f..ng details ....

I'm glad, some very brave devs nevertheless did.

-- 
E.R.

--===============7813849327148101457==--


From louigi.verona@gmail.com Tue Apr  3 14:18:29 2012
From: Louigi Verona <louigi.verona@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Tue, 03 Apr 2012 14:18:29 +0000
Message-ID:
 <CADqqn4-U_HG3d13vDcVM+Wn-j4zXA3WMTdn-7nyLK4-iLRQSfA@mail.gmail.com>
In-Reply-To:
 <CAGQuJFKJYDS+s55=-2u=a9eyyZPZt6sf8S+Cc6z0zqZx5zhP1A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8101983166217936817=="

--===============8101983166217936817==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Guys, is there any info on JACK Session state? What apps are supported? How
to use?

-- 
Louigi Verona
http://www.louigiverona.ru/



--===============8101983166217936817==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

R3V5cywgaXMgdGhlcmUgYW55IGluZm8gb24gSkFDSyBTZXNzaW9uIHN0YXRlPyBXaGF0IGFwcHMg
YXJlIHN1cHBvcnRlZD8gSG93IHRvIHVzZT88YnIgY2xlYXI9ImFsbCI+PGJyPi0tIDxicj5Mb3Vp
Z2kgVmVyb25hPGJyPjxhIGhyZWY9Imh0dHA6Ly93d3cubG91aWdpdmVyb25hLnJ1LyI+aHR0cDov
L3d3dy5sb3VpZ2l2ZXJvbmEucnUvPC9hPjxicj4K

--===============8101983166217936817==--


From xbran@web.de Tue Apr  3 14:21:50 2012
From: Emanuel Rumpf <xbran@web.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Tue, 03 Apr 2012 14:21:50 +0000
Message-ID:
 <CAGQuJF+MLDzAOoeKdrd=nHgC8OzooZzPz3yvbausQzmi+6dqSg@mail.gmail.com>
In-Reply-To: <5e25fdd113b7a6d1b04d4dbf8253787d@rncbc.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8571468135419269399=="

--===============8571468135419269399==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Am 3. April 2012 05:49 schrieb Joel Roth <joelz(a)pobox.com>:
> (gaol one)
> As I understand it, the primary motivation for a session
> manager is to be able to save and restore the state of an
> audio project[1] that consists of multiple interconnected
> programs running on a multiprocessing Linux system.
>
> In other words, the minimum capability sufficient to be
> useful would be some sort of checkpointing mechanism.
>
> A secondary goal, discussed extensively here, is that it
> would be nice to be able to copy a session or export a
> session. This is where all the contentious issues with
> handling filesystem objects comes up.


We have two gaols, as Joel told us.

goal 1.  store/restore - is already reached by NSM, if you ask me
goal 2.  archive/copy/duplicate - is the point of this discussion


with goal 1. only

we have a session manager, that can handle projects you are currently
working on,
but if you want to, or have to, transfer the session to a different machine,
if you re-install your system, if you intent to store a sessions data,
if any data has to be moved, then -- your sessions are
very much lost -- as far as I can tell
As an NSM-client, you do what you want with the data, thus
nobody knows, how to automatically or manually fix lost path information,
how to ensure things are stored properly, etc...

with goal 2.

which could - at least to a very basic degree - be reached,
by forcing symlinks, there would be a tiny base, for further improvements
and dedicated helper scripts in the future




-- 
E.R.

--===============8571468135419269399==--


From rosea.grammostola@gmail.com Tue Apr  3 14:22:27 2012
From: "rosea.grammostola" <rosea.grammostola@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Tue, 03 Apr 2012 14:22:27 +0000
Message-ID: <4F7B0773.2070106@gmail.com>
In-Reply-To:
 <CADqqn4-U_HG3d13vDcVM+Wn-j4zXA3WMTdn-7nyLK4-iLRQSfA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6575357900063598413=="

--===============6575357900063598413==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/03/2012 04:18 PM, Louigi Verona wrote:
> Guys, is there any info on JACK Session state? What apps are supported?
> How to use?


http://tangostudio.tuxfamily.org/en/documentations/jacksession

--===============6575357900063598413==--


From rncbc@rncbc.org Tue Apr  3 17:03:50 2012
From: Rui Nuno Capela <rncbc@rncbc.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Tue, 03 Apr 2012 17:03:50 +0000
Message-ID: <4F7B2D95.5030202@rncbc.org>
In-Reply-To: <4F7AF338.7080605@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7838462343605561285=="

--===============7838462343605561285==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/03/2012 01:55 PM, rosea.grammostola wrote:
> On 04/03/2012 11:51 AM, rncbc wrote:
>> On 03.04.2012 10:38, rosea.grammostola wrote:
>>> On 04/03/2012 10:05 AM, rncbc wrote:
>>>> On 03.04.2012 06:49, Joel Roth wrote:
>>>>> On Thu, Mar 29, 2012 at 03:44:17PM +0200, Emanuel Rumpf wrote:
>>>>>
>>>>>> Back to life - back to reality
>>>>>>
>>>>>> 1. We start qtractor as part of a session, create some midi-tracks,
>>>>>> include some external wav-files.
>>>>>>
>>>>>> Should the SM "know" about these external files, as I suggested ?
>>>>>> (Allowing the user to find out basic info about it. )
>>>>>> Or leave it completely to qtractor ?
>>>>>
>>>> <snip>
>>>>>
>>>>> As I understand it, the primary motivation for a session
>>>>> manager is to be able to save and restore the state of an
>>>>> audio project[1] that consists of multiple interconnected
>>>>> programs running on a multiprocessing Linux system.
>>>>>
>>>>> In other words, the minimum capability sufficient to be
>>>>> useful would be some sort of checkpointing mechanism.
>>>>>
>>>>> A secondary goal, discussed extensively here, is that it
>>>>> would be nice to be able to copy a session or export a
>>>>> session. This is where all the contentious issues with
>>>>> handling filesystem objects comes up.
>>>>>
>>>>> The latter goal should be optional, IMO, rather than required.
>>>>>
>>>> </snip>
>>>>
>>>> this is exactly what i've been trying to tell (only that my english
>>>> wording leaves a lot to be desired)
>>>>
>>>> thanks Joel :)
>>>>
>>>> the primary goal is already achieved by qtractor on jack-session and
>>>> ladish; the second goal is the one i called "utopian".
>>>
>>> As far as I understood, to have everything saved in the session
>>> folder was designed to make the behavior of the session manager more
>>> predictable and more simple to avoid errors and misbehavior.
>>> To be able to export the session was *not* the primary choice for
>>> this (correct me if I am wrong).
>>>
>>
>> but is this one i complain about. nb. getting the full application state
>> saved under one SM session directory is a lot different than saving
>> everything an application state refers to under the same SM session
>> directory.
>>
>> i'll gently recall you can actually have sort of both with qtractor
>> under jack-session management: you just choose which of qtractor's
>> default session file format you want: either the regular xml state file
>> (.qtr) or the complete bundle, self-contained archive/zip file (.qtz).
>> note that if your files are huge, saving in this latter format might
>> just take more time :)
>>
>> however, please note, that's just a qtractor's user
>> preference/convenience option, not mandated by any permanent rule of the
>> SM API.
>
> But Qtractor seems to be special case here. Jonathan said in this thread
> that there are not many apps with the same behavior when it comes to
> saving and using files/ sessions.
>
> So saying that this isn't ideal for Qtractor-like-applications, doesn't
> say that other developers have problems with the strict saving rules of
> NSM.
> (I have the *feeling* that these rules are in general harder to accept
> for developers of big applications like Qtractor, Ardour, Muse etc, then
> it is for small applications. The first have the unconscious urge of
> being in charge I can imagine, but I could be wrong).
>

speaking of which

ardour gets all its stuff under one own session directory, on a per 
session/project basis, iirc just like NSM mandates,

bbbuuuuuut...:) making that one and the same directory as from an 
outsider/independent session manager like NSM is asking for a lot of 
file and symlink juggling, if you ask me

i'm not an expert in ardour internals, someone else could chime in and 
help me here.

my feeling again is that the effort to comply with NSM isn't, won't be 
so easy for any lass-than-simple-textbook-like client examples

once again, i call for some ardour expertise. i'm even afraid to ask 
this btw, but does ardour work with jack-session already? o.O

aham

> However, it might be fair to take a look at how JackSession does this
> and answer the question why it is or why it is not a problem to not have
> these saving restrictions.
>

jack-session has some fsck-up restrictions of its own

one that i had historical complaints is about this non-reusable session 
directory restriction (here, the "non" particle, is not a pun;) which 
meant that you can't save into the same session directory twice

a "really-smart/intelligent" SM could copy and re(sym)link all the 
references under each client participant's session sub-directory, yes, a 
chimeric kind of effort comes to mind :o)

alas. this jack-session restriction has been somewhat circumvented by 
the "versioning" feature on qjackctl-as-jack-session-manager, by yours 
truly. yes it's true, but it shows you how cumbersome is like when one 
has to go around and break the red tape of those draconian SM's ;)

and now NSM is about asking for even more and thicker red tape...

cough

now, i could suggest NSM API to be split in levels of compliance and 
restrictiveness, so to speak:

- level 0 :- clients just store/retrieve their own private state from a 
supplied and independent session sub-directory; no GUI File menu 
restrictions; no file location restrictions, no symlinks, no juggling, 
no dupes, no sh*t.

- level 1+ :- anything that (may progressively?) imposes each one the 
mentioned non-restrictions of level 0.

starting with level 0, there's a fair chance for NSM to revolve, and 
even co-exist peacefully with jack-session and ladish. call me a dreamer :)

cheers
-- 
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org

--===============7838462343605561285==--


From malnourite@gmail.com Tue Apr  3 17:17:19 2012
From: "J. Liles" <malnourite@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Tue, 03 Apr 2012 17:17:19 +0000
Message-ID:
 <CAGhWSSbajfxxwT6m9tpn2mYdjmMgWd3BxYOc2RjBD8tjs_w00w@mail.gmail.com>
In-Reply-To: <4F7AFC8A.4060401@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6057942037941344876=="

--===============6057942037941344876==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Tue, Apr 3, 2012 at 6:35 AM, rosea.grammostola
<rosea.grammostola(a)gmail.com> wrote:

> [quote=Liles]
> Currently one of the strong points of NSM is that applications with heavy
> state (e.g. large audio files) know *exactly* where to put the state at the
> time they join the session. This eliminates the need for undesirable hacks
> with just storing a link to the heavy state (as was generally required with
> LASH). I felt like this was one of the primary requirements of Non-DAW which
> was not addressed by other session managers.
> [/quote=Liles]
>
> (Assuming that this ^ is because of the strict opening and saving rules of
> NSM).
> Liles compares here with LASH, undesirable hacks are not needed anymore.
> Why is this a primary requirement?

Because LASH was designed with the assumption that all client
applications would either:

1) Store all their state in memory and be fine with just dumping it to
disk when the save yourself message came.
2) Naturally store their heavy state in some random place (like QTractor?)

Programs with heavy state closely associated to the individual
projects (like Non-DAW and Ardour) had to work around this by just
storing the project data in some random place and only storing a
reference to it in LASH, which was terrible from a consistency
perspective because the user really had no idea where their data was.

I want to have my sessions laid out on disk in a very specific way,
with none of them named after GUIDs, and no applications/data being
(mis)directed to a session just because it happened to be the last one
active.

With NSM (this is part of the server implementation and not the
protocol) the user can lay things out on disk however they like,
organizing their sessions in any way they want (including doing fancy
things with subdirectories and symlinks) *and* have an expectation
that e.g. the audio they record in Non-DAW after adding it as a client
to a session *actually goes into the session directory they defined
when they created the session*. If I want to back up my audio
partition, I should not have to track down gigabytes of data  from
some hidden directory in $HOME that is only referred to inside
incomprehensible XML files as well.

The matter is complicated by applications which have been attempting
to do their own crude form of session management. But here's the key
point: It is only reasonable to expect an application to adhere to
*one* system of session management at a time. So, if the application
is connected to NSM, it should behave in a way consistent with other
NSM capable applications, and if it is connected to XSM, JackSession
or LASH, or what have you it can do whatever those systems allow
(which is totally undefined anyway).

> Moreover LASH isn't seen as a serious candidate anyway these days. I would
> rather see a comparison with JackSession in this area. In other words:
>
> How JackSession does this and why is it, or why it is not, a problem to not
> have these strict rules for applications which are in a session.

I believe JackSession was intended to be the bare minimum required to
transmit a 'save' message to JACK applications... Just a very basic
protocol. Doing anything more to ensure a smooth and consistent user
experience is outside of its scope. A lot of this behavior depends on
the implementation of the Session Manager server itself, but
JackSession by its nature has some basic limitations that exclude the
possibility of the kind of features NSM has, so a server
implementation for it can only do so much...

--===============6057942037941344876==--


From malnourite@gmail.com Tue Apr  3 17:34:02 2012
From: "J. Liles" <malnourite@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Tue, 03 Apr 2012 17:34:02 +0000
Message-ID:
 <CAGhWSSZJR11RcBJ_SYUxk9vjKSkaCp7Wp9WbHAzuYLEWZqTEtg@mail.gmail.com>
In-Reply-To: <4F7B2D95.5030202@rncbc.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8786480478444578953=="

--===============8786480478444578953==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Tue, Apr 3, 2012 at 10:04 AM, Rui Nuno Capela <rncbc(a)rncbc.org> wrote:

>
> jack-session has some fsck-up restrictions of its own
>
> one that i had historical complaints is about this non-reusable session
> directory restriction (here, the "non" particle, is not a pun;) which meant
> that you can't save into the same session directory twice
>
> a "really-smart/intelligent" SM could copy and re(sym)link all the
> references under each client participant's session sub-directory, yes, a
> chimeric kind of effort comes to mind :o)
>
> alas. this jack-session restriction has been somewhat circumvented by the
> "versioning" feature on qjackctl-as-jack-session-**manager, by yours
> truly. yes it's true, but it shows you how cumbersome is like when one has
> to go around and break the red tape of those draconian SM's ;)
>
> and now NSM is about asking for even more and thicker red tape...
>
> cough
>
> now, i could suggest NSM API to be split in levels of compliance and
> restrictiveness, so to speak:
>
> - level 0 :- clients just store/retrieve their own private state from a
> supplied and independent session sub-directory; no GUI File menu
> restrictions; no file location restrictions, no symlinks, no juggling, no
> dupes, no sh*t.
>
> - level 1+ :- anything that (may progressively?) imposes each one the
> mentioned non-restrictions of level 0.
>
> starting with level 0, there's a fair chance for NSM to revolve, and even
> co-exist peacefully with jack-session and ladish. call me a dreamer :)
>
>
Peacefully co-existing at the lowest common denominator of functionality
completely defeats the purpose of trying to improve the integration
experience for *users*. Remember, you only have to change the code once...
People use this stuff every day. If there is a compliance level of 0, then
developers will just pick that (you know it's true) and stop there.

As far as the restrictions imposed by NSM... NSM requires very little of
the application developer. The hardest part is if you want to support the
session 'switch' functionality, and even that is not very difficult (hey,
all the Non-* does it, so that means I had to implement it 4 times... so
why are you complaining when you haven't even tried?)  The requirement that
you *not* do something is a hell of a lot easier to comply with than
requiring that you do something complicated, which is exactly why NSM
*doesn't* require applications to do anything complicated...



--===============8786480478444578953==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PGJyPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gVHVlLCBBcHIgMywgMjAxMiBhdCAx
MDowNCBBTSwgUnVpIE51bm8gQ2FwZWxhIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFp
bHRvOnJuY2JjQHJuY2JjLm9yZyI+cm5jYmNAcm5jYmMub3JnPC9hPiZndDs8L3NwYW4+IHdyb3Rl
Ojxicj4KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAw
IC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRpdiBj
bGFzcz0iaW0iPgo8YnI+PC9kaXY+CmphY2stc2Vzc2lvbiBoYXMgc29tZSBmc2NrLXVwIHJlc3Ry
aWN0aW9ucyBvZiBpdHMgb3duPGJyPgo8YnI+Cm9uZSB0aGF0IGkgaGFkIGhpc3RvcmljYWwgY29t
cGxhaW50cyBpcyBhYm91dCB0aGlzIG5vbi1yZXVzYWJsZSBzZXNzaW9uIGRpcmVjdG9yeSByZXN0
cmljdGlvbiAoaGVyZSwgdGhlICZxdW90O25vbiZxdW90OyBwYXJ0aWNsZSwgaXMgbm90IGEgcHVu
Oykgd2hpY2ggbWVhbnQgdGhhdCB5b3UgY2FuJiMzOTt0IHNhdmUgaW50byB0aGUgc2FtZSBzZXNz
aW9uIGRpcmVjdG9yeSB0d2ljZTxicj4KCjxicj4KYSAmcXVvdDtyZWFsbHktc21hcnQvaW50ZWxs
aWdlbnQmcXVvdDsgU00gY291bGQgY29weSBhbmQgcmUoc3ltKWxpbmsgYWxsIHRoZSByZWZlcmVu
Y2VzIHVuZGVyIGVhY2ggY2xpZW50IHBhcnRpY2lwYW50JiMzOTtzIHNlc3Npb24gc3ViLWRpcmVj
dG9yeSwgeWVzLCBhIGNoaW1lcmljIGtpbmQgb2YgZWZmb3J0IGNvbWVzIHRvIG1pbmQgOm8pPGJy
Pgo8YnI+CmFsYXMuIHRoaXMgamFjay1zZXNzaW9uIHJlc3RyaWN0aW9uIGhhcyBiZWVuIHNvbWV3
aGF0IGNpcmN1bXZlbnRlZCBieSB0aGUgJnF1b3Q7dmVyc2lvbmluZyZxdW90OyBmZWF0dXJlIG9u
IHFqYWNrY3RsLWFzLWphY2stc2Vzc2lvbi08dT48L3U+bWFuYWdlciwgYnkgeW91cnMgdHJ1bHku
IHllcyBpdCYjMzk7cyB0cnVlLCBidXQgaXQgc2hvd3MgeW91IGhvdyBjdW1iZXJzb21lIGlzIGxp
a2Ugd2hlbiBvbmUgaGFzIHRvIGdvIGFyb3VuZCBhbmQgYnJlYWsgdGhlIHJlZCB0YXBlIG9mIHRo
b3NlIGRyYWNvbmlhbiBTTSYjMzk7cyA7KTxicj4KCjxicj4KYW5kIG5vdyBOU00gaXMgYWJvdXQg
YXNraW5nIGZvciBldmVuIG1vcmUgYW5kIHRoaWNrZXIgcmVkIHRhcGUuLi48YnI+Cjxicj4KY291
Z2g8YnI+Cjxicj4Kbm93LCBpIGNvdWxkIHN1Z2dlc3QgTlNNIEFQSSB0byBiZSBzcGxpdCBpbiBs
ZXZlbHMgb2YgY29tcGxpYW5jZSBhbmQgcmVzdHJpY3RpdmVuZXNzLCBzbyB0byBzcGVhazo8YnI+
Cjxicj4KLSBsZXZlbCAwIDotIGNsaWVudHMganVzdCBzdG9yZS9yZXRyaWV2ZSB0aGVpciBvd24g
cHJpdmF0ZSBzdGF0ZSBmcm9tIGEgc3VwcGxpZWQgYW5kIGluZGVwZW5kZW50IHNlc3Npb24gc3Vi
LWRpcmVjdG9yeTsgbm8gR1VJIEZpbGUgbWVudSByZXN0cmljdGlvbnM7IG5vIGZpbGUgbG9jYXRp
b24gcmVzdHJpY3Rpb25zLCBubyBzeW1saW5rcywgbm8ganVnZ2xpbmcsIG5vIGR1cGVzLCBubyBz
aCp0Ljxicj4KCjxicj4KLSBsZXZlbCAxKyA6LSBhbnl0aGluZyB0aGF0IChtYXkgcHJvZ3Jlc3Np
dmVseT8pIGltcG9zZXMgZWFjaCBvbmUgdGhlIG1lbnRpb25lZCBub24tcmVzdHJpY3Rpb25zIG9m
IGxldmVsIDAuPGJyPgo8YnI+CnN0YXJ0aW5nIHdpdGggbGV2ZWwgMCwgdGhlcmUmIzM5O3MgYSBm
YWlyIGNoYW5jZSBmb3IgTlNNIHRvIHJldm9sdmUsIGFuZCBldmVuIGNvLWV4aXN0IHBlYWNlZnVs
bHkgd2l0aCBqYWNrLXNlc3Npb24gYW5kIGxhZGlzaC4gY2FsbCBtZSBhIGRyZWFtZXIgOik8YnI+
Cjxicj4KPC9ibG9ja3F1b3RlPjxkaXY+PGJyPlBlYWNlZnVsbHkgY28tZXhpc3RpbmcgYXQgdGhl
IGxvd2VzdCBjb21tb24gZGVub21pbmF0b3Igb2YgZnVuY3Rpb25hbGl0eSBjb21wbGV0ZWx5IGRl
ZmVhdHMgdGhlIHB1cnBvc2Ugb2YgdHJ5aW5nIHRvIGltcHJvdmUgdGhlIGludGVncmF0aW9uIGV4
cGVyaWVuY2UgZm9yICp1c2VycyouIFJlbWVtYmVyLCB5b3Ugb25seSBoYXZlIHRvIGNoYW5nZSB0
aGUgY29kZSBvbmNlLi4uIFBlb3BsZSB1c2UgdGhpcyBzdHVmZiBldmVyeSBkYXkuIElmIHRoZXJl
IGlzIGEgY29tcGxpYW5jZSBsZXZlbCBvZiAwLCB0aGVuIGRldmVsb3BlcnMgd2lsbCBqdXN0IHBp
Y2sgdGhhdCAoeW91IGtub3cgaXQmIzM5O3MgdHJ1ZSkgYW5kIHN0b3AgdGhlcmUuIDxicj4KPGJy
PkFzIGZhciBhcyB0aGUgcmVzdHJpY3Rpb25zIGltcG9zZWQgYnkgTlNNLi4uIE5TTSByZXF1aXJl
cyB2ZXJ5IGxpdHRsZSBvZiB0aGUgYXBwbGljYXRpb24gZGV2ZWxvcGVyLiBUaGUgaGFyZGVzdCBw
YXJ0IGlzIGlmIHlvdSB3YW50IHRvIHN1cHBvcnQgdGhlIHNlc3Npb24gJiMzOTtzd2l0Y2gmIzM5
OyBmdW5jdGlvbmFsaXR5LCBhbmQgZXZlbiB0aGF0IGlzIG5vdCB2ZXJ5IGRpZmZpY3VsdCAoaGV5
LCBhbGwgdGhlIE5vbi0qIGRvZXMgaXQsIHNvIHRoYXQgbWVhbnMgSSBoYWQgdG8gaW1wbGVtZW50
IGl0IDQgdGltZXMuLi4gc28gd2h5IGFyZSB5b3UgY29tcGxhaW5pbmcgd2hlbiB5b3UgaGF2ZW4m
IzM5O3QgZXZlbiB0cmllZD8pwqAgVGhlIHJlcXVpcmVtZW50IHRoYXQgeW91ICpub3QqIGRvIHNv
bWV0aGluZyBpcyBhIGhlbGwgb2YgYSBsb3QgZWFzaWVyIHRvIGNvbXBseSB3aXRoIHRoYW4gcmVx
dWlyaW5nIHRoYXQgeW91IGRvIHNvbWV0aGluZyBjb21wbGljYXRlZCwgd2hpY2ggaXMgZXhhY3Rs
eSB3aHkgTlNNICpkb2VzbiYjMzk7dCogcmVxdWlyZSBhcHBsaWNhdGlvbnMgdG8gZG8gYW55dGhp
bmcgY29tcGxpY2F0ZWQuLi48YnI+Cjxicj48YnI+PGJyPsKgPC9kaXY+PC9kaXY+Cg==

--===============8786480478444578953==--


From falktx@gmail.com Tue Apr  3 23:24:26 2012
From: Filipe Lopes <falktx@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: [LAD] JACK CV Ports API
Date: Tue, 03 Apr 2012 23:24:26 +0000
Message-ID:
 <CAJ=bptaYaS65gfxwt9qFfSeembbO+Or_tEsLYeY=c4k6ZD3wLw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4884602511334934626=="

--===============4884602511334934626==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

hey lads,
sharing an idea I had here

my (currently in development) host directly exposes plugin ports to jack -
audio as audio, midi as midi, and parameters as a midi port for midi-cc
usage.
while coding for lv2 plugins, I noticed the CV port type, more info here:
http://lv2plug.in/ns/ext/cv-port/

I didn't yet coded support for it, but I'll do soon. Those kind of ports
will be exposed to jack as pure audio ports.
Non-daw and non-mixer also use this kind of ports, and maybe others.
The problem is that users shouldn't connect normal audio and CV ports
together...

so I came up with an idea that is simple and fairly easy to implement - a
new jack port flag.

example:
port = jack_port_register(client, port_name, JACK_DEFAULT_AUDIO_TYPE,
JackPortIsInput|JackPortIsCV, 0);

patchbays can check for this flag and represent the port as a different
type (I've done it here myself as jack keeps any custom port flag values I
set, and works just fine).
in the jack library code we can check for the flag and not allow port
connections.

what do you think?



--===============4884602511334934626==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

aGV5IGxhZHMsPGJyPnNoYXJpbmcgYW4gaWRlYSBJIGhhZCBoZXJlPGJyPjxicj5teSAoY3VycmVu
dGx5IGluIGRldmVsb3BtZW50KSBob3N0IGRpcmVjdGx5IGV4cG9zZXMgcGx1Z2luIHBvcnRzIHRv
IGphY2sgLSBhdWRpbyBhcyBhdWRpbywgbWlkaSBhcyBtaWRpLCBhbmQgcGFyYW1ldGVycyBhcyBh
IG1pZGkgcG9ydCBmb3IgbWlkaS1jYyB1c2FnZS48YnI+d2hpbGUgY29kaW5nIGZvciBsdjIgcGx1
Z2lucywgSSBub3RpY2VkIHRoZSBDViBwb3J0IHR5cGUsIG1vcmUgaW5mbyBoZXJlOjxicj4KPGEg
aHJlZj0iaHR0cDovL2x2MnBsdWcuaW4vbnMvZXh0L2N2LXBvcnQvIj5odHRwOi8vbHYycGx1Zy5p
bi9ucy9leHQvY3YtcG9ydC88L2E+PGJyPjxicj5JIGRpZG4mIzM5O3QgeWV0IGNvZGVkIHN1cHBv
cnQgZm9yIGl0LCBidXQgSSYjMzk7bGwgZG8gc29vbi4gVGhvc2Uga2luZCBvZiBwb3J0cyB3aWxs
IGJlIGV4cG9zZWQgdG8gamFjayBhcyBwdXJlIGF1ZGlvIHBvcnRzLjxicj5Ob24tZGF3IGFuZCBu
b24tbWl4ZXIgYWxzbyB1c2UgdGhpcyBraW5kIG9mIHBvcnRzLCBhbmQgbWF5YmUgb3RoZXJzLjxi
cj4KVGhlIHByb2JsZW0gaXMgdGhhdCB1c2VycyBzaG91bGRuJiMzOTt0IGNvbm5lY3Qgbm9ybWFs
IGF1ZGlvIGFuZCBDViBwb3J0cyB0b2dldGhlci4uLjxicj48YnI+c28gSSBjYW1lIHVwIHdpdGgg
YW4gaWRlYSB0aGF0IGlzIHNpbXBsZSBhbmQgZmFpcmx5IGVhc3kgdG8gaW1wbGVtZW50IC0gYSBu
ZXcgamFjayBwb3J0IGZsYWcuPGJyPjxicj5leGFtcGxlOjxicj5wb3J0ID0gamFja19wb3J0X3Jl
Z2lzdGVyKGNsaWVudCwgcG9ydF9uYW1lLCBKQUNLX0RFRkFVTFRfQVVESU9fVFlQRSwgSmFja1Bv
cnRJc0lucHV0fEphY2tQb3J0SXNDViwgMCk7PGJyPgo8YnI+cGF0Y2hiYXlzIGNhbiBjaGVjayBm
b3IgdGhpcyBmbGFnIGFuZCByZXByZXNlbnQgdGhlIHBvcnQgYXMgYSBkaWZmZXJlbnQgdHlwZSAo
SSYjMzk7dmUgZG9uZSBpdCBoZXJlIG15c2VsZiBhcyBqYWNrIGtlZXBzIGFueSBjdXN0b20gcG9y
dCBmbGFnIHZhbHVlcyBJIHNldCwgYW5kIHdvcmtzIGp1c3QgZmluZSkuPGJyPmluIHRoZSBqYWNr
IGxpYnJhcnkgY29kZSB3ZSBjYW4gY2hlY2sgZm9yIHRoZSBmbGFnIGFuZCBub3QgYWxsb3cgcG9y
dCBjb25uZWN0aW9ucy48YnI+Cjxicj53aGF0IGRvIHlvdSB0aGluaz88YnI+PGJyPgo=

--===============4884602511334934626==--


From d@drobilla.net Wed Apr  4 00:20:36 2012
From: David Robillard <d@drobilla.net>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] JACK CV Ports API
Date: Wed, 04 Apr 2012 00:20:36 +0000
Message-ID: <1333498827.22058.0.camel@verne.drobilla.net>
In-Reply-To:
 <CAJ=bptaYaS65gfxwt9qFfSeembbO+Or_tEsLYeY=c4k6ZD3wLw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6469674484284859540=="

--===============6469674484284859540==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Wed, 2012-04-04 at 00:24 +0100, Filipe Lopes wrote:
> hey lads,
> sharing an idea I had here
> 
> my (currently in development) host directly exposes plugin ports to
> jack - audio as audio, midi as midi, and parameters as a midi port for
> midi-cc usage.
> while coding for lv2 plugins, I noticed the CV port type, more info
> here:
> http://lv2plug.in/ns/ext/cv-port/
> 
> I didn't yet coded support for it, but I'll do soon. Those kind of
> ports will be exposed to jack as pure audio ports.
> Non-daw and non-mixer also use this kind of ports, and maybe others.
> The problem is that users shouldn't connect normal audio and CV ports
> together...
> 
> so I came up with an idea that is simple and fairly easy to implement
> - a new jack port flag.
> 
> example:
> port = jack_port_register(client, port_name, JACK_DEFAULT_AUDIO_TYPE,
> JackPortIsInput|JackPortIsCV, 0);
> 
> patchbays can check for this flag and represent the port as a
> different type (I've done it here myself as jack keeps any custom port
> flag values I set, and works just fine).
> in the jack library code we can check for the flag and not allow port
> connections.
> 
> what do you think?

++

-dr



--===============6469674484284859540==--


From malnourite@gmail.com Wed Apr  4 00:45:05 2012
From: "J. Liles" <malnourite@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] JACK CV Ports API
Date: Wed, 04 Apr 2012 00:45:05 +0000
Message-ID:
 <CAGhWSSazuN16nq-edkEEJ3mNq+QU7-3+KNRhf7arWwvV=yk0qg@mail.gmail.com>
In-Reply-To:
 <CAJ=bptaYaS65gfxwt9qFfSeembbO+Or_tEsLYeY=c4k6ZD3wLw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8439179709126524465=="

--===============8439179709126524465==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Tue, Apr 3, 2012 at 4:24 PM, Filipe Lopes <falktx(a)gmail.com> wrote:

> hey lads,
> sharing an idea I had here
>
> my (currently in development) host directly exposes plugin ports to jack -
> audio as audio, midi as midi, and parameters as a midi port for midi-cc
> usage.
> while coding for lv2 plugins, I noticed the CV port type, more info here:
> http://lv2plug.in/ns/ext/cv-port/
>
> I didn't yet coded support for it, but I'll do soon. Those kind of ports
> will be exposed to jack as pure audio ports.
> Non-daw and non-mixer also use this kind of ports, and maybe others.
> The problem is that users shouldn't connect normal audio and CV ports
> together...
>
> so I came up with an idea that is simple and fairly easy to implement - a
> new jack port flag.
>
> example:
> port = jack_port_register(client, port_name, JACK_DEFAULT_AUDIO_TYPE,
> JackPortIsInput|JackPortIsCV, 0);
>
> patchbays can check for this flag and represent the port as a different
> type (I've done it here myself as jack keeps any custom port flag values I
> set, and works just fine).
> in the jack library code we can check for the flag and not allow port
> connections.
>
> what do you think?
>
>
BTW, SpiralSynthModular is another program that uses JACK audio ports for
CV.

Seems perfectly reasonable to me, although I would rather it be the
connection manager that disallows the connections rather than JACK itself.
Some users may have valid reasons for wanting to force a connection between
Audio and CV ports (such as sending an analog control voltage signal out of
the audio interface)... And consider the case right now for programs which
have not been updated to set the appropriate flag on their CV ports--those
connections would have to be forced until the programs are updated. But
even if the connection manager just used the information to display the
ports in a different color, it would still be useful. Also, obviously you
need a #define or something to indicate that the version of libjack has the
enum for CV ports.

As you point out, it's a very simple change and I think it's about time we
had *something* in place for this and in lieu of arbitrary port types and
data representations, this will certainly work for the CV case.



--===============8439179709126524465==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PGJyPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gVHVlLCBBcHIgMywgMjAxMiBhdCA0
OjI0IFBNLCBGaWxpcGUgTG9wZXMgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86
ZmFsa3R4QGdtYWlsLmNvbSI+ZmFsa3R4QGdtYWlsLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8
YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44
ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+CmhleSBsYWRz
LDxicj5zaGFyaW5nIGFuIGlkZWEgSSBoYWQgaGVyZTxicj48YnI+bXkgKGN1cnJlbnRseSBpbiBk
ZXZlbG9wbWVudCkgaG9zdCBkaXJlY3RseSBleHBvc2VzIHBsdWdpbiBwb3J0cyB0byBqYWNrIC0g
YXVkaW8gYXMgYXVkaW8sIG1pZGkgYXMgbWlkaSwgYW5kIHBhcmFtZXRlcnMgYXMgYSBtaWRpIHBv
cnQgZm9yIG1pZGktY2MgdXNhZ2UuPGJyPndoaWxlIGNvZGluZyBmb3IgbHYyIHBsdWdpbnMsIEkg
bm90aWNlZCB0aGUgQ1YgcG9ydCB0eXBlLCBtb3JlIGluZm8gaGVyZTo8YnI+Cgo8YSBocmVmPSJo
dHRwOi8vbHYycGx1Zy5pbi9ucy9leHQvY3YtcG9ydC8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8v
bHYycGx1Zy5pbi9ucy9leHQvY3YtcG9ydC88L2E+PGJyPjxicj5JIGRpZG4mIzM5O3QgeWV0IGNv
ZGVkIHN1cHBvcnQgZm9yIGl0LCBidXQgSSYjMzk7bGwgZG8gc29vbi4gVGhvc2Uga2luZCBvZiBw
b3J0cyB3aWxsIGJlIGV4cG9zZWQgdG8gamFjayBhcyBwdXJlIGF1ZGlvIHBvcnRzLjxicj4KTm9u
LWRhdyBhbmQgbm9uLW1peGVyIGFsc28gdXNlIHRoaXMga2luZCBvZiBwb3J0cywgYW5kIG1heWJl
IG90aGVycy48YnI+ClRoZSBwcm9ibGVtIGlzIHRoYXQgdXNlcnMgc2hvdWxkbiYjMzk7dCBjb25u
ZWN0IG5vcm1hbCBhdWRpbyBhbmQgQ1YgcG9ydHMgdG9nZXRoZXIuLi48YnI+PGJyPnNvIEkgY2Ft
ZSB1cCB3aXRoIGFuIGlkZWEgdGhhdCBpcyBzaW1wbGUgYW5kIGZhaXJseSBlYXN5IHRvIGltcGxl
bWVudCAtIGEgbmV3IGphY2sgcG9ydCBmbGFnLjxicj48YnI+ZXhhbXBsZTo8YnI+cG9ydCA9IGph
Y2tfcG9ydF9yZWdpc3RlcihjbGllbnQsIHBvcnRfbmFtZSwgSkFDS19ERUZBVUxUX0FVRElPX1RZ
UEUsIEphY2tQb3J0SXNJbnB1dHxKYWNrUG9ydElzQ1YsIDApOzxicj4KCjxicj5wYXRjaGJheXMg
Y2FuIGNoZWNrIGZvciB0aGlzIGZsYWcgYW5kIHJlcHJlc2VudCB0aGUgcG9ydCBhcyBhIGRpZmZl
cmVudCB0eXBlIChJJiMzOTt2ZSBkb25lIGl0IGhlcmUgbXlzZWxmIGFzIGphY2sga2VlcHMgYW55
IGN1c3RvbSBwb3J0IGZsYWcgdmFsdWVzIEkgc2V0LCBhbmQgd29ya3MganVzdCBmaW5lKS48YnI+
aW4gdGhlIGphY2sgbGlicmFyeSBjb2RlIHdlIGNhbiBjaGVjayBmb3IgdGhlIGZsYWcgYW5kIG5v
dCBhbGxvdyBwb3J0IGNvbm5lY3Rpb25zLjxicj4KCjxicj53aGF0IGRvIHlvdSB0aGluaz88YnI+
PGJyPjwvYmxvY2txdW90ZT48ZGl2Pjxicj5CVFcsIFNwaXJhbFN5bnRoTW9kdWxhciBpcyBhbm90
aGVyIHByb2dyYW0gdGhhdCB1c2VzIEpBQ0sgYXVkaW8gcG9ydHMgZm9yIENWLjxicj48YnI+U2Vl
bXMgcGVyZmVjdGx5IHJlYXNvbmFibGUgdG8gbWUsIGFsdGhvdWdoIEkgd291bGQgcmF0aGVyIGl0
IGJlIHRoZSBjb25uZWN0aW9uIG1hbmFnZXIgdGhhdCBkaXNhbGxvd3MgdGhlIGNvbm5lY3Rpb25z
IHJhdGhlciB0aGFuIEpBQ0sgaXRzZWxmLiBTb21lIHVzZXJzIG1heSBoYXZlIHZhbGlkIHJlYXNv
bnMgZm9yIHdhbnRpbmcgdG8gZm9yY2UgYSBjb25uZWN0aW9uIGJldHdlZW4gQXVkaW8gYW5kIENW
IHBvcnRzIChzdWNoIGFzIHNlbmRpbmcgYW4gYW5hbG9nIGNvbnRyb2wgdm9sdGFnZSBzaWduYWwg
b3V0IG9mIHRoZSBhdWRpbyBpbnRlcmZhY2UpLi4uIEFuZCBjb25zaWRlciB0aGUgY2FzZSByaWdo
dCBub3cgZm9yIHByb2dyYW1zIHdoaWNoIGhhdmUgbm90IGJlZW4gdXBkYXRlZCB0byBzZXQgdGhl
IGFwcHJvcHJpYXRlIGZsYWcgb24gdGhlaXIgQ1YgcG9ydHMtLXRob3NlIGNvbm5lY3Rpb25zIHdv
dWxkIGhhdmUgdG8gYmUgZm9yY2VkIHVudGlsIHRoZSBwcm9ncmFtcyBhcmUgdXBkYXRlZC4gQnV0
IGV2ZW4gaWYgdGhlIGNvbm5lY3Rpb24gbWFuYWdlciBqdXN0IHVzZWQgdGhlIGluZm9ybWF0aW9u
IHRvIGRpc3BsYXkgdGhlIHBvcnRzIGluIGEgZGlmZmVyZW50IGNvbG9yLCBpdCB3b3VsZCBzdGls
bCBiZSB1c2VmdWwuIEFsc28sIG9idmlvdXNseSB5b3UgbmVlZCBhICNkZWZpbmUgb3Igc29tZXRo
aW5nIHRvIGluZGljYXRlIHRoYXQgdGhlIHZlcnNpb24gb2YgbGliamFjayBoYXMgdGhlIGVudW0g
Zm9yIENWIHBvcnRzLjxicj4KPGJyPkFzIHlvdSBwb2ludCBvdXQsIGl0JiMzOTtzIGEgdmVyeSBz
aW1wbGUgY2hhbmdlIGFuZCBJIHRoaW5rIGl0JiMzOTtzIGFib3V0IHRpbWUgd2UgaGFkICpzb21l
dGhpbmcqIGluIHBsYWNlIGZvciB0aGlzIGFuZCBpbiBsaWV1IG9mIGFyYml0cmFyeSBwb3J0IHR5
cGVzIGFuZCBkYXRhIHJlcHJlc2VudGF0aW9ucywgdGhpcyB3aWxsIGNlcnRhaW5seSB3b3JrIGZv
ciB0aGUgQ1YgY2FzZS48YnI+Cjxicj7CoDwvZGl2PjwvZGl2Pgo=

--===============8439179709126524465==--


From louigi.verona@gmail.com Wed Apr  4 08:11:54 2012
From: Louigi Verona <louigi.verona@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 04 Apr 2012 08:11:54 +0000
Message-ID:
 <CADqqn4_YXqOQG-0HwkFEgffTH3QqqbBThM-AJTSC9Wt8NNqLgA@mail.gmail.com>
In-Reply-To:
 <CAGhWSSZJR11RcBJ_SYUxk9vjKSkaCp7Wp9WbHAzuYLEWZqTEtg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4919829602988969315=="

--===============4919829602988969315==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Guys, I read about JACK Session, tried it out. It does seem very capable.
And if more apps add support (which, as people say in this discussion, is
not that difficult), wouldn't JACK Session be a good, stable way to restore
sessions? After all, JACK is a basic thing for Linux Audio and adding
support for all its features, including Session, would just become part of
the default routine. Am I missing something here?

-- 
Louigi Verona
http://www.louigiverona.ru/



--===============4919829602988969315==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

R3V5cywgSSByZWFkIGFib3V0IEpBQ0sgU2Vzc2lvbiwgdHJpZWQgaXQgb3V0LiBJdCBkb2VzIHNl
ZW0gdmVyeSBjYXBhYmxlLiBBbmQgaWYgbW9yZSBhcHBzIGFkZCBzdXBwb3J0ICh3aGljaCwgYXMg
cGVvcGxlIHNheSBpbiB0aGlzIGRpc2N1c3Npb24sIGlzIG5vdCB0aGF0IGRpZmZpY3VsdCksIHdv
dWxkbiYjMzk7dCBKQUNLIFNlc3Npb24gYmUgYSBnb29kLCBzdGFibGUgd2F5IHRvIHJlc3RvcmUg
c2Vzc2lvbnM/IEFmdGVyIGFsbCwgSkFDSyBpcyBhIGJhc2ljIHRoaW5nIGZvciBMaW51eCBBdWRp
byBhbmQgYWRkaW5nIHN1cHBvcnQgZm9yIGFsbCBpdHMgZmVhdHVyZXMsIGluY2x1ZGluZyBTZXNz
aW9uLCB3b3VsZCBqdXN0IGJlY29tZSBwYXJ0IG9mIHRoZSBkZWZhdWx0IHJvdXRpbmUuIEFtIEkg
bWlzc2luZyBzb21ldGhpbmcgaGVyZT88YnIgY2xlYXI9ImFsbCI+Cjxicj4tLSA8YnI+TG91aWdp
IFZlcm9uYTxicj48YSBocmVmPSJodHRwOi8vd3d3LmxvdWlnaXZlcm9uYS5ydS8iPmh0dHA6Ly93
d3cubG91aWdpdmVyb25hLnJ1LzwvYT48YnI+Cg==

--===============4919829602988969315==--


From xbran@web.de Wed Apr  4 09:06:04 2012
From: Emanuel Rumpf <xbran@web.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 04 Apr 2012 09:06:04 +0000
Message-ID:
 <CAGQuJFJdS+85iArZ3yUuiGafm1vJpW4W-6O76ozjZSw9GZF+TA@mail.gmail.com>
In-Reply-To:
 <CADqqn4_YXqOQG-0HwkFEgffTH3QqqbBThM-AJTSC9Wt8NNqLgA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3758231721079461458=="

--===============3758231721079461458==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Am 4. April 2012 08:11 schrieb Louigi Verona <louigi.verona(a)gmail.com>:

> Am I missing something here?
>
Yes,
search the archives.
or visit
http://wiki.linuxaudio.org/wiki/user/emrum/jack_session_2_draft
to see,
what NSM tries to improve, by imposing some meaningful rules.

--===============3758231721079461458==--


From rosea.grammostola@gmail.com Wed Apr  4 11:18:45 2012
From: "rosea.grammostola" <rosea.grammostola@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 04 Apr 2012 11:18:45 +0000
Message-ID: <4F7C2DEF.5000504@gmail.com>
In-Reply-To: <4F7B2D95.5030202@rncbc.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0853188366303366265=="

--===============0853188366303366265==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/03/2012 07:04 PM, Rui Nuno Capela wrote:
> now, i could suggest NSM API to be split in levels of compliance and
> restrictiveness, so to speak:
>
> - level 0 :- clients just store/retrieve their own private state from a
> supplied and independent session sub-directory; no GUI File menu
> restrictions; no file location restrictions, no symlinks, no juggling,
> no dupes, no sh*t.
>
> - level 1+ :- anything that (may progressively?) imposes each one the
> mentioned non-restrictions of level 0.

How much more effort will it be in terms of coding, to implement 
'level-1' versus 'level-0'?

\r


--===============0853188366303366265==--


From rncbc@rncbc.org Wed Apr  4 12:22:06 2012
From: Rui Nuno Capela <rncbc@rncbc.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 04 Apr 2012 12:22:06 +0000
Message-ID: <4F7C3D0F.5030206@rncbc.org>
In-Reply-To: <4F7C2DEF.5000504@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1402690984651571795=="

--===============1402690984651571795==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/04/2012 12:18 PM, rosea.grammostola wrote:
> On 04/03/2012 07:04 PM, Rui Nuno Capela wrote:
>> now, i could suggest NSM API to be split in levels of compliance and
>> restrictiveness, so to speak:
>>
>> - level 0 :- clients just store/retrieve their own private state from a
>> supplied and independent session sub-directory; no GUI File menu
>> restrictions; no file location restrictions, no symlinks, no juggling,
>> no dupes, no sh*t.
>>
>> - level 1+ :- anything that (may progressively?) imposes each one the
>> mentioned non-restrictions of level 0.
>
> How much more effort will it be in terms of coding, to implement
> 'level-1' versus 'level-0'?
>

speaking from qtractor pov.:

- level 0: minimal effort as it would be a probable and simple 
rephrasing and/or adaptation of the code already in place for 
jack-session; also, there's this osc branch somewhat lurking in svn to 
get readily merged and apply for the NSM/OSC interface.

- level 1+: pervasive change and effort; almost brand new application 
overhaul (iow. won't happen any time soon:) sorry.

cheers
-- 
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org

--===============1402690984651571795==--


From rosea.grammostola@gmail.com Wed Apr  4 12:36:28 2012
From: "rosea.grammostola" <rosea.grammostola@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 04 Apr 2012 12:36:28 +0000
Message-ID: <4F7C4029.1070503@gmail.com>
In-Reply-To: <4F7C3D0F.5030206@rncbc.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8928398543610406568=="

--===============8928398543610406568==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/04/2012 02:22 PM, Rui Nuno Capela wrote:
> On 04/04/2012 12:18 PM, rosea.grammostola wrote:
>> On 04/03/2012 07:04 PM, Rui Nuno Capela wrote:
>>> now, i could suggest NSM API to be split in levels of compliance and
>>> restrictiveness, so to speak:
>>>
>>> - level 0 :- clients just store/retrieve their own private state from a
>>> supplied and independent session sub-directory; no GUI File menu
>>> restrictions; no file location restrictions, no symlinks, no juggling,
>>> no dupes, no sh*t.
>>>
>>> - level 1+ :- anything that (may progressively?) imposes each one the
>>> mentioned non-restrictions of level 0.
>>
>> How much more effort will it be in terms of coding, to implement
>> 'level-1' versus 'level-0'?
>>
>
> speaking from qtractor pov.:
>
> - level 0: minimal effort as it would be a probable and simple
> rephrasing and/or adaptation of the code already in place for
> jack-session; also, there's this osc branch somewhat lurking in svn to
> get readily merged and apply for the NSM/OSC interface.
>
> - level 1+: pervasive change and effort; almost brand new application
> overhaul (iow. won't happen any time soon:) sorry.

Another question. If you compare NSM level 0 (!) with JackSession. Which 
session manager do you prefer and why?

Regards,
\r

--===============8928398543610406568==--


From xbran@web.de Wed Apr  4 13:25:08 2012
From: Emanuel Rumpf <xbran@web.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 04 Apr 2012 13:25:08 +0000
Message-ID:
 <CAGQuJFKpiWhxVZ1q41v6F-KzXaH7QD=zawJTpwfm--s0s4bnAQ@mail.gmail.com>
In-Reply-To: <4F7C2DEF.5000504@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4389941338431100757=="

--===============4389941338431100757==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Am 4. April 2012 11:18 schrieb rosea.grammostola <rosea.grammostola(a)gmail.c=
om>:
>
> How much more effort will it be in terms of coding, to implement 'level-1'
> versus 'level-0'?
>

For anyone who prefers to work with "apps-do-whatever-they-want" appraoch
or "we-have-zero-to-X-support-levels-so-you-dont-know-what-to-expect" ,
there are alternatives: JackSession, Lash, Ladish.

I would prefere at least *one* SM to have a clean and handy solution
and hope that is NSM.

I have to dig deeper into the NSM-API myself,
but currently it's not obvious to me,
why disabling a few menu-items and using
symlinks in the session-dir. is recognized as
impregnable obstacle.

--=20
E.R.

--===============4389941338431100757==--


From fons@linuxaudio.org Wed Apr  4 13:51:21 2012
From: Fons Adriaensen <fons@linuxaudio.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 04 Apr 2012 13:51:21 +0000
Message-ID: <20120404135120.GA28917@linuxaudio.org>
In-Reply-To:
 <CAGQuJFKpiWhxVZ1q41v6F-KzXaH7QD=zawJTpwfm--s0s4bnAQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1099117548432333369=="

--===============1099117548432333369==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Wed, Apr 04, 2012 at 01:25:02PM +0000, Emanuel Rumpf wrote:
 
> For anyone who prefers to work with "apps-do-whatever-they-want" appraoch
> or "we-have-zero-to-X-support-levels-so-you-dont-know-what-to-expect" ,
> there are alternatives: JackSession, Lash, Ladish.
> 
> I would prefere at least *one* SM to have a clean and handy solution

votes++

> and hope that is NSM.
 
> I have to dig deeper into the NSM-API myself,
> but currently it's not obvious to me,
> why disabling a few menu-items and using
> symlinks in the session-dir. is recognized as
> impregnable obstacle.

I fail to see that as well. And I may be an unrecoverable 
individualist, but if ever I add session management to any
app then that app will obey the NSM rules or very similar
ones if the session manager is not NSM - it is the obvious
thing to do if you want something that works. 

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)


--===============1099117548432333369==--


From rosea.grammostola@gmail.com Wed Apr  4 14:38:38 2012
From: "rosea.grammostola" <rosea.grammostola@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 04 Apr 2012 14:38:38 +0000
Message-ID: <4F7C5CC7.5080006@gmail.com>
In-Reply-To: <20120404135120.GA28917@linuxaudio.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3523565812286334006=="

--===============3523565812286334006==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/04/2012 03:51 PM, Fons Adriaensen wrote:
> if ever I add session management to any
> app then that app will obey the NSM rules or very similar
> ones if the session manager is not NSM - it is the obvious
> thing to do if you want something that works.

Could you elaborate your reasons for this, for those who don't see this 
as obvious?

Regards,
\r

--===============3523565812286334006==--


From rncbc@rncbc.org Wed Apr  4 14:38:41 2012
From: Rui Nuno Capela <rncbc@rncbc.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 04 Apr 2012 14:38:41 +0000
Message-ID: <4F7C5D0A.1000607@rncbc.org>
In-Reply-To: <4F7C4029.1070503@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7997604445034293001=="

--===============7997604445034293001==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/04/2012 01:35 PM, rosea.grammostola wrote:
> On 04/04/2012 02:22 PM, Rui Nuno Capela wrote:
>> On 04/04/2012 12:18 PM, rosea.grammostola wrote:
>>> On 04/03/2012 07:04 PM, Rui Nuno Capela wrote:
>>>> now, i could suggest NSM API to be split in levels of compliance and
>>>> restrictiveness, so to speak:
>>>>
>>>> - level 0 :- clients just store/retrieve their own private state from a
>>>> supplied and independent session sub-directory; no GUI File menu
>>>> restrictions; no file location restrictions, no symlinks, no juggling,
>>>> no dupes, no sh*t.
>>>>
>>>> - level 1+ :- anything that (may progressively?) imposes each one the
>>>> mentioned non-restrictions of level 0.
>>>
>>> How much more effort will it be in terms of coding, to implement
>>> 'level-1' versus 'level-0'?
>>>
>>
>> speaking from qtractor pov.:
>>
>> - level 0: minimal effort as it would be a probable and simple
>> rephrasing and/or adaptation of the code already in place for
>> jack-session; also, there's this osc branch somewhat lurking in svn to
>> get readily merged and apply for the NSM/OSC interface.
>>
>> - level 1+: pervasive change and effort; almost brand new application
>> overhaul (iow. won't happen any time soon:) sorry.
>
> Another question. If you compare NSM level 0 (!) with JackSession. Which
> session manager do you prefer and why?
>

well, NSM level 0 adds nothing to what JSM already delivers. sorry for 
the noise :)

the once self-called "uber-procrastinator" says: prefer what is already 
there and "de-facto" working.

of course it's a biased opinion

nuff said :)
-- 
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org

--===============7997604445034293001==--


From rosea.grammostola@gmail.com Wed Apr  4 14:56:05 2012
From: "rosea.grammostola" <rosea.grammostola@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 04 Apr 2012 14:56:05 +0000
Message-ID: <4F7C60DF.9040709@gmail.com>
In-Reply-To: <4F7C5D0A.1000607@rncbc.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6393547062518477125=="

--===============6393547062518477125==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/04/2012 04:39 PM, Rui Nuno Capela wrote:
>>
>> Another question. If you compare NSM level 0 (!) with JackSession. Which
>> session manager do you prefer and why?
>>
>
> well, NSM level 0 adds nothing to what JSM already delivers. sorry for
> the noise :)
>
> the once self-called "uber-procrastinator" says: prefer what is already
> there and "de-facto" working.

Your opinion is clear, but your arguments are not strictly correct I think.
You say that a hypothetical NSM level 0, adds nothing to what JS 
delivers, but that's not true.

When I want to save a session in JS, I have to make a new folder. If I 
want to save a slightly changed session, I have to make a new folder or 
choose a existent folder. If I do the latter, the gui ask me if I really 
want to overwrite it. I choose 'yes'. (This is what you could call 
pretty cumbersome). In one case, someone did choose the /home/user 
folder... and lost all his data. Ok, you've versioning now in 
qjackctl... There is no way in Qjackctl to add apps without JS support 
to the session. It is not possible to quit a session without saving it, 
so I have to close every application manually.

In NSM on the other hand. I make a new session, add and remove apps on 
the fly from a nice centralized and quick GUI interface. It's even easy 
to add apps without NSM support (or scripts) via the GUI. If I change a 
session, I'm just able to save it without making a new folder or 
overwrite it. I am able to close a whole session and to abort a whole 
session (without saving). As a user can expect, all apps in the session 
close. Moreover it's possible to duplicate a session as a manner of 
using templates. It's very easy and fast to change between sessions. I 
am able to use session over the network very easily. I have never the 
risk of overwriting my precious data. I' m able to add applications 
without JACK support to NSM (Frescobaldi notation-editor, Emacs with 
SuperCollder etc.).

If you say that NSM adds nothing then a) you didn't try it and don't 
really know where you're talking about or b) don't think that the NSM 
stuff mentioned above are valuable of any kind for a user.

Regards,
\r

If

--===============6393547062518477125==--


From rosea.grammostola@gmail.com Wed Apr  4 15:20:49 2012
From: "rosea.grammostola" <rosea.grammostola@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 04 Apr 2012 15:20:49 +0000
Message-ID: <4F7C66A8.1090101@gmail.com>
In-Reply-To: <4F7C60DF.9040709@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7214229413835180843=="

--===============7214229413835180843==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/04/2012 04:55 PM, rosea.grammostola wrote:
> On 04/04/2012 04:39 PM, Rui Nuno Capela wrote:
>>>
>>> Another question. If you compare NSM level 0 (!) with JackSession. Which
>>> session manager do you prefer and why?
>>>
>>
>> well, NSM level 0 adds nothing to what JSM already delivers. sorry for
>> the noise :)
>>
>> the once self-called "uber-procrastinator" says: prefer what is already
>> there and "de-facto" working.
>
> Your opinion is clear, but your arguments are not strictly correct I think.
> You say that a hypothetical NSM level 0, adds nothing to what JS
> delivers, but that's not true.
>
> When I want to save a session in JS, I have to make a new folder. If I
> want to save a slightly changed session, I have to make a new folder or
> choose a existent folder. If I do the latter, the gui ask me if I really
> want to overwrite it. I choose 'yes'. (This is what you could call
> pretty cumbersome).

I'm not sure if this is cumbersomeness of Qjackctl as a GUI for 
JackSession or JackSession itself. I'm not sure how this works in 
Pyjacksm (which is a pretty limited GUI and not in active development).


  In one case, someone did choose the /home/user
> folder... and lost all his data. Ok, you've versioning now in
> qjackctl... There is no way in Qjackctl to add apps without JS support
> to the session. It is not possible to quit a session without saving it,
> so I have to close every application manually.
>
> In NSM on the other hand. I make a new session, add and remove apps on
> the fly from a nice centralized and quick GUI interface. It's even easy
> to add apps without NSM support (or scripts) via the GUI.

Btw this should in theory also be possible with JS I think. Someone 
could write a GUI possibly that is also capable of starting applications 
from it. Moreover JS can make use of "infra clients", (an alpha version 
of) pyjacksm supports this via a configuration file, .pyjacksmrc
Which looks like this, for example:

[DEFAULT]
sessiondir = ~/linuxaudio/JacksmpySession
[infra]
a2j = a2jmidid -e
jkmeter = jkmeter

Then it should be possible to add applications without JS support or 
without a 'state to save' to the JackSession.

BUT, this is *not* implemented in Qjackctl.
Pyjacksm sessions are *not* exchangeable with qjackctl
http://tangostudio.tuxfamily.org/en/documentations/jacksession


If I change a
> session, I'm just able to save it without making a new folder or
> overwrite it. I am able to close a whole session and to abort a whole
> session (without saving). As a user can expect, all apps in the session
> close. Moreover it's possible to duplicate a session as a manner of
> using templates. It's very easy and fast to change between sessions. I
> am able to use session over the network very easily. I have never the
> risk of overwriting my precious data. I' m able to add applications
> without JACK support to NSM (Frescobaldi notation-editor, Emacs with
> SuperCollder etc.).
>
> If you say that NSM adds nothing then a) you didn't try it and don't
> really know where you're talking about or b) don't think that the NSM
> stuff mentioned above are valuable of any kind for a user.
>
> Regards,
> \r
>
> If


--===============7214229413835180843==--


From rncbc@rncbc.org Wed Apr  4 15:46:08 2012
From: Rui Nuno Capela <rncbc@rncbc.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 04 Apr 2012 15:46:08 +0000
Message-ID: <4F7C6CDF.6060107@rncbc.org>
In-Reply-To: <4F7C60DF.9040709@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6928572996351591266=="

--===============6928572996351591266==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/04/2012 03:55 PM, rosea.grammostola wrote:
> On 04/04/2012 04:39 PM, Rui Nuno Capela wrote:
>>>
>>> Another question. If you compare NSM level 0 (!) with JackSession. Which
>>> session manager do you prefer and why?
>>>
>>
>> well, NSM level 0 adds nothing to what JSM already delivers. sorry for
>> the noise :)
>>
>> the once self-called "uber-procrastinator" says: prefer what is already
>> there and "de-facto" working.
>
> Your opinion is clear, but your arguments are not strictly correct I think.
> You say that a hypothetical NSM level 0, adds nothing to what JS
> delivers, but that's not true.
>
> When I want to save a session in JS, I have to make a new folder. If I
> want to save a slightly changed session, I have to make a new folder or
> choose a existent folder. If I do the latter, the gui ask me if I really
> want to overwrite it. I choose 'yes'. (This is what you could call
> pretty cumbersome). In one case, someone did choose the /home/user
> folder... and lost all his data. Ok, you've versioning now in
> qjackctl... There is no way in Qjackctl to add apps without JS support
> to the session. It is not possible to quit a session without saving it,
> so I have to close every application manually.
>
> In NSM on the other hand. I make a new session, add and remove apps on
> the fly from a nice centralized and quick GUI interface. It's even easy
> to add apps without NSM support (or scripts) via the GUI. If I change a
> session, I'm just able to save it without making a new folder or
> overwrite it. I am able to close a whole session and to abort a whole
> session (without saving). As a user can expect, all apps in the session
> close. Moreover it's possible to duplicate a session as a manner of
> using templates. It's very easy and fast to change between sessions. I
> am able to use session over the network very easily. I have never the
> risk of overwriting my precious data. I' m able to add applications
> without JACK support to NSM (Frescobaldi notation-editor, Emacs with
> SuperCollder etc.).
>
> If you say that NSM adds nothing then a) you didn't try it and don't
> really know where you're talking about or b) don't think that the NSM
> stuff mentioned above are valuable of any kind for a user.
>

i may have missed it, but those application clients which are NOT coded 
as compliant to a session protocol are not the point--that's just a SM 
implementation convenience outside of the bounds of the "ideal-SM" 
discussion

i'll refresh your memory that pyjacksm (a JSM reference implementation) 
does that too (something called exo-clients or wtf:). ladish have been 
doing that also and way, way before, for ages now o.O

unfortunately, i reckon, qjackctl doesn't. on my own call it has been 
pure&strict to the JS business (aka. protocol) and nothing more.

however, re. exo-/infra-clients (or w/e they've been called, i don't 
quite remember exactly but those are about clients which are 
non-jack-session-aware) are in the drawer ntl.

actually, i was minding about the *intrinsic* cost/benefits of the 
session protocol and *not* about *any* particular *session management* 
(SM) implementation

got that?
-- 
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org

--===============6928572996351591266==--


From gerald.mwangi@gmx.de Wed Apr  4 15:55:47 2012
From: Gerald Mwangi <gerald.mwangi@gmx.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: [LAD] What 16chan sound card
Date: Wed, 04 Apr 2012 15:55:47 +0000
Message-ID: <1333554940.5783.8.camel@zickzack-laptop>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4490140181708281800=="

--===============4490140181708281800==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Hi guys,
I want to buy a usb sound card with the following specs:
16 input channels :
    at least 8 Mic ins, 
    the rest line ins, intrument ins or ADAT ins (optical)
    no spdif

output channels:
    8 would be nice but not a must

price: 300-350 €

I have these on my list:
http://www.thomann.de/de/256918tascam_us1800.htm (has no ADAT, but only
spdif)

http://www.thomann.de/de/phonic_firefly_808_retour.htm (unkown
manufacturer, at least to me)

Can someone tell how good these do with jack/linux,or maybe show another
option.
Thanx, 
Gerald




--===============4490140181708281800==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUUkFOU0lUSU9OQUwv
L0VOIj4KPEhUTUw+CjxIRUFEPgogIDxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09O
VEVOVD0idGV4dC9odG1sOyBDSEFSU0VUPVVURi04Ij4KICA8TUVUQSBOQU1FPSJHRU5FUkFUT1Ii
IENPTlRFTlQ9Ikd0a0hUTUwvNC4xLjkyIj4KPC9IRUFEPgo8Qk9EWT4KSGkgZ3V5cyw8QlI+Ckkg
d2FudCB0byBidXkgYSB1c2Igc291bmQgY2FyZCB3aXRoIHRoZSBmb2xsb3dpbmcgc3BlY3M6PEJS
PgoxNiBpbnB1dCBjaGFubmVscyA6PEJSPgombmJzcDsmbmJzcDsmbmJzcDsgYXQgbGVhc3QgOCBN
aWMgaW5zLCA8QlI+CiZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgcmVzdCBsaW5lIGlucywgaW50cnVt
ZW50IGlucyBvciBBREFUIGlucyAob3B0aWNhbCk8QlI+CiZuYnNwOyZuYnNwOyZuYnNwOyBubyBz
cGRpZjxCUj4KPEJSPgpvdXRwdXQgY2hhbm5lbHM6PEJSPgombmJzcDsmbmJzcDsmbmJzcDsgOCB3
b3VsZCBiZSBuaWNlIGJ1dCBub3QgYSBtdXN0PEJSPgo8QlI+CnByaWNlOiAzMDAtMzUwICYjODM2
NDs8QlI+CjxCUj4KSSBoYXZlIHRoZXNlIG9uIG15IGxpc3Q6PEJSPgo8QSBIUkVGPSJodHRwOi8v
d3d3LnRob21hbm4uZGUvZGUvMjU2OTE4dGFzY2FtX3VzMTgwMC5odG0iPmh0dHA6Ly93d3cudGhv
bWFubi5kZS9kZS8yNTY5MTh0YXNjYW1fdXMxODAwLmh0bTwvQT4gKGhhcyBubyBBREFULCBidXQg
b25seSBzcGRpZik8QlI+CjxCUj4KPEEgSFJFRj0iaHR0cDovL3d3dy50aG9tYW5uLmRlL2RlL3Bo
b25pY19maXJlZmx5XzgwOF9yZXRvdXIuaHRtIj5odHRwOi8vd3d3LnRob21hbm4uZGUvZGUvcGhv
bmljX2ZpcmVmbHlfODA4X3JldG91ci5odG08L0E+ICh1bmtvd24gbWFudWZhY3R1cmVyLCBhdCBs
ZWFzdCB0byBtZSk8QlI+CjxCUj4KQ2FuIHNvbWVvbmUgdGVsbCBob3cgZ29vZCB0aGVzZSBkbyB3
aXRoIGphY2svbGludXgsb3IgbWF5YmUgc2hvdyBhbm90aGVyIG9wdGlvbi48QlI+ClRoYW54LCA8
QlI+CkdlcmFsZDxCUj4KPEJSPgo8L0JPRFk+CjwvSFRNTD4K

--===============4490140181708281800==--


From malnourite@gmail.com Wed Apr  4 16:19:59 2012
From: "J. Liles" <malnourite@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 04 Apr 2012 16:19:59 +0000
Message-ID:
 <CAGhWSSatjpG5xzGCSM6Tg9AFgJRps7Z-1j9h8iD67mt5vs6gmw@mail.gmail.com>
In-Reply-To: <4F7C3D0F.5030206@rncbc.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0643702542384634160=="

--===============0643702542384634160==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Wed, Apr 4, 2012 at 5:22 AM, Rui Nuno Capela <rncbc(a)rncbc.org> wrote:

> On 04/04/2012 12:18 PM, rosea.grammostola wrote:
>
>> On 04/03/2012 07:04 PM, Rui Nuno Capela wrote:
>>
>>> now, i could suggest NSM API to be split in levels of compliance and
>>> restrictiveness, so to speak:
>>>
>>> - level 0 :- clients just store/retrieve their own private state from a
>>> supplied and independent session sub-directory; no GUI File menu
>>> restrictions; no file location restrictions, no symlinks, no juggling,
>>> no dupes, no sh*t.
>>>
>>> - level 1+ :- anything that (may progressively?) imposes each one the
>>> mentioned non-restrictions of level 0.
>>>
>>
>> How much more effort will it be in terms of coding, to implement
>> 'level-1' versus 'level-0'?
>>
>>
> speaking from qtractor pov.:
>
> - level 0: minimal effort as it would be a probable and simple rephrasing
> and/or adaptation of the code already in place for jack-session; also,
> there's this osc branch somewhat lurking in svn to get readily merged and
> apply for the NSM/OSC interface.
>
> - level 1+: pervasive change and effort; almost brand new application
> overhaul (iow. won't happen any time soon:) sorry.
>

Are you seriously saying that the equivalent of doing:

if ( nsm_is_active )
      save_here( file );
else
      save_there( file );

Would require a complete rewrite and overhaul of your application? Say you
don't want to do it... That's fine. Say you don't like the NSM
design--that's fine too. But don't just make up wild hyperbole out of
laziness...



--===============0643702542384634160==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PGJyPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gV2VkLCBBcHIgNCwgMjAxMiBhdCA1
OjIyIEFNLCBSdWkgTnVubyBDYXBlbGEgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWls
dG86cm5jYmNAcm5jYmMub3JnIj5ybmNiY0BybmNiYy5vcmc8L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6
PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAu
OGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPgo8ZGl2IGNs
YXNzPSJpbSI+T24gMDQvMDQvMjAxMiAxMjoxOCBQTSwgcm9zZWEuZ3JhbW1vc3RvbGEgd3JvdGU6
PGJyPgo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAg
LjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4KT24gMDQv
MDMvMjAxMiAwNzowNCBQTSwgUnVpIE51bm8gQ2FwZWxhIHdyb3RlOjxicj4KPGJsb2NrcXVvdGUg
Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6
MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+Cm5vdywgaSBjb3VsZCBzdWdnZXN0IE5T
TSBBUEkgdG8gYmUgc3BsaXQgaW4gbGV2ZWxzIG9mIGNvbXBsaWFuY2UgYW5kPGJyPgpyZXN0cmlj
dGl2ZW5lc3MsIHNvIHRvIHNwZWFrOjxicj4KPGJyPgotIGxldmVsIDAgOi0gY2xpZW50cyBqdXN0
IHN0b3JlL3JldHJpZXZlIHRoZWlyIG93biBwcml2YXRlIHN0YXRlIGZyb20gYTxicj4Kc3VwcGxp
ZWQgYW5kIGluZGVwZW5kZW50IHNlc3Npb24gc3ViLWRpcmVjdG9yeTsgbm8gR1VJIEZpbGUgbWVu
dTxicj4KcmVzdHJpY3Rpb25zOyBubyBmaWxlIGxvY2F0aW9uIHJlc3RyaWN0aW9ucywgbm8gc3lt
bGlua3MsIG5vIGp1Z2dsaW5nLDxicj4Kbm8gZHVwZXMsIG5vIHNoKnQuPGJyPgo8YnI+Ci0gbGV2
ZWwgMSsgOi0gYW55dGhpbmcgdGhhdCAobWF5IHByb2dyZXNzaXZlbHk/KSBpbXBvc2VzIGVhY2gg
b25lIHRoZTxicj4KbWVudGlvbmVkIG5vbi1yZXN0cmljdGlvbnMgb2YgbGV2ZWwgMC48YnI+Cjwv
YmxvY2txdW90ZT4KPGJyPgpIb3cgbXVjaCBtb3JlIGVmZm9ydCB3aWxsIGl0IGJlIGluIHRlcm1z
IG9mIGNvZGluZywgdG8gaW1wbGVtZW50PGJyPgomIzM5O2xldmVsLTEmIzM5OyB2ZXJzdXMgJiMz
OTtsZXZlbC0wJiMzOTs/PGJyPgo8YnI+CjwvYmxvY2txdW90ZT4KPGJyPjwvZGl2PgpzcGVha2lu
ZyBmcm9tIHF0cmFjdG9yIHBvdi46PGJyPgo8YnI+Ci0gbGV2ZWwgMDogbWluaW1hbCBlZmZvcnQg
YXMgaXQgd291bGQgYmUgYSBwcm9iYWJsZSBhbmQgc2ltcGxlIHJlcGhyYXNpbmcgYW5kL29yIGFk
YXB0YXRpb24gb2YgdGhlIGNvZGUgYWxyZWFkeSBpbiBwbGFjZSBmb3IgamFjay1zZXNzaW9uOyBh
bHNvLCB0aGVyZSYjMzk7cyB0aGlzIG9zYyBicmFuY2ggc29tZXdoYXQgbHVya2luZyBpbiBzdm4g
dG8gZ2V0IHJlYWRpbHkgbWVyZ2VkIGFuZCBhcHBseSBmb3IgdGhlIE5TTS9PU0MgaW50ZXJmYWNl
Ljxicj4KCjxicj4KLSBsZXZlbCAxKzogcGVydmFzaXZlIGNoYW5nZSBhbmQgZWZmb3J0OyBhbG1v
c3QgYnJhbmQgbmV3IGFwcGxpY2F0aW9uIG92ZXJoYXVsIChpb3cuIHdvbiYjMzk7dCBoYXBwZW4g
YW55IHRpbWUgc29vbjopIHNvcnJ5LjxkaXYgY2xhc3M9ImltIEhPRW5aYiI+PC9kaXY+PC9ibG9j
a3F1b3RlPjwvZGl2Pjxicj5BcmUgeW91IHNlcmlvdXNseSBzYXlpbmcgdGhhdCB0aGUgZXF1aXZh
bGVudCBvZiBkb2luZzo8YnI+Cjxicj5pZiAoIG5zbV9pc19hY3RpdmUgKTxicj7CoMKgwqDCoMKg
IHNhdmVfaGVyZSggZmlsZSApOzxicj5lbHNlPGJyPsKgwqDCoMKgwqAgc2F2ZV90aGVyZSggZmls
ZSApOzxicj48YnI+V291bGQgcmVxdWlyZSBhIGNvbXBsZXRlIHJld3JpdGUgYW5kIG92ZXJoYXVs
IG9mIHlvdXIgYXBwbGljYXRpb24/IFNheSB5b3UgZG9uJiMzOTt0IHdhbnQgdG8gZG8gaXQuLi4g
VGhhdCYjMzk7cyBmaW5lLiBTYXkgeW91IGRvbiYjMzk7dCBsaWtlIHRoZSBOU00gZGVzaWduLS10
aGF0JiMzOTtzIGZpbmUgdG9vLiBCdXQgZG9uJiMzOTt0IGp1c3QgbWFrZSB1cCB3aWxkIGh5cGVy
Ym9sZSBvdXQgb2YgbGF6aW5lc3MuLi48YnI+Cjxicj48YnI+PGJyPjxicj4K

--===============0643702542384634160==--


From rosea.grammostola@gmail.com Wed Apr  4 16:20:30 2012
From: "rosea.grammostola" <rosea.grammostola@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 04 Apr 2012 16:20:30 +0000
Message-ID: <4F7C74AA.7020902@gmail.com>
In-Reply-To: <4F7C6CDF.6060107@rncbc.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6758989176100766531=="

--===============6758989176100766531==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/04/2012 05:46 PM, Rui Nuno Capela wrote:
> On 04/04/2012 03:55 PM, rosea.grammostola wrote:
>> On 04/04/2012 04:39 PM, Rui Nuno Capela wrote:
>>>>
>>>> Another question. If you compare NSM level 0 (!) with JackSession.
>>>> Which
>>>> session manager do you prefer and why?
>>>>
>>>
>>> well, NSM level 0 adds nothing to what JSM already delivers. sorry for
>>> the noise :)
>>>
>>> the once self-called "uber-procrastinator" says: prefer what is already
>>> there and "de-facto" working.
>>
>> Your opinion is clear, but your arguments are not strictly correct I
>> think.
>> You say that a hypothetical NSM level 0, adds nothing to what JS
>> delivers, but that's not true.
>>
>> When I want to save a session in JS, I have to make a new folder. If I
>> want to save a slightly changed session, I have to make a new folder or
>> choose a existent folder. If I do the latter, the gui ask me if I really
>> want to overwrite it. I choose 'yes'. (This is what you could call
>> pretty cumbersome). In one case, someone did choose the /home/user
>> folder... and lost all his data. Ok, you've versioning now in
>> qjackctl... There is no way in Qjackctl to add apps without JS support
>> to the session. It is not possible to quit a session without saving it,
>> so I have to close every application manually.
>>
>> In NSM on the other hand. I make a new session, add and remove apps on
>> the fly from a nice centralized and quick GUI interface. It's even easy
>> to add apps without NSM support (or scripts) via the GUI. If I change a
>> session, I'm just able to save it without making a new folder or
>> overwrite it. I am able to close a whole session and to abort a whole
>> session (without saving). As a user can expect, all apps in the session
>> close. Moreover it's possible to duplicate a session as a manner of
>> using templates. It's very easy and fast to change between sessions. I
>> am able to use session over the network very easily. I have never the
>> risk of overwriting my precious data. I' m able to add applications
>> without JACK support to NSM (Frescobaldi notation-editor, Emacs with
>> SuperCollder etc.).
>>
>> If you say that NSM adds nothing then a) you didn't try it and don't
>> really know where you're talking about or b) don't think that the NSM
>> stuff mentioned above are valuable of any kind for a user.
>>
>
> i may have missed it, but those application clients which are NOT coded
> as compliant to a session protocol are not the point--that's just a SM
> implementation convenience outside of the bounds of the "ideal-SM"
> discussion
>
> i'll refresh your memory that pyjacksm (a JSM reference implementation)
> does that too (something called exo-clients or wtf:). ladish have been
> doing that also and way, way before, for ages now o.O
>
> unfortunately, i reckon, qjackctl doesn't. on my own call it has been
> pure&strict to the JS business (aka. protocol) and nothing more.
That's probably the most essential part on LAD to discuss indeed, the 
session protocol. But that doesn't take away that for a user these are 
essential components. The user is looking at how an (SM) application is 
presented on his Desktop, the *end-product*. And because of the fact 
that also the LAU'er knows that it is 'utopian' to think that all the 
apps on apps.linuxaudio.org will get session support, it *is* a 
important matter a SM has to deal with. If Qjackctl doesn't offer this 
functionality by purpose, it is a obvious disadvantage for the user at 
the end.

>
> however, re. exo-/infra-clients (or w/e they've been called, i don't
> quite remember exactly but those are about clients which are
> non-jack-session-aware) are in the drawer ntl.
>
> actually, i was minding about the *intrinsic* cost/benefits of the
> session protocol and *not* about *any* particular *session management*
> (SM) implementation

True, we've to make clear what the technical possibilities of a SM are. 
You're saying that a hypothetical NSM level-0 offers nothing more 
compared to JackSession in this scope. I do also doubt this, you might 
be able to tell me what JackSession can do from the things I described 
as advantages of NSM. I can think of these at least, which still stand:

- JackSession is not able to quit the applications in the session 
without saving.
- It is not possible to add applications without JACK support to a 
JackSession (Frescobalid, Emacs with SuperCollider)
- Changing between NSM sessions is more easy and faster
- with NSM you can use the duplicate function and so use templates
- with NSM you can open multiple session on one host
- NSM has a clear way how to use a session on multiple computers via the 
network
- NSM sessions are not machine dependent (level 1)


This is just a quick brainstorm. As mentioned, this doesn't talk about 
the end implementation benefits of NSM for the user, which are of equal 
importance for the end-user. On that topic I conclude that Qjackctl 
doesn't support infra clients by purpose and that I don't see it happen 
that there will be another GUI who does support in the near future.

Regards,
\r



--===============6758989176100766531==--


From fons@linuxaudio.org Wed Apr  4 16:31:02 2012
From: Fons Adriaensen <fons@linuxaudio.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 04 Apr 2012 16:31:02 +0000
Message-ID: <20120404163101.GA987@linuxaudio.org>
In-Reply-To: <4F7C5CC7.5080006@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0686952492326899809=="

--===============0686952492326899809==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Wed, Apr 04, 2012 at 04:37:59PM +0200, rosea.grammostola wrote:

> Could you elaborate your reasons for this, for those who don't see this  
> as obvious?

I could. But it wouldn't help anyone.

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)


--===============0686952492326899809==--


From rncbc@rncbc.org Wed Apr  4 18:13:42 2012
From: Rui Nuno Capela <rncbc@rncbc.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 04 Apr 2012 18:13:42 +0000
Message-ID: <4F7C8F77.8090807@rncbc.org>
In-Reply-To:
 <CAGhWSSatjpG5xzGCSM6Tg9AFgJRps7Z-1j9h8iD67mt5vs6gmw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0945370065788428416=="

--===============0945370065788428416==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/04/2012 05:19 PM, J. Liles wrote:
>
>
> On Wed, Apr 4, 2012 at 5:22 AM, Rui Nuno Capela <rncbc(a)rncbc.org
> <mailto:rncbc(a)rncbc.org>> wrote:
>
>     On 04/04/2012 12:18 PM, rosea.grammostola wrote:
>
>         On 04/03/2012 07:04 PM, Rui Nuno Capela wrote:
>
>             now, i could suggest NSM API to be split in levels of
>             compliance and
>             restrictiveness, so to speak:
>
>             - level 0 :- clients just store/retrieve their own private
>             state from a
>             supplied and independent session sub-directory; no GUI File menu
>             restrictions; no file location restrictions, no symlinks, no
>             juggling,
>             no dupes, no sh*t.
>
>             - level 1+ :- anything that (may progressively?) imposes
>             each one the
>             mentioned non-restrictions of level 0.
>
>
>         How much more effort will it be in terms of coding, to implement
>         'level-1' versus 'level-0'?
>
>
>     speaking from qtractor pov.:
>
>     - level 0: minimal effort as it would be a probable and simple
>     rephrasing and/or adaptation of the code already in place for
>     jack-session; also, there's this osc branch somewhat lurking in svn
>     to get readily merged and apply for the NSM/OSC interface.
>
>     - level 1+: pervasive change and effort; almost brand new
>     application overhaul (iow. won't happen any time soon:) sorry.
>
>
> Are you seriously saying that the equivalent of doing:
>
> if ( nsm_is_active )
>        save_here( file );
> else
>        save_there( file );
>

this is level 0, assuming "file" is the application private state file


> Would require a complete rewrite and overhaul of your application? Say
> you don't want to do it... That's fine. Say you don't like the NSM
> design--that's fine too. But don't just make up wild hyperbole out of
> laziness...
>

the rewrite is about level 1+ (my nomenclature, i know:)

cheers
-- 
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org

--===============0945370065788428416==--


From rncbc@rncbc.org Wed Apr  4 18:50:39 2012
From: Rui Nuno Capela <rncbc@rncbc.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 04 Apr 2012 18:50:39 +0000
Message-ID: <4F7C981D.6080007@rncbc.org>
In-Reply-To: <4F7C74AA.7020902@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3895891518481768610=="

--===============3895891518481768610==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/04/2012 05:19 PM, rosea.grammostola wrote:
>
> ... On that topic I conclude that Qjackctl doesn't support infra
> clients by purpose and that I don't see it happen that there will be
> another GUI who does support in the near future.
>

wait, it's not "by purpose" but just "overlooked" ok?

infra-clients (ie. jack clients unaware of jack-session) and exo-clients 
(non-jack applications) are here subjects of a "covenant": the SM in 
charge, by its particular implementation, follows some god-knows-what 
convention which is NOT bounded by the session protocol (or API) at 
all--of course, the suspects are not session-aware to begin with, so any 
SM can raise its own "convention" and make up its own party--it's a free 
world isn't it? :)

as said, infra/exo-clients support on qjackctl (as a JSM) is "in the 
drawer", meaning it's coming out any day soon. so, is there yet another 
convention party in the making, you ask?

yep:)

cheers
-- 
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org

--===============3895891518481768610==--


From rosea.grammostola@gmail.com Wed Apr  4 19:59:47 2012
From: "rosea.grammostola" <rosea.grammostola@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 04 Apr 2012 19:59:47 +0000
Message-ID: <4F7CA80D.1060906@gmail.com>
In-Reply-To: <4F7C981D.6080007@rncbc.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5222122902861414151=="

--===============5222122902861414151==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/04/2012 08:51 PM, Rui Nuno Capela wrote:
> On 04/04/2012 05:19 PM, rosea.grammostola wrote:
>>
>> ... On that topic I conclude that Qjackctl doesn't support infra
>> clients by purpose and that I don't see it happen that there will be
>> another GUI who does support in the near future.
>>
>
> wait, it's not "by purpose" but just "overlooked" ok?
>
> infra-clients (ie. jack clients unaware of jack-session) and exo-clients
> (non-jack applications) are here subjects of a "covenant": the SM in
> charge, by its particular implementation, follows some god-knows-what
> convention which is NOT bounded by the session protocol (or API) at
> all--of course, the suspects are not session-aware to begin with, so any
> SM can raise its own "convention" and make up its own party--it's a free
> world isn't it? :)
>
> as said, infra/exo-clients support on qjackctl (as a JSM) is "in the
> drawer", meaning it's coming out any day soon. so, is there yet another
> convention party in the making, you ask?

That would take away one, for me important, advantage of NSM compared to 
JackSession atm (for the user). All though the implementation in 
Pyjacksm, is more cumbersome (using configuration file where you have to 
set each application you use) compared to NSM (no thinking, just adding 
clients).

One might ask why this isn't already in Qjackctl and how long it will 
take though. Which brings me to another possible advantage of NSM. The 
fact that the developer is clearly dedicated to the ask in time and 
motivation. And also important, he uses NSM himself and believes in 
session management. (I little reasons to believe that JS devs use 
JackSession themselves. Also if I read your words well Rui, I don't 
think you use Qjackctls session option yourself). With JackSession you 
lack those things atm (no blaming here). It's probably no accident that 
in NSM it's all there, whereas for JackSession some features still have 
to be implemented (in the GUI). Personally I asked for the infra client 
feature way back, but it's still not there. A new project like NSM seems 
to be needed to get some new progress, this is not the kind of 
dedication such a project needs (no blaming).

But of course, this are not the only reason to prefer one SM above the 
other. As mentioned in my previous mails, there are arguments for me atm 
to say that NSM gives a user more then JackSession (even with the 
hypothetical level-0). NSM seems to be a SM which has a very good and 
simple solution, more functionality then JackSession, without the need 
of things like Jackdbus (ladish).
Also I've the opinion that the community should go with the best 
implementation. Why go for an implementation which lacks useful 
functionality when implementation into the apps are more or less the 
same effort?
  I think it's essential to the discussion to get the cards on the 
table, so everybody can make up his own mind and decides which SM is the 
best solution for the Linuxaudio session puzzle. It would be nice if we 
could reach agreement on this, but it's a free world indeed. :)

Regards,
\r



--===============5222122902861414151==--


From rosea.grammostola@gmail.com Wed Apr  4 20:13:30 2012
From: "rosea.grammostola" <rosea.grammostola@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 04 Apr 2012 20:13:30 +0000
Message-ID: <4F7CAB45.5050700@gmail.com>
In-Reply-To: <4F7CA80D.1060906@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3352917822520290624=="

--===============3352917822520290624==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/04/2012 09:59 PM, rosea.grammostola wrote:
> But of course, this are not the only reason to prefer one SM above the
> other. As mentioned in my previous mails, there are arguments for me atm
> to say that NSM gives a user more then JackSession (even with the
> hypothetical level-0). NSM seems to be a SM which has a very good and
> simple solution, more functionality then JackSession, without the need
> of things like Jackdbus (ladish).
> Also I've the opinion that the community should go with the best
> implementation. Why go for an implementation which lacks useful
> functionality when implementation into the apps are more or less the
> same effort?

Afaik, NSM gives us all we users need when it comes to LAU session 
management. You've to help me to give something it doesn't do in this 
scope. If you can't help me with this, you can more or less take the 
conclusion that NSM is a final solution to the Linuxaudio session 
puzzle. Final as in, does all what it should do, has intrinsic all the 
stuff it should be able to do in the coming >10 yrs, it doesn't lack 
essential features in terms of functionality and workflow, if a better 
SM bumps up in the coming yrs there will likely be no essential reasons 
to switch to that one (which makes the effort for adding NSM support to 
an app, a valuable and longstanding contribution).

Correct me if I'm wrong.

Regards,
\r



--===============3352917822520290624==--


From fons@linuxaudio.org Wed Apr  4 20:48:45 2012
From: Fons Adriaensen <fons@linuxaudio.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 04 Apr 2012 20:48:45 +0000
Message-ID: <20120404204844.GB11509@linuxaudio.org>
In-Reply-To:
 <CAGhWSSatjpG5xzGCSM6Tg9AFgJRps7Z-1j9h8iD67mt5vs6gmw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1317187613588965687=="

--===============1317187613588965687==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Wed, Apr 04, 2012 at 09:19:57AM -0700, J. Liles wrote:
 
> Are you seriously saying that the equivalent of doing:
> 
> if ( nsm_is_active )
>       save_here( file );
> else
>       save_there( file );
> 
> Would require a complete rewrite and overhaul of your application? Say you
> don't want to do it... That's fine. Say you don't like the NSM
> design--that's fine too. But don't just make up wild hyperbole out of
> laziness...

:-)

A question: according to the docs, a client should consider itself
'managed' after receiving the reply to the 'announce' message. But
at that time it has no path to save anything 'New' or 'Load'ed.
If I understand the docs correctly, the 'open' message specifying
this path will follow immediately. But still this is a possible race
condition. So shouldn't a client consider itself managed only after
having received the first 'open' message ?

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)


--===============1317187613588965687==--


From d@drobilla.net Wed Apr  4 21:22:47 2012
From: David Robillard <d@drobilla.net>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 04 Apr 2012 21:22:47 +0000
Message-ID: <1333574553.9602.18.camel@verne.drobilla.net>
In-Reply-To: <4F7CA80D.1060906@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7355140422476184877=="

--===============7355140422476184877==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Wed, 2012-04-04 at 21:59 +0200, rosea.grammostola wrote:
[...]
>   I think it's essential to the discussion to get the cards on the 
> table, so everybody can make up his own mind and decides which SM is the 
> best solution for the Linuxaudio session puzzle. It would be nice if we 
> could reach agreement on this, but it's a free world indeed. :)

With apologies in advance, here are my cards:

It would be nice if this list could stick to actual
developer/development problems.  I just spent quite some time catching
up on this thread, and almost nothing at all of value (i.e. something
towards solving the/a problem) has been contributed since last I
checked.  Mostly just a bunch of wannabe bureaucracy political noise,
which only obscures any actual technical points that might need fleshing
out (i.e. it's actively hurting, not helping).  I doubt I'm the only one
interested in the problem who's just given up on this thread because the
signal:noise ratio is ridiculous.

Take the politics to LAU or something.  The official resolution of the
User Committee on The Agreed-Upon Solution for LAD Session Management
will have zero impact on what developers actually implement, but
dragging the signal:noise ratio into the gutter might - though probably
not the impact you were hoping for.

-dr


--===============7355140422476184877==--


From malnourite@gmail.com Wed Apr  4 22:23:06 2012
From: "J. Liles" <malnourite@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 04 Apr 2012 22:23:06 +0000
Message-ID:
 <CAGhWSSYOtBVL-kiRwnMb5TEYDTF5pr6YJ6=4RnzE421cMSvx6w@mail.gmail.com>
In-Reply-To: <20120404204844.GB11509@linuxaudio.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7336880830397375658=="

--===============7336880830397375658==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Wed, Apr 4, 2012 at 1:48 PM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:

> On Wed, Apr 04, 2012 at 09:19:57AM -0700, J. Liles wrote:
>
> > Are you seriously saying that the equivalent of doing:
> >
> > if ( nsm_is_active )
> >       save_here( file );
> > else
> >       save_there( file );
> >
> > Would require a complete rewrite and overhaul of your application? Say
> you
> > don't want to do it... That's fine. Say you don't like the NSM
> > design--that's fine too. But don't just make up wild hyperbole out of
> > laziness...
>
> :-)
>
> A question: according to the docs, a client should consider itself
> 'managed' after receiving the reply to the 'announce' message. But
> at that time it has no path to save anything 'New' or 'Load'ed.
> If I understand the docs correctly, the 'open' message specifying
> this path will follow immediately. But still this is a possible race
> condition. So shouldn't a client consider itself managed only after
> having received the first 'open' message ?
>

Yes. Well, there's a bit of a fine distinction between being managed and
being part of the session. The application could conceivably receive a
'quit' message before the 'open' message, but that would never actually
happen in the current implementation and doesn't make a lot of sense
anyway. I think you're probably right in that for all practical purposes
'open' is the time to consider the application managed.



--===============7336880830397375658==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PGJyPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gV2VkLCBBcHIgNCwgMjAxMiBhdCAx
OjQ4IFBNLCBGb25zIEFkcmlhZW5zZW4gPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWls
dG86Zm9uc0BsaW51eGF1ZGlvLm9yZyI+Zm9uc0BsaW51eGF1ZGlvLm9yZzwvYT4mZ3Q7PC9zcGFu
PiB3cm90ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2lu
OjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+
CjxkaXYgY2xhc3M9ImltIj5PbiBXZWQsIEFwciAwNCwgMjAxMiBhdCAwOToxOTo1N0FNIC0wNzAw
LCBKLiBMaWxlcyB3cm90ZTo8YnI+Cjxicj4KJmd0OyBBcmUgeW91IHNlcmlvdXNseSBzYXlpbmcg
dGhhdCB0aGUgZXF1aXZhbGVudCBvZiBkb2luZzo8YnI+CiZndDs8YnI+CiZndDsgaWYgKCBuc21f
aXNfYWN0aXZlICk8YnI+CiZndDsgwqAgwqAgwqAgc2F2ZV9oZXJlKCBmaWxlICk7PGJyPgomZ3Q7
IGVsc2U8YnI+CiZndDsgwqAgwqAgwqAgc2F2ZV90aGVyZSggZmlsZSApOzxicj4KJmd0Ozxicj4K
Jmd0OyBXb3VsZCByZXF1aXJlIGEgY29tcGxldGUgcmV3cml0ZSBhbmQgb3ZlcmhhdWwgb2YgeW91
ciBhcHBsaWNhdGlvbj8gU2F5IHlvdTxicj4KJmd0OyBkb24mIzM5O3Qgd2FudCB0byBkbyBpdC4u
LiBUaGF0JiMzOTtzIGZpbmUuIFNheSB5b3UgZG9uJiMzOTt0IGxpa2UgdGhlIE5TTTxicj4KJmd0
OyBkZXNpZ24tLXRoYXQmIzM5O3MgZmluZSB0b28uIEJ1dCBkb24mIzM5O3QganVzdCBtYWtlIHVw
IHdpbGQgaHlwZXJib2xlIG91dCBvZjxicj4KJmd0OyBsYXppbmVzcy4uLjxicj4KPGJyPgo8L2Rp
dj46LSk8YnI+Cjxicj4KQSBxdWVzdGlvbjogYWNjb3JkaW5nIHRvIHRoZSBkb2NzLCBhIGNsaWVu
dCBzaG91bGQgY29uc2lkZXIgaXRzZWxmPGJyPgomIzM5O21hbmFnZWQmIzM5OyBhZnRlciByZWNl
aXZpbmcgdGhlIHJlcGx5IHRvIHRoZSAmIzM5O2Fubm91bmNlJiMzOTsgbWVzc2FnZS4gQnV0PGJy
PgphdCB0aGF0IHRpbWUgaXQgaGFzIG5vIHBhdGggdG8gc2F2ZSBhbnl0aGluZyAmIzM5O05ldyYj
Mzk7IG9yICYjMzk7TG9hZCYjMzk7ZWQuPGJyPgpJZiBJIHVuZGVyc3RhbmQgdGhlIGRvY3MgY29y
cmVjdGx5LCB0aGUgJiMzOTtvcGVuJiMzOTsgbWVzc2FnZSBzcGVjaWZ5aW5nPGJyPgp0aGlzIHBh
dGggd2lsbCBmb2xsb3cgaW1tZWRpYXRlbHkuIEJ1dCBzdGlsbCB0aGlzIGlzIGEgcG9zc2libGUg
cmFjZTxicj4KY29uZGl0aW9uLiBTbyBzaG91bGRuJiMzOTt0IGEgY2xpZW50IGNvbnNpZGVyIGl0
c2VsZiBtYW5hZ2VkIG9ubHkgYWZ0ZXI8YnI+CmhhdmluZyByZWNlaXZlZCB0aGUgZmlyc3QgJiMz
OTtvcGVuJiMzOTsgbWVzc2FnZSA/PGJyPjwvYmxvY2txdW90ZT48ZGl2Pjxicj5ZZXMuIFdlbGws
IHRoZXJlJiMzOTtzIGEgYml0IG9mIGEgZmluZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIGJlaW5nIG1h
bmFnZWQgYW5kIGJlaW5nIHBhcnQgb2YgdGhlIHNlc3Npb24uIFRoZSBhcHBsaWNhdGlvbiBjb3Vs
ZCBjb25jZWl2YWJseSByZWNlaXZlIGEgJiMzOTtxdWl0JiMzOTsgbWVzc2FnZSBiZWZvcmUgdGhl
ICYjMzk7b3BlbiYjMzk7IG1lc3NhZ2UsIGJ1dCB0aGF0IHdvdWxkIG5ldmVyIGFjdHVhbGx5IGhh
cHBlbiBpbiB0aGUgY3VycmVudCBpbXBsZW1lbnRhdGlvbiBhbmQgZG9lc24mIzM5O3QgbWFrZSBh
IGxvdCBvZiBzZW5zZSBhbnl3YXkuIEkgdGhpbmsgeW91JiMzOTtyZSBwcm9iYWJseSByaWdodCBp
biB0aGF0IGZvciBhbGwgcHJhY3RpY2FsIHB1cnBvc2VzICYjMzk7b3BlbiYjMzk7IGlzIHRoZSB0
aW1lIHRvIGNvbnNpZGVyIHRoZSBhcHBsaWNhdGlvbiBtYW5hZ2VkLjxicj4KPGJyPsKgPC9kaXY+
PC9kaXY+Cg==

--===============7336880830397375658==--


From malnourite@gmail.com Wed Apr  4 22:28:22 2012
From: "J. Liles" <malnourite@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 04 Apr 2012 22:28:22 +0000
Message-ID:
 <CAGhWSSYzXFa-wYLNoa+HKW_BKwPaTWA-pakGT=F4w+x=wPszOQ@mail.gmail.com>
In-Reply-To:
 <CAGhWSSYOtBVL-kiRwnMb5TEYDTF5pr6YJ6=4RnzE421cMSvx6w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0300762545581193625=="

--===============0300762545581193625==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 4, 2012 at 3:22 PM, J. Liles <malnourite(a)gmail.com> wrote:

>
>
> On Wed, Apr 4, 2012 at 1:48 PM, Fons Adriaensen <fons(a)linuxaudio.org>wrot=
e:
>
>> On Wed, Apr 04, 2012 at 09:19:57AM -0700, J. Liles wrote:
>>
>> > Are you seriously saying that the equivalent of doing:
>> >
>> > if ( nsm_is_active )
>> >       save_here( file );
>> > else
>> >       save_there( file );
>> >
>> > Would require a complete rewrite and overhaul of your application? Say
>> you
>> > don't want to do it... That's fine. Say you don't like the NSM
>> > design--that's fine too. But don't just make up wild hyperbole out of
>> > laziness...
>>
>> :-)
>>
>> A question: according to the docs, a client should consider itself
>> 'managed' after receiving the reply to the 'announce' message. But
>> at that time it has no path to save anything 'New' or 'Load'ed.
>> If I understand the docs correctly, the 'open' message specifying
>> this path will follow immediately. But still this is a possible race
>> condition. So shouldn't a client consider itself managed only after
>> having received the first 'open' message ?
>>
>
> Yes. Well, there's a bit of a fine distinction between being managed and
> being part of the session. The application could conceivably receive a
> 'quit' message before the 'open' message, but that would never actually
> happen in the current implementation and doesn't make a lot of sense
> anyway. I think you're probably right in that for all practical purposes
> 'open' is the time to consider the application managed.
>
>
Also, to clairify, by 'quit' I mean SIGTERM and furthermore, there's no
reason that the announce reply and the first open message can't be in an
OSC 'bundle' to guarantee they are processed at the same time (although the
current implementation doesn't use bundles).


>



--===============0300762545581193625==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PGJyPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gV2VkLCBBcHIgNCwgMjAxMiBhdCAz
OjIyIFBNLCBKLiBMaWxlcyA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzptYWxu
b3VyaXRlQGdtYWlsLmNvbSI+bWFsbm91cml0ZUBnbWFpbC5jb208L2E+Jmd0Ozwvc3Bhbj4gd3Jv
dGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAg
MCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPgo8YnI+
PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48ZGl2IGNsYXNzPSJpbSI+T24gV2VkLCBBcHIg
NCwgMjAxMiBhdCAxOjQ4IFBNLCBGb25zIEFkcmlhZW5zZW4gPHNwYW4gZGlyPSJsdHIiPiZsdDs8
YSBocmVmPSJtYWlsdG86Zm9uc0BsaW51eGF1ZGlvLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmZvbnNA
bGludXhhdWRpby5vcmc8L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPjxibG9ja3F1b3RlIGNsYXNz
PSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAj
Y2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPgoKPGRpdj5PbiBXZWQsIEFwciAwNCwgMjAxMiBh
dCAwOToxOTo1N0FNIC0wNzAwLCBKLiBMaWxlcyB3cm90ZTo8YnI+Cjxicj4KJmd0OyBBcmUgeW91
IHNlcmlvdXNseSBzYXlpbmcgdGhhdCB0aGUgZXF1aXZhbGVudCBvZiBkb2luZzo8YnI+CiZndDs8
YnI+CiZndDsgaWYgKCBuc21faXNfYWN0aXZlICk8YnI+CiZndDsgwqAgwqAgwqAgc2F2ZV9oZXJl
KCBmaWxlICk7PGJyPgomZ3Q7IGVsc2U8YnI+CiZndDsgwqAgwqAgwqAgc2F2ZV90aGVyZSggZmls
ZSApOzxicj4KJmd0Ozxicj4KJmd0OyBXb3VsZCByZXF1aXJlIGEgY29tcGxldGUgcmV3cml0ZSBh
bmQgb3ZlcmhhdWwgb2YgeW91ciBhcHBsaWNhdGlvbj8gU2F5IHlvdTxicj4KJmd0OyBkb24mIzM5
O3Qgd2FudCB0byBkbyBpdC4uLiBUaGF0JiMzOTtzIGZpbmUuIFNheSB5b3UgZG9uJiMzOTt0IGxp
a2UgdGhlIE5TTTxicj4KJmd0OyBkZXNpZ24tLXRoYXQmIzM5O3MgZmluZSB0b28uIEJ1dCBkb24m
IzM5O3QganVzdCBtYWtlIHVwIHdpbGQgaHlwZXJib2xlIG91dCBvZjxicj4KJmd0OyBsYXppbmVz
cy4uLjxicj4KPGJyPgo8L2Rpdj46LSk8YnI+Cjxicj4KQSBxdWVzdGlvbjogYWNjb3JkaW5nIHRv
IHRoZSBkb2NzLCBhIGNsaWVudCBzaG91bGQgY29uc2lkZXIgaXRzZWxmPGJyPgomIzM5O21hbmFn
ZWQmIzM5OyBhZnRlciByZWNlaXZpbmcgdGhlIHJlcGx5IHRvIHRoZSAmIzM5O2Fubm91bmNlJiMz
OTsgbWVzc2FnZS4gQnV0PGJyPgphdCB0aGF0IHRpbWUgaXQgaGFzIG5vIHBhdGggdG8gc2F2ZSBh
bnl0aGluZyAmIzM5O05ldyYjMzk7IG9yICYjMzk7TG9hZCYjMzk7ZWQuPGJyPgpJZiBJIHVuZGVy
c3RhbmQgdGhlIGRvY3MgY29ycmVjdGx5LCB0aGUgJiMzOTtvcGVuJiMzOTsgbWVzc2FnZSBzcGVj
aWZ5aW5nPGJyPgp0aGlzIHBhdGggd2lsbCBmb2xsb3cgaW1tZWRpYXRlbHkuIEJ1dCBzdGlsbCB0
aGlzIGlzIGEgcG9zc2libGUgcmFjZTxicj4KY29uZGl0aW9uLiBTbyBzaG91bGRuJiMzOTt0IGEg
Y2xpZW50IGNvbnNpZGVyIGl0c2VsZiBtYW5hZ2VkIG9ubHkgYWZ0ZXI8YnI+CmhhdmluZyByZWNl
aXZlZCB0aGUgZmlyc3QgJiMzOTtvcGVuJiMzOTsgbWVzc2FnZSA/PGJyPjwvYmxvY2txdW90ZT48
L2Rpdj48ZGl2Pjxicj5ZZXMuIFdlbGwsIHRoZXJlJiMzOTtzIGEgYml0IG9mIGEgZmluZSBkaXN0
aW5jdGlvbiBiZXR3ZWVuIGJlaW5nIG1hbmFnZWQgYW5kIGJlaW5nIHBhcnQgb2YgdGhlIHNlc3Np
b24uIFRoZSBhcHBsaWNhdGlvbiBjb3VsZCBjb25jZWl2YWJseSByZWNlaXZlIGEgJiMzOTtxdWl0
JiMzOTsgbWVzc2FnZSBiZWZvcmUgdGhlICYjMzk7b3BlbiYjMzk7IG1lc3NhZ2UsIGJ1dCB0aGF0
IHdvdWxkIG5ldmVyIGFjdHVhbGx5IGhhcHBlbiBpbiB0aGUgY3VycmVudCBpbXBsZW1lbnRhdGlv
biBhbmQgZG9lc24mIzM5O3QgbWFrZSBhIGxvdCBvZiBzZW5zZSBhbnl3YXkuIEkgdGhpbmsgeW91
JiMzOTtyZSBwcm9iYWJseSByaWdodCBpbiB0aGF0IGZvciBhbGwgcHJhY3RpY2FsIHB1cnBvc2Vz
ICYjMzk7b3BlbiYjMzk7IGlzIHRoZSB0aW1lIHRvIGNvbnNpZGVyIHRoZSBhcHBsaWNhdGlvbiBt
YW5hZ2VkLjxicj4KCjxicj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+QWxzbywg
dG8gY2xhaXJpZnksIGJ5ICYjMzk7cXVpdCYjMzk7IEkgbWVhbiBTSUdURVJNIGFuZCBmdXJ0aGVy
bW9yZSwgdGhlcmUmIzM5O3Mgbm8gcmVhc29uIHRoYXQgdGhlIGFubm91bmNlIHJlcGx5IGFuZCB0
aGUgZmlyc3Qgb3BlbiBtZXNzYWdlIGNhbiYjMzk7dCBiZSBpbiBhbiBPU0MgJiMzOTtidW5kbGUm
IzM5OyB0byBndWFyYW50ZWUgdGhleSBhcmUgcHJvY2Vzc2VkIGF0IHRoZSBzYW1lIHRpbWUgKGFs
dGhvdWdoIHRoZSBjdXJyZW50IGltcGxlbWVudGF0aW9uIGRvZXNuJiMzOTt0IHVzZSBidW5kbGVz
KS48YnI+CsKgPGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9
Im1hcmdpbjowcHQgMHB0IDBwdCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwy
MDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4KPC9ibG9ja3F1b3RlPjwvZGl2Pjxicj4K

--===============0300762545581193625==--


From rosea.grammostola@gmail.com Wed Apr  4 22:45:38 2012
From: "rosea.grammostola" <rosea.grammostola@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 04 Apr 2012 22:45:38 +0000
Message-ID: <4F7CCEE8.3090405@gmail.com>
In-Reply-To: <1333574553.9602.18.camel@verne.drobilla.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6467082585600759297=="

--===============6467082585600759297==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On 04/04/2012 11:22 PM, David Robillard wrote:
> On Wed, 2012-04-04 at 21:59 +0200, rosea.grammostola wrote: [...]
>> I think it's essential to the discussion to get the cards on the
>> table, so everybody can make up his own mind and decides which SM
>> is the best solution for the Linuxaudio session puzzle. It would be
>> nice if we could reach agreement on this, but it's a free world
>> indeed. :)
>
> With apologies in advance, here are my cards:

Thanks, with my apologies in advance for my reply. :)
>
> It would be nice if this list could stick to actual
> developer/development problems.

Of course this is the LAD list, so I don't post often on this list,=20
except for this topic, started by me and of importance for me.

I think this topic is a special case on LAD, because it's by far more=20
interesting for users to have a good SM implementation then for=20
developers. For musicians/ user it is a real problem when something=20
doesn't work or when a session API is implemented badly (technically=20
and/ or socially). Developers care much less.

But if you make such a strict border between devs and users, also in=20
such a topic, as you seem to suggest, I'm afraid we'll have to deal with=20
the same 'great-technical-design' but=20
'sorry-not-yet-usable-if-you-really-want-to-make-music' software issues=20
in the coming years on Linux.

Or in the case of session management,'great-minimal-design' but=20
'useless-because-you-can-only-use-a-few-apps-and-we-dont-have-a-problem-with-=
that-because-we-dont-use-it-ourselves'.

I'll tell you why this topic is important to me. I did a talk about=20
Linuxaudio. I can't tell you how much of a pain it was to get my stuff=20
together. It did cost me more then a *fulltime week, 10h a day* to be=20
able to show a more or less workable Linuxaudio workflow. Truly=20
ridiculous and it made me realize that JackSession is utopian (and=20
probably making music on Linux too) in this state.

It's nice to talk about software design side of Linuxaudio, but actually=20
working with it is a whole different story, I tell you...especially the=20
combination 'making music' and 'the modular approach'... (NSM seems to=20
change this quite a bit though)

But if you're only interested in technical stuff and academic discussion=20
about APIs, this might be not very interesting to read for you, my=20
apologies.


> up on this thread, and almost nothing at all of value (i.e.
> something towards solving the/a problem) has been contributed since
> last I checked.  Mostly just a bunch of wannabe bureaucracy political
> noise, which only obscures any actual technical points that might
> need fleshing out (i.e. it's actively hurting, not helping). >
> Take the politics to LAU or something.


Call it politics, or call it just an obvious part of the process of=20
implementing something like a session manager API, where a large part of=20
the community has to deal with. For me it's not politics in the sense=20
that I like to see API X supported, rather then API Y, don't get me=20
wrong. I just think it's important to get the real true (technical/ LAD=20
related) arguments on table, it helps already to get the picture clear=20
and to kill argumentation flaws, wrong suggestions and myths. That's in=20
the benefit for devs and users.


Regards,
\r







--===============6467082585600759297==--


From d@drobilla.net Wed Apr  4 23:25:47 2012
From: David Robillard <d@drobilla.net>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 04 Apr 2012 23:25:47 +0000
Message-ID: <1333581940.9602.42.camel@verne.drobilla.net>
In-Reply-To: <4F7B2D95.5030202@rncbc.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0509342944323674583=="

--===============0509342944323674583==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Tue, 2012-04-03 at 18:04 +0100, Rui Nuno Capela wrote:
[...]
> ardour gets all its stuff under one own session directory, on a per 
> session/project basis, iirc just like NSM mandates,
> 
> bbbuuuuuut...:) making that one and the same directory as from an 
> outsider/independent session manager like NSM is asking for a lot of 
> file and symlink juggling, if you ask me
> 
> i'm not an expert in ardour internals, someone else could chime in and 
> help me here.

I don't know what you are trying to say.  "One and the same directory as
from an outsider/independent session manager"?  Huh?

A directory of files is a directory of files.  The format Ardour would
save to inside of a session is precisely the same format it already
saves in, perhaps with some things being links.

I can guarantee you that much, because if it had to be different,
Ardour, like presumably most apps, simply would never implement it...

> > my feeling again is that the effort to comply with NSM isn't, won't be 
> > so easy for any lass-than-simple-textbook-like client examples

Not really.  Qtractor is just a weirdo edge case.  You seem to be trying
to paint the "mandates" of NSM as deeply imposing requirements, but
they're not.  Quite the opposite, really, anything else would certainly
be *far* more imposing and complicated.  That's kind of the point.

It's not really worth it to care about this case from an SM perspective
since it's rare, easily fixable, inherently un-archivable, and there's
no palatable solution for dealing with apps like this anyway.  The
obvious one would be to have a special 'deep save', but then... if the
app implements that, it can just save that way when running in an SM
every time.  Therefore it's a non-issue (heh) for SM.

-dr



--===============0509342944323674583==--


From brendan.jones.it@gmail.com Thu Apr  5 09:17:22 2012
From: Brendan Jones <brendan.jones.it@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: [LAD] Google summer of code - Fedora Audio
Date: Thu, 05 Apr 2012 09:17:22 +0000
Message-ID: <4F7D6317.5050703@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4155565092268081841=="

--===============4155565092268081841==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hey all,

we've listed the the Fedora Audio/Studio distro as an idea for the 
Google summer of code. Apart from packaging/community wrangling etc., 
one of the requirements is development effort to provide some out of the 
box jack/pulse configuration, similar to what falktx is doing with 
KXStudio.

So if you are a student and find this interesting (and are in need of a 
cash injection) please apply. Deadline for student applications is 
tomorrow. You can find all the links to information you need here 
http://brendanonet.com/gsoc/

Brendan

--===============4155565092268081841==--


From rncbc@rncbc.org Thu Apr  5 11:16:34 2012
From: Rui Nuno Capela <rncbc@rncbc.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Thu, 05 Apr 2012 11:16:34 +0000
Message-ID: <4F7D7E7B.7010801@rncbc.org>
In-Reply-To: <1333581940.9602.42.camel@verne.drobilla.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6800187898217643188=="

--===============6800187898217643188==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/05/2012 12:25 AM, David Robillard wrote:
> On Tue, 2012-04-03 at 18:04 +0100, Rui Nuno Capela wrote:
> [...]
>> ardour gets all its stuff under one own session directory, on a per
>> session/project basis, iirc just like NSM mandates,
>>
>> bbbuuuuuut...:) making that one and the same directory as from an
>> outsider/independent session manager like NSM is asking for a lot of
>> file and symlink juggling, if you ask me
>>
>> i'm not an expert in ardour internals, someone else could chime in and
>> help me here.
>
> I don't know what you are trying to say.  "One and the same directory as
> from an outsider/independent session manager"?  Huh?
>
> A directory of files is a directory of files.  The format Ardour would
> save to inside of a session is precisely the same format it already
> saves in, perhaps with some things being links.
>
> I can guarantee you that much, because if it had to be different,
> Ardour, like presumably most apps, simply would never implement it...
>

ok then.

but again, i was implying about the NSM session directory location 
restriction, not ardour's session/project directory/file format.

let me thrown in some more ;)

from what I read on the NSM User & API specs. you can only create new, 
open and save NSM-managed sessions as in each participating client 
project's sub-directories. existing individual projects are out of the 
picture. unless you "cheat" the NSM o.O

iow. what if, assuming Ardour were about a fully-compliant NSM client 
and you want to open an existing Ardour session, one you've been working 
hard previously but stand-lone ie. outside the NSM umbrella? i read that 
you'll have to copy or move all ardour's session files _manually_ first, 
or symlink at best, into the NSM's central/root directory and guess what 
and where. that's the kind of "cheat" or "juggling" i was telling you 
about :)

otoh, if its native(gui file menu)-open is available, it would be dead 
simple to get an existing qtractor project into a NSM session and 
behold: later, the NSM would just save (a new stanza) of the qtractor 
session/state file under the SM's designated central directory location 
and that's perfect for qtractor, see? because all qtractor media content 
files are external and independent of the state file. and if you (the 
user) selects the archive/zip bundle format (.qtz suffix) as default, 
then we'll get *all* qtractor project stuff under the nominated NSM 
session directory tree (already compressed into one single archive/zip 
file, though)

perhaps, automatic symlinking of all the external files could be also 
doable at the NSM-Save instant, 'coz qtractor state is, among other 
important things, an inventory map of all those files anyway--some 
invasive coding required, though ;)

looks like, after all, that qtractor could stand compliant to both NSM 
levels 0 and 1+, in one fine blow, only if those file menu restrictions 
get subverted or just plainly ignored:o) and all the code to comply with 
the basic NSM API announce, open, save, close... gets eventually coded 
in, of course

aha. this seems the case for "edgy" applications like qtractor, when 
their own file new, open, save, and save as... menu operations are made 
completely orthogonal and independent of any general SM open/save ones.

try that with the not-so-edgy (mainstream?) applications ;)

cheers
-- 
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org

--===============6800187898217643188==--


From fons@linuxaudio.org Thu Apr  5 12:16:45 2012
From: Fons Adriaensen <fons@linuxaudio.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Thu, 05 Apr 2012 12:16:45 +0000
Message-ID: <20120405121641.GA8690@linuxaudio.org>
In-Reply-To: <4F7D7E7B.7010801@rncbc.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4836021050782446589=="

--===============4836021050782446589==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Thu, Apr 05, 2012 at 12:14:03PM +0100, Rui Nuno Capela wrote:

> from what I read on the NSM User & API specs. you can only create new,  
> open and save NSM-managed sessions as in each participating client  
> project's sub-directories. existing individual projects are out of the  
> picture. unless you "cheat" the NSM o.O
>
> iow. what if, assuming Ardour were about a fully-compliant NSM client  
> and you want to open an existing Ardour session, one you've been working  
> hard previously but stand-lone ie. outside the NSM umbrella? i read that  
> you'll have to copy or move all ardour's session files _manually_ first,  
> or symlink at best, into the NSM's central/root directory and guess what  
> and where. that's the kind of "cheat" or "juggling" i was telling you  
> about :)

You have a project of application A, created without NSM, and the project
is saved in P (a single file, or a directory).

You want to use P as part of an NSM session. Note that this scenario means
that A has some button to select if it runs under NSM or not. Let's assume
that the default is to run stand-alone.

There are two ways to do this:

1. ('Load' and 'New' are disabled when running NSM)

* Start A.
* Load  P.
* Connect A to NSM. Application A will receive a path indicating
  where to save its current project. The actual message is 'open',
  but since there is nothing to open at the given path the only
  sensible thing to do is to put the current project there.
  App. A can do so immediately, and then continue as normal.
  The whole thing amounts to a 'Save as' [*] with the name given
  by NSM instead of the user. So it's really nothing new.


2. ('Load' and 'New' are not disabled but the application knows
    how to handle then when running under NSM)

* Start A.
* Connect A to NSM. App. A will receive a path indicating where to
  save the its project. Since A is now running under NSM, it remembers
  this path as the 'current project' even when it loads another one,
  or creates a complete new one (under these condition A is allowed
  to have 'Load' and 'New' menu entries).
* Load P. App A knows that it should not save to P, but to the path
  given by NSM. To keep things simple, it could copy P to that path
  immediately and then continue as normal. Again this is essentially
  a 'Save as'.


The only difference between the two is that in (2) the second and
third steps are swapped. 

No 'manual' user action is required in either case.

Ciao,


[*] 'Save as' interpreted as most apps would, not as Ardour does it.
In Ardour, 'Save as' does not create a new project but a snapshot,
while setting the current name to that snapshot.

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


--===============4836021050782446589==--


From rncbc@rncbc.org Thu Apr  5 14:18:52 2012
From: Rui Nuno Capela <rncbc@rncbc.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Thu, 05 Apr 2012 14:18:52 +0000
Message-ID: <4F7DA9EC.8030004@rncbc.org>
In-Reply-To: <20120405121641.GA8690@linuxaudio.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3545614660012732524=="

--===============3545614660012732524==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/05/2012 01:16 PM, Fons Adriaensen wrote:
> On Thu, Apr 05, 2012 at 12:14:03PM +0100, Rui Nuno Capela wrote:
>
>> from what I read on the NSM User&  API specs. you can only create new,
>> open and save NSM-managed sessions as in each participating client
>> project's sub-directories. existing individual projects are out of the
>> picture. unless you "cheat" the NSM o.O
>>
>> iow. what if, assuming Ardour were about a fully-compliant NSM client
>> and you want to open an existing Ardour session, one you've been working
>> hard previously but stand-lone ie. outside the NSM umbrella? i read that
>> you'll have to copy or move all ardour's session files _manually_ first,
>> or symlink at best, into the NSM's central/root directory and guess what
>> and where. that's the kind of "cheat" or "juggling" i was telling you
>> about :)
>
> You have a project of application A, created without NSM, and the project
> is saved in P (a single file, or a directory).
>
> You want to use P as part of an NSM session. Note that this scenario means
> that A has some button to select if it runs under NSM or not. Let's assume
> that the default is to run stand-alone.
>
> There are two ways to do this:
>
> 1. ('Load' and 'New' are disabled when running NSM)
>
> * Start A.
> * Load  P.
> * Connect A to NSM. Application A will receive a path indicating
>    where to save its current project. The actual message is 'open',
>    but since there is nothing to open at the given path the only
>    sensible thing to do is to put the current project there.
>    App. A can do so immediately, and then continue as normal.
>    The whole thing amounts to a 'Save as' [*] with the name given
>    by NSM instead of the user. So it's really nothing new.
>
>
> 2. ('Load' and 'New' are not disabled but the application knows
>      how to handle then when running under NSM)
>
> * Start A.
> * Connect A to NSM. App. A will receive a path indicating where to
>    save the its project. Since A is now running under NSM, it remembers
>    this path as the 'current project' even when it loads another one,
>    or creates a complete new one (under these condition A is allowed
>    to have 'Load' and 'New' menu entries).
> * Load P. App A knows that it should not save to P, but to the path
>    given by NSM. To keep things simple, it could copy P to that path
>    immediately and then continue as normal. Again this is essentially
>    a 'Save as'.
>
>
> The only difference between the two is that in (2) the second and
> third steps are swapped.
>
> No 'manual' user action is required in either case.
 >
 > [*] 'Save as' interpreted as most apps would, not as Ardour does it.
 > In Ardour, 'Save as' does not create a new project but a snapshot,
 > while setting the current name to that snapshot.
 >

so true, and ain't that something? you actually need the native-open and 
save(as...) commands enabled after all o.O

i rest my case ;)

cheers
-- 
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org

--===============3545614660012732524==--


From fons@linuxaudio.org Thu Apr  5 14:48:55 2012
From: Fons Adriaensen <fons@linuxaudio.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Thu, 05 Apr 2012 14:48:55 +0000
Message-ID: <20120405144854.GA24754@linuxaudio.org>
In-Reply-To: <4F7DA9EC.8030004@rncbc.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6447327021208905795=="

--===============6447327021208905795==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Thu, Apr 05, 2012 at 03:19:24PM +0100, Rui Nuno Capela wrote:
> On 04/05/2012 01:16 PM, Fons Adriaensen wrote:
>> On Thu, Apr 05, 2012 at 12:14:03PM +0100, Rui Nuno Capela wrote:
>>
>>> from what I read on the NSM User&  API specs. you can only create new,
>>> open and save NSM-managed sessions as in each participating client
>>> project's sub-directories. existing individual projects are out of the
>>> picture. unless you "cheat" the NSM o.O
>>>
>>> iow. what if, assuming Ardour were about a fully-compliant NSM client
>>> and you want to open an existing Ardour session, one you've been working
>>> hard previously but stand-lone ie. outside the NSM umbrella? i read that
>>> you'll have to copy or move all ardour's session files _manually_ first,
>>> or symlink at best, into the NSM's central/root directory and guess what
>>> and where. that's the kind of "cheat" or "juggling" i was telling you
>>> about :)
>>
>> You have a project of application A, created without NSM, and the project
>> is saved in P (a single file, or a directory).
>>
>> You want to use P as part of an NSM session. Note that this scenario means
>> that A has some button to select if it runs under NSM or not. Let's assume
>> that the default is to run stand-alone.
>>
>> There are two ways to do this:
>>
>> 1. ('Load' and 'New' are disabled when running NSM)
>>
>> * Start A.
>> * Load  P.
>> * Connect A to NSM. Application A will receive a path indicating
>>    where to save its current project. The actual message is 'open',
>>    but since there is nothing to open at the given path the only
>>    sensible thing to do is to put the current project there.
>>    App. A can do so immediately, and then continue as normal.
>>    The whole thing amounts to a 'Save as' [*] with the name given
>>    by NSM instead of the user. So it's really nothing new.
>>
>>
>> 2. ('Load' and 'New' are not disabled but the application knows
>>      how to handle then when running under NSM)
>>
>> * Start A.
>> * Connect A to NSM. App. A will receive a path indicating where to
>>    save the its project. Since A is now running under NSM, it remembers
>>    this path as the 'current project' even when it loads another one,
>>    or creates a complete new one (under these condition A is allowed
>>    to have 'Load' and 'New' menu entries).
>> * Load P. App A knows that it should not save to P, but to the path
>>    given by NSM. To keep things simple, it could copy P to that path
>>    immediately and then continue as normal. Again this is essentially
>>    a 'Save as'.
>>
>>
>> The only difference between the two is that in (2) the second and
>> third steps are swapped.
>>
>> No 'manual' user action is required in either case.
> >
> > [*] 'Save as' interpreted as most apps would, not as Ardour does it.
> > In Ardour, 'Save as' does not create a new project but a snapshot,
> > while setting the current name to that snapshot.
> >
>
> so true, and ain't that something? you actually need the native-open and  
> save(as...) commands enabled after all o.O

No, where do you get that ? Did you actually read what you comment on
and think about it for a second or two ? In case (1) both are disabled
while in managed mode. In case (2) 'Load' (or 'Open') is enabled (but
behaves slightly differently) and 'Save as' is disabled (in the menu,
the function is still used, to save to the path given by NSM).


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)


--===============6447327021208905795==--


From rncbc@rncbc.org Thu Apr  5 16:19:46 2012
From: Rui Nuno Capela <rncbc@rncbc.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Thu, 05 Apr 2012 16:19:46 +0000
Message-ID: <4F7DC643.5070200@rncbc.org>
In-Reply-To: <20120405144854.GA24754@linuxaudio.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7240924304511040233=="

--===============7240924304511040233==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/05/2012 03:48 PM, Fons Adriaensen wrote:
> On Thu, Apr 05, 2012 at 03:19:24PM +0100, Rui Nuno Capela wrote:
>> On 04/05/2012 01:16 PM, Fons Adriaensen wrote:
>>> On Thu, Apr 05, 2012 at 12:14:03PM +0100, Rui Nuno Capela wrote:
>>>
>>>> from what I read on the NSM User&   API specs. you can only create new,
>>>> open and save NSM-managed sessions as in each participating client
>>>> project's sub-directories. existing individual projects are out of the
>>>> picture. unless you "cheat" the NSM o.O
>>>>
>>>> iow. what if, assuming Ardour were about a fully-compliant NSM client
>>>> and you want to open an existing Ardour session, one you've been working
>>>> hard previously but stand-lone ie. outside the NSM umbrella? i read that
>>>> you'll have to copy or move all ardour's session files _manually_ first,
>>>> or symlink at best, into the NSM's central/root directory and guess what
>>>> and where. that's the kind of "cheat" or "juggling" i was telling you
>>>> about :)
>>>
>>> You have a project of application A, created without NSM, and the project
>>> is saved in P (a single file, or a directory).
>>>
>>> You want to use P as part of an NSM session. Note that this scenario means
>>> that A has some button to select if it runs under NSM or not. Let's assume
>>> that the default is to run stand-alone.
>>>
>>> There are two ways to do this:
>>>
>>> 1. ('Load' and 'New' are disabled when running NSM)
>>>
>>> * Start A.
>>> * Load  P.
>>> * Connect A to NSM. Application A will receive a path indicating
>>>     where to save its current project. The actual message is 'open',
>>>     but since there is nothing to open at the given path the only
>>>     sensible thing to do is to put the current project there.
>>>     App. A can do so immediately, and then continue as normal.
>>>     The whole thing amounts to a 'Save as' [*] with the name given
>>>     by NSM instead of the user. So it's really nothing new.
>>>
>>>
>>> 2. ('Load' and 'New' are not disabled but the application knows
>>>       how to handle then when running under NSM)
>>>
>>> * Start A.
>>> * Connect A to NSM. App. A will receive a path indicating where to
>>>     save the its project. Since A is now running under NSM, it remembers
>>>     this path as the 'current project' even when it loads another one,
>>>     or creates a complete new one (under these condition A is allowed
>>>     to have 'Load' and 'New' menu entries).
>>> * Load P. App A knows that it should not save to P, but to the path
>>>     given by NSM. To keep things simple, it could copy P to that path
>>>     immediately and then continue as normal. Again this is essentially
>>>     a 'Save as'.
>>>
>>>
>>> The only difference between the two is that in (2) the second and
>>> third steps are swapped.
>>>
>>> No 'manual' user action is required in either case.
>>>
>>> [*] 'Save as' interpreted as most apps would, not as Ardour does it.
>>> In Ardour, 'Save as' does not create a new project but a snapshot,
>>> while setting the current name to that snapshot.
>>>
>>
>> so true, and ain't that something? you actually need the native-open and
>> save(as...) commands enabled after all o.O
>
> No, where do you get that ? Did you actually read what you comment on
> and think about it for a second or two ? In case (1) both are disabled
> while in managed mode. In case (2) 'Load' (or 'Open') is enabled (but
> behaves slightly differently) and 'Save as' is disabled (in the menu,
> the function is still used, to save to the path given by NSM).
>

ah ok, sorry. scrap (1) then

re. (2) then i concur with you when "Open" and "Save(As...)" shall be 
enabled *but* having different code-paths, behavior or internal 
semantics if you prefer, when in "managed" than in native/original aka. 
"non-managed" modes. chalked!

we might disagree however on that "slightly" part, though. i understand 
that's behavior as seen from user pov. but under the hood things might 
just not be that "slight"... the usual ymmv applies ;)

ps. i know you're not found of jack-session Fons, but ntl. fwiw. 
qtractor has been making that distinction when serving jack-session 
requests, for almost 2 years now :P

cheers
-- 
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org

--===============7240924304511040233==--


From d@drobilla.net Thu Apr  5 17:10:27 2012
From: David Robillard <d@drobilla.net>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Thu, 05 Apr 2012 17:10:27 +0000
Message-ID: <1333645824.23779.9.camel@verne.drobilla.net>
In-Reply-To: <4F7DC643.5070200@rncbc.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1693370570950320281=="

--===============1693370570950320281==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Thu, 2012-04-05 at 17:20 +0100, Rui Nuno Capela wrote:
[...]
> re. (2) then i concur with you when "Open" and "Save(As...)" shall be 
> enabled *but* having different code-paths, behavior or internal 
> semantics if you prefer, when in "managed" than in native/original aka. 
> "non-managed" modes. chalked!

?

The app performing an action similar or identical to what "Save As"
might do is a completely different thing to the "Save As" menu item
being available to the user...

-dr



--===============1693370570950320281==--


From d@drobilla.net Thu Apr  5 17:48:13 2012
From: David Robillard <d@drobilla.net>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Thu, 05 Apr 2012 17:48:13 +0000
Message-ID: <1333648083.23779.41.camel@verne.drobilla.net>
In-Reply-To: <4F7D7E7B.7010801@rncbc.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4022191904508378107=="

--===============4022191904508378107==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Thu, 2012-04-05 at 12:14 +0100, Rui Nuno Capela wrote:
> On 04/05/2012 12:25 AM, David Robillard wrote:
> > On Tue, 2012-04-03 at 18:04 +0100, Rui Nuno Capela wrote:
> > [...]
> >> ardour gets all its stuff under one own session directory, on a per
> >> session/project basis, iirc just like NSM mandates,
> >>
> >> bbbuuuuuut...:) making that one and the same directory as from an
> >> outsider/independent session manager like NSM is asking for a lot of
> >> file and symlink juggling, if you ask me
[...]
> > A directory of files is a directory of files.  The format Ardour would
> > save to inside of a session is precisely the same format it already
> > saves in, perhaps with some things being links.
[...]
> ok then.
> 
> but again, i was implying about the NSM session directory location 
> restriction, not ardour's session/project directory/file format.

... You specifically asked for input about Ardour's directories.

You keep calling the *goal* here a "restriction".  Look, if you want to
just save an XML file with references to files who knows where, feel
free.  Nobody is going to break in to your house and hold a gun to your
head and make you do otherwise.

However, then any session containing qtractor will be fragile and
unarchivable.  Why?  Because the way you saved INHERENTLY makes that so.

This isn't some arbitrary NSM "restriction" to make Rui Nuno Capela's
life miserable, it's simply a necessary condition to make the desired
behaviour possible.

> iow. what if, assuming Ardour were about a fully-compliant NSM client 
> and you want to open an existing Ardour session, one you've been working 
> hard previously but stand-lone ie. outside the NSM umbrella? i read that 
> you'll have to copy or move all ardour's session files _manually_ first, 
> or symlink at best, into the NSM's central/root directory and guess what 
> and where. that's the kind of "cheat" or "juggling" i was telling you 
> about :)

I agree that "open" should clearly work.  The same amount of juggling
would have to happen regardless.

> otoh, if its native(gui file menu)-open is available, it would be dead 
> simple to get an existing qtractor project into a NSM session and 
> behold: later, the NSM would just save (a new stanza) of the qtractor 
> session/state file under the SM's designated central directory location 
> and that's perfect for qtractor, see? because all qtractor media content 
> files are external and independent of the state file. and if you (the 
> user) selects the archive/zip bundle format (.qtz suffix) as default, 
> then we'll get *all* qtractor project stuff under the nominated NSM 
> session directory tree (already compressed into one single archive/zip 
> file, though)

Assuming, conveniently, that all existing sessions are not archived
(.qtz) and all SM ones are.  Otherwise, it's the exact same situation as
any other program.  Notably, in this scheme, it's exactly the same for
any qtractor session saved within the SM.  Same as Ardour but you tarred
it.

> perhaps, automatic symlinking of all the external files could be also 
> doable at the NSM-Save instant, 'coz qtractor state is, among other 
> important things, an inventory map of all those files anyway--some 
> invasive coding required, though ;)
> 
> looks like, after all, that qtractor could stand compliant to both NSM 
> levels 0 and 1+, in one fine blow, only if those file menu restrictions 
> get subverted or just plainly ignored:o) and all the code to comply with 
> the basic NSM API announce, open, save, close... gets eventually coded 
> in, of course

One fine blow that just so happens to be qtractor *not* saving in the
way you are so vehemently defending ;)

> aha. this seems the case for "edgy" applications like qtractor, when 
> their own file new, open, save, and save as... menu operations are made 
> completely orthogonal and independent of any general SM open/save ones.
> 
> try that with the not-so-edgy (mainstream?) applications ;)

It's not any different for any applications, loading existing stuff is
loading existing stuff.  Things will indeed need to be copied or moved.
Unfortunate, perhaps, but necessary.

Your knee-jerk desire to defend qtractor's saving scheme at all costs
with a death-by-emoticon blitzkrieg is obscuring the fact that all of
this is inherent to session management.  Qtractor has problems with it
because qtractor has problems with it.  There is no working scheme
qtractor would have less problems with, because they are inherent
problems with qtractor + SM, not the SM itself.

Back in the realm of "solving problems" rather than "inflating egos",
there are two approaches you can use:

1) Completely save everything within the SM directory
2) Make your XML file point to links in the SM directory which point to
the configured store location

Sound familiar?  It should, because it's precisely what every other app
has to do to refer to "external files".  Qtractor just uses every file
as external files.

Of course, number 2 is completely pointless and silly unless sessions
share these files, but that doesn't really matter.  The solution is the
same in any case.

You may not particularly like this because qtractor does not currently
save in either way, meaning you have to implement a new saving scheme,
but... well, qtractor simply doesn't currently save in a way that makes
SM work.  To make it do so, yep, obviously gonna be a bit of work,
because it doesn't right now.

If you don't want to support it, then simply don't support it, but don't
try to paint that as a failing of the SM.  It's not.

-dr



--===============4022191904508378107==--


From linux-audio-dev@windows3.de Thu Apr  5 18:11:07 2012
From: Dennis Schulmeister <linux-audio-dev@windows3.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Thu, 05 Apr 2012 18:11:07 +0000
Message-ID: <20120405201101.6cedf9af58b0dd753953aed9@windows3.de>
In-Reply-To: <4F7D7E7B.7010801@rncbc.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4870738938687747796=="

--===============4870738938687747796==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Thu, 05 Apr 2012 12:14:03 +0100
Rui Nuno Capela <rncbc(a)rncbc.org> wrote:

> iow. what if, assuming Ardour were about a fully-compliant NSM client 
> and you want to open an existing Ardour session, one you've been working 
> hard previously but stand-lone ie. outside the NSM umbrella? i read that 
> you'll have to copy or move all ardour's session files _manually_ first, 
> or symlink at best, into the NSM's central/root directory and guess what 
> and where. that's the kind of "cheat" or "juggling" i was telling you 
> about :)

Good point. As far as I remember this is covered the NSM API, though.
It says that "New", "Open, and "Save/Save As" commands have to by
disabled while it is perfectly fine to offer a command "to import the
state of an existing project". So you get a new managed project but
with all state imported from an already existing possibly unmanaged
project.


Yours sincerely,
Dennis Schulmeister

-- 
Dennis Schulmeister - Schifferstr. 1 - 76189 Karlsruhe - Germany
Tel: +49 721/5978883 - Fax: +49 721/5978882 -  Mob: +49 152/01994400
eMail: dennis(a)windows3.de - web: there-is.no-ip.org

--===============4870738938687747796==--


From malnourite@gmail.com Thu Apr  5 18:14:59 2012
From: "J. Liles" <malnourite@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Thu, 05 Apr 2012 18:14:59 +0000
Message-ID:
 <CAGhWSSbOtM7Ps1pTVHmBbuzugGNp+Ct7tO_=3TMhP5LeDyLyfQ@mail.gmail.com>
In-Reply-To: <1333648083.23779.41.camel@verne.drobilla.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3462274340207236349=="

--===============3462274340207236349==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Thu, Apr 5, 2012 at 10:48 AM, David Robillard <d(a)drobilla.net> wrote:

> On Thu, 2012-04-05 at 12:14 +0100, Rui Nuno Capela wrote:
> > On 04/05/2012 12:25 AM, David Robillard wrote:
> > > On Tue, 2012-04-03 at 18:04 +0100, Rui Nuno Capela wrote:
> > > [...]
> > >> ardour gets all its stuff under one own session directory, on a per
> > >> session/project basis, iirc just like NSM mandates,
> > >>
> > >> bbbuuuuuut...:) making that one and the same directory as from an
> > >> outsider/independent session manager like NSM is asking for a lot of
> > >> file and symlink juggling, if you ask me
> [...]
> > > A directory of files is a directory of files.  The format Ardour would
> > > save to inside of a session is precisely the same format it already
> > > saves in, perhaps with some things being links.
> [...]
> > ok then.
> >
> > but again, i was implying about the NSM session directory location
> > restriction, not ardour's session/project directory/file format.
>
> ... You specifically asked for input about Ardour's directories.
>
> You keep calling the *goal* here a "restriction".  Look, if you want to
> just save an XML file with references to files who knows where, feel
> free.  Nobody is going to break in to your house and hold a gun to your
> head and make you do otherwise.
>
> However, then any session containing qtractor will be fragile and
> unarchivable.  Why?  Because the way you saved INHERENTLY makes that so.
>
> This isn't some arbitrary NSM "restriction" to make Rui Nuno Capela's
> life miserable, it's simply a necessary condition to make the desired
> behaviour possible.
>
> > iow. what if, assuming Ardour were about a fully-compliant NSM client
> > and you want to open an existing Ardour session, one you've been working
> > hard previously but stand-lone ie. outside the NSM umbrella? i read that
> > you'll have to copy or move all ardour's session files _manually_ first,
> > or symlink at best, into the NSM's central/root directory and guess what
> > and where. that's the kind of "cheat" or "juggling" i was telling you
> > about :)
>
> I agree that "open" should clearly work.  The same amount of juggling
> would have to happen regardless.
>
> > otoh, if its native(gui file menu)-open is available, it would be dead
> > simple to get an existing qtractor project into a NSM session and
> > behold: later, the NSM would just save (a new stanza) of the qtractor
> > session/state file under the SM's designated central directory location
> > and that's perfect for qtractor, see? because all qtractor media content
> > files are external and independent of the state file. and if you (the
> > user) selects the archive/zip bundle format (.qtz suffix) as default,
> > then we'll get *all* qtractor project stuff under the nominated NSM
> > session directory tree (already compressed into one single archive/zip
> > file, though)
>
> Assuming, conveniently, that all existing sessions are not archived
> (.qtz) and all SM ones are.  Otherwise, it's the exact same situation as
> any other program.  Notably, in this scheme, it's exactly the same for
> any qtractor session saved within the SM.  Same as Ardour but you tarred
> it.
>
> > perhaps, automatic symlinking of all the external files could be also
> > doable at the NSM-Save instant, 'coz qtractor state is, among other
> > important things, an inventory map of all those files anyway--some
> > invasive coding required, though ;)
> >
> > looks like, after all, that qtractor could stand compliant to both NSM
> > levels 0 and 1+, in one fine blow, only if those file menu restrictions
> > get subverted or just plainly ignored:o) and all the code to comply with
> > the basic NSM API announce, open, save, close... gets eventually coded
> > in, of course
>
> One fine blow that just so happens to be qtractor *not* saving in the
> way you are so vehemently defending ;)
>
> > aha. this seems the case for "edgy" applications like qtractor, when
> > their own file new, open, save, and save as... menu operations are made
> > completely orthogonal and independent of any general SM open/save ones.
> >
> > try that with the not-so-edgy (mainstream?) applications ;)
>
> It's not any different for any applications, loading existing stuff is
> loading existing stuff.  Things will indeed need to be copied or moved.
> Unfortunate, perhaps, but necessary.
>
> Your knee-jerk desire to defend qtractor's saving scheme at all costs
> with a death-by-emoticon blitzkrieg is obscuring the fact that all of
> this is inherent to session management.  Qtractor has problems with it
> because qtractor has problems with it.  There is no working scheme
> qtractor would have less problems with, because they are inherent
> problems with qtractor + SM, not the SM itself.
>
> Back in the realm of "solving problems" rather than "inflating egos",
> there are two approaches you can use:
>
> 1) Completely save everything within the SM directory
> 2) Make your XML file point to links in the SM directory which point to
> the configured store location
>
> Sound familiar?  It should, because it's precisely what every other app
> has to do to refer to "external files".  Qtractor just uses every file
> as external files.
>
> Of course, number 2 is completely pointless and silly unless sessions
> share these files, but that doesn't really matter.  The solution is the
> same in any case.
>
> You may not particularly like this because qtractor does not currently
> save in either way, meaning you have to implement a new saving scheme,
> but... well, qtractor simply doesn't currently save in a way that makes
> SM work.  To make it do so, yep, obviously gonna be a bit of work,
> because it doesn't right now.
>
> If you don't want to support it, then simply don't support it, but don't
> try to paint that as a failing of the SM.  It's not.
>
> -dr
>
>
Dealing with existing projects is what the optional "Import to Session" and
"Export from Session" commands are there for. These are basically Open and
Save As but with *defined* semantics.

Anyway, FWIW the way I imported all my pre-existing project to NSM was very
simple:

1) Create a new session and add all the clients you used in your
non-managed setup.
2) Close that session and overwrite the the uniquely named project
files/directories that the NSM clients have created with the ones from your
non-managed-setup
3) Open the project and restore JACK connections (either manually or with
some other patchbay) and save so that JACKPatch will know the graph.
4) Rinse and repeat for other pre-existing projects.

Since the system was designed to work with the Unix files/directories model
(instead of e.g. a database), I don't consider the user mv'ing, symlinking
etc to be hacks, but just normal usage.

Depending on how organized your pre-existing projects were, much of this
can be automated with scripting. If a client implements an Import to
Session menu option, then basically it would just have to do the cp or mv
itself (or if it lacks heavy state, then just open the file and be prepared
to save it under the NSM path when the time comes.) But the SM has nothing
to do with it.



--===============3462274340207236349==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBUaHUsIEFwciA1LCAyMDEyIGF0IDEwOjQ4
IEFNLCBEYXZpZCBSb2JpbGxhcmQgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86
ZEBkcm9iaWxsYS5uZXQiPmRAZHJvYmlsbGEubmV0PC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj48
YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDti
b3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4KPGRpdiBjbGFzcz0i
aW0iPk9uIFRodSwgMjAxMi0wNC0wNSBhdCAxMjoxNCArMDEwMCwgUnVpIE51bm8gQ2FwZWxhIHdy
b3RlOjxicj4KJmd0OyBPbiAwNC8wNS8yMDEyIDEyOjI1IEFNLCBEYXZpZCBSb2JpbGxhcmQgd3Jv
dGU6PGJyPgomZ3Q7ICZndDsgT24gVHVlLCAyMDEyLTA0LTAzIGF0IDE4OjA0ICswMTAwLCBSdWkg
TnVubyBDYXBlbGEgd3JvdGU6PGJyPgomZ3Q7ICZndDsgWy4uLl08YnI+CiZndDsgJmd0OyZndDsg
YXJkb3VyIGdldHMgYWxsIGl0cyBzdHVmZiB1bmRlciBvbmUgb3duIHNlc3Npb24gZGlyZWN0b3J5
LCBvbiBhIHBlcjxicj4KJmd0OyAmZ3Q7Jmd0OyBzZXNzaW9uL3Byb2plY3QgYmFzaXMsIGlpcmMg
anVzdCBsaWtlIE5TTSBtYW5kYXRlcyw8YnI+CiZndDsgJmd0OyZndDs8YnI+CiZndDsgJmd0OyZn
dDsgYmJidXV1dXV1dC4uLjopIG1ha2luZyB0aGF0IG9uZSBhbmQgdGhlIHNhbWUgZGlyZWN0b3J5
IGFzIGZyb20gYW48YnI+CiZndDsgJmd0OyZndDsgb3V0c2lkZXIvaW5kZXBlbmRlbnQgc2Vzc2lv
biBtYW5hZ2VyIGxpa2UgTlNNIGlzIGFza2luZyBmb3IgYSBsb3Qgb2Y8YnI+CiZndDsgJmd0OyZn
dDsgZmlsZSBhbmQgc3ltbGluayBqdWdnbGluZywgaWYgeW91IGFzayBtZTxicj4KPC9kaXY+Wy4u
Ll08YnI+CjxkaXYgY2xhc3M9ImltIj4mZ3Q7ICZndDsgQSBkaXJlY3Rvcnkgb2YgZmlsZXMgaXMg
YSBkaXJlY3Rvcnkgb2YgZmlsZXMuIMKgVGhlIGZvcm1hdCBBcmRvdXIgd291bGQ8YnI+CiZndDsg
Jmd0OyBzYXZlIHRvIGluc2lkZSBvZiBhIHNlc3Npb24gaXMgcHJlY2lzZWx5IHRoZSBzYW1lIGZv
cm1hdCBpdCBhbHJlYWR5PGJyPgomZ3Q7ICZndDsgc2F2ZXMgaW4sIHBlcmhhcHMgd2l0aCBzb21l
IHRoaW5ncyBiZWluZyBsaW5rcy48YnI+CjwvZGl2PlsuLi5dPGJyPgo8ZGl2IGNsYXNzPSJpbSI+
Jmd0OyBvayB0aGVuLjxicj4KJmd0Ozxicj4KJmd0OyBidXQgYWdhaW4sIGkgd2FzIGltcGx5aW5n
IGFib3V0IHRoZSBOU00gc2Vzc2lvbiBkaXJlY3RvcnkgbG9jYXRpb248YnI+CiZndDsgcmVzdHJp
Y3Rpb24sIG5vdCBhcmRvdXImIzM5O3Mgc2Vzc2lvbi9wcm9qZWN0IGRpcmVjdG9yeS9maWxlIGZv
cm1hdC48YnI+Cjxicj4KPC9kaXY+Li4uIFlvdSBzcGVjaWZpY2FsbHkgYXNrZWQgZm9yIGlucHV0
IGFib3V0IEFyZG91ciYjMzk7cyBkaXJlY3Rvcmllcy48YnI+Cjxicj4KWW91IGtlZXAgY2FsbGlu
ZyB0aGUgKmdvYWwqIGhlcmUgYSAmcXVvdDtyZXN0cmljdGlvbiZxdW90Oy4gwqBMb29rLCBpZiB5
b3Ugd2FudCB0bzxicj4KanVzdCBzYXZlIGFuIFhNTCBmaWxlIHdpdGggcmVmZXJlbmNlcyB0byBm
aWxlcyB3aG8ga25vd3Mgd2hlcmUsIGZlZWw8YnI+CmZyZWUuIMKgTm9ib2R5IGlzIGdvaW5nIHRv
IGJyZWFrIGluIHRvIHlvdXIgaG91c2UgYW5kIGhvbGQgYSBndW4gdG8geW91cjxicj4KaGVhZCBh
bmQgbWFrZSB5b3UgZG8gb3RoZXJ3aXNlLjxicj4KPGJyPgpIb3dldmVyLCB0aGVuIGFueSBzZXNz
aW9uIGNvbnRhaW5pbmcgcXRyYWN0b3Igd2lsbCBiZSBmcmFnaWxlIGFuZDxicj4KdW5hcmNoaXZh
YmxlLiDCoFdoeT8gwqBCZWNhdXNlIHRoZSB3YXkgeW91IHNhdmVkIElOSEVSRU5UTFkgbWFrZXMg
dGhhdCBzby48YnI+Cjxicj4KVGhpcyBpc24mIzM5O3Qgc29tZSBhcmJpdHJhcnkgTlNNICZxdW90
O3Jlc3RyaWN0aW9uJnF1b3Q7IHRvIG1ha2UgUnVpIE51bm8gQ2FwZWxhJiMzOTtzPGJyPgpsaWZl
IG1pc2VyYWJsZSwgaXQmIzM5O3Mgc2ltcGx5IGEgbmVjZXNzYXJ5IGNvbmRpdGlvbiB0byBtYWtl
IHRoZSBkZXNpcmVkPGJyPgpiZWhhdmlvdXIgcG9zc2libGUuPGJyPgo8ZGl2IGNsYXNzPSJpbSI+
PGJyPgomZ3Q7IGlvdy4gd2hhdCBpZiwgYXNzdW1pbmcgQXJkb3VyIHdlcmUgYWJvdXQgYSBmdWxs
eS1jb21wbGlhbnQgTlNNIGNsaWVudDxicj4KJmd0OyBhbmQgeW91IHdhbnQgdG8gb3BlbiBhbiBl
eGlzdGluZyBBcmRvdXIgc2Vzc2lvbiwgb25lIHlvdSYjMzk7dmUgYmVlbiB3b3JraW5nPGJyPgom
Z3Q7IGhhcmQgcHJldmlvdXNseSBidXQgc3RhbmQtbG9uZSBpZS4gb3V0c2lkZSB0aGUgTlNNIHVt
YnJlbGxhPyBpIHJlYWQgdGhhdDxicj4KJmd0OyB5b3UmIzM5O2xsIGhhdmUgdG8gY29weSBvciBt
b3ZlIGFsbCBhcmRvdXImIzM5O3Mgc2Vzc2lvbiBmaWxlcyBfbWFudWFsbHlfIGZpcnN0LDxicj4K
Jmd0OyBvciBzeW1saW5rIGF0IGJlc3QsIGludG8gdGhlIE5TTSYjMzk7cyBjZW50cmFsL3Jvb3Qg
ZGlyZWN0b3J5IGFuZCBndWVzcyB3aGF0PGJyPgomZ3Q7IGFuZCB3aGVyZS4gdGhhdCYjMzk7cyB0
aGUga2luZCBvZiAmcXVvdDtjaGVhdCZxdW90OyBvciAmcXVvdDtqdWdnbGluZyZxdW90OyBpIHdh
cyB0ZWxsaW5nIHlvdTxicj4KJmd0OyBhYm91dCA6KTxicj4KPGJyPgo8L2Rpdj5JIGFncmVlIHRo
YXQgJnF1b3Q7b3BlbiZxdW90OyBzaG91bGQgY2xlYXJseSB3b3JrLiDCoFRoZSBzYW1lIGFtb3Vu
dCBvZiBqdWdnbGluZzxicj4Kd291bGQgaGF2ZSB0byBoYXBwZW4gcmVnYXJkbGVzcy48YnI+Cjxk
aXYgY2xhc3M9ImltIj48YnI+CiZndDsgb3RvaCwgaWYgaXRzIG5hdGl2ZShndWkgZmlsZSBtZW51
KS1vcGVuIGlzIGF2YWlsYWJsZSwgaXQgd291bGQgYmUgZGVhZDxicj4KJmd0OyBzaW1wbGUgdG8g
Z2V0IGFuIGV4aXN0aW5nIHF0cmFjdG9yIHByb2plY3QgaW50byBhIE5TTSBzZXNzaW9uIGFuZDxi
cj4KJmd0OyBiZWhvbGQ6IGxhdGVyLCB0aGUgTlNNIHdvdWxkIGp1c3Qgc2F2ZSAoYSBuZXcgc3Rh
bnphKSBvZiB0aGUgcXRyYWN0b3I8YnI+CiZndDsgc2Vzc2lvbi9zdGF0ZSBmaWxlIHVuZGVyIHRo
ZSBTTSYjMzk7cyBkZXNpZ25hdGVkIGNlbnRyYWwgZGlyZWN0b3J5IGxvY2F0aW9uPGJyPgomZ3Q7
IGFuZCB0aGF0JiMzOTtzIHBlcmZlY3QgZm9yIHF0cmFjdG9yLCBzZWU/IGJlY2F1c2UgYWxsIHF0
cmFjdG9yIG1lZGlhIGNvbnRlbnQ8YnI+CiZndDsgZmlsZXMgYXJlIGV4dGVybmFsIGFuZCBpbmRl
cGVuZGVudCBvZiB0aGUgc3RhdGUgZmlsZS4gYW5kIGlmIHlvdSAodGhlPGJyPgomZ3Q7IHVzZXIp
IHNlbGVjdHMgdGhlIGFyY2hpdmUvemlwIGJ1bmRsZSBmb3JtYXQgKC5xdHogc3VmZml4KSBhcyBk
ZWZhdWx0LDxicj4KJmd0OyB0aGVuIHdlJiMzOTtsbCBnZXQgKmFsbCogcXRyYWN0b3IgcHJvamVj
dCBzdHVmZiB1bmRlciB0aGUgbm9taW5hdGVkIE5TTTxicj4KJmd0OyBzZXNzaW9uIGRpcmVjdG9y
eSB0cmVlIChhbHJlYWR5IGNvbXByZXNzZWQgaW50byBvbmUgc2luZ2xlIGFyY2hpdmUvemlwPGJy
PgomZ3Q7IGZpbGUsIHRob3VnaCk8YnI+Cjxicj4KPC9kaXY+QXNzdW1pbmcsIGNvbnZlbmllbnRs
eSwgdGhhdCBhbGwgZXhpc3Rpbmcgc2Vzc2lvbnMgYXJlIG5vdCBhcmNoaXZlZDxicj4KKC5xdHop
IGFuZCBhbGwgU00gb25lcyBhcmUuIMKgT3RoZXJ3aXNlLCBpdCYjMzk7cyB0aGUgZXhhY3Qgc2Ft
ZSBzaXR1YXRpb24gYXM8YnI+CmFueSBvdGhlciBwcm9ncmFtLiDCoE5vdGFibHksIGluIHRoaXMg
c2NoZW1lLCBpdCYjMzk7cyBleGFjdGx5IHRoZSBzYW1lIGZvcjxicj4KYW55IHF0cmFjdG9yIHNl
c3Npb24gc2F2ZWQgd2l0aGluIHRoZSBTTS4gwqBTYW1lIGFzIEFyZG91ciBidXQgeW91IHRhcnJl
ZDxicj4KaXQuPGJyPgo8ZGl2IGNsYXNzPSJpbSI+PGJyPgomZ3Q7IHBlcmhhcHMsIGF1dG9tYXRp
YyBzeW1saW5raW5nIG9mIGFsbCB0aGUgZXh0ZXJuYWwgZmlsZXMgY291bGQgYmUgYWxzbzxicj4K
Jmd0OyBkb2FibGUgYXQgdGhlIE5TTS1TYXZlIGluc3RhbnQsICYjMzk7Y296IHF0cmFjdG9yIHN0
YXRlIGlzLCBhbW9uZyBvdGhlcjxicj4KJmd0OyBpbXBvcnRhbnQgdGhpbmdzLCBhbiBpbnZlbnRv
cnkgbWFwIG9mIGFsbCB0aG9zZSBmaWxlcyBhbnl3YXktLXNvbWU8YnI+CiZndDsgaW52YXNpdmUg
Y29kaW5nIHJlcXVpcmVkLCB0aG91Z2ggOyk8YnI+CiZndDs8YnI+CiZndDsgbG9va3MgbGlrZSwg
YWZ0ZXIgYWxsLCB0aGF0IHF0cmFjdG9yIGNvdWxkIHN0YW5kIGNvbXBsaWFudCB0byBib3RoIE5T
TTxicj4KJmd0OyBsZXZlbHMgMCBhbmQgMSssIGluIG9uZSBmaW5lIGJsb3csIG9ubHkgaWYgdGhv
c2UgZmlsZSBtZW51IHJlc3RyaWN0aW9uczxicj4KJmd0OyBnZXQgc3VidmVydGVkIG9yIGp1c3Qg
cGxhaW5seSBpZ25vcmVkOm8pIGFuZCBhbGwgdGhlIGNvZGUgdG8gY29tcGx5IHdpdGg8YnI+CiZn
dDsgdGhlIGJhc2ljIE5TTSBBUEkgYW5ub3VuY2UsIG9wZW4sIHNhdmUsIGNsb3NlLi4uIGdldHMg
ZXZlbnR1YWxseSBjb2RlZDxicj4KJmd0OyBpbiwgb2YgY291cnNlPGJyPgo8YnI+CjwvZGl2Pk9u
ZSBmaW5lIGJsb3cgdGhhdCBqdXN0IHNvIGhhcHBlbnMgdG8gYmUgcXRyYWN0b3IgKm5vdCogc2F2
aW5nIGluIHRoZTxicj4Kd2F5IHlvdSBhcmUgc28gdmVoZW1lbnRseSBkZWZlbmRpbmcgOyk8YnI+
CjxkaXYgY2xhc3M9ImltIj48YnI+CiZndDsgYWhhLiB0aGlzIHNlZW1zIHRoZSBjYXNlIGZvciAm
cXVvdDtlZGd5JnF1b3Q7IGFwcGxpY2F0aW9ucyBsaWtlIHF0cmFjdG9yLCB3aGVuPGJyPgomZ3Q7
IHRoZWlyIG93biBmaWxlIG5ldywgb3Blbiwgc2F2ZSwgYW5kIHNhdmUgYXMuLi4gbWVudSBvcGVy
YXRpb25zIGFyZSBtYWRlPGJyPgomZ3Q7IGNvbXBsZXRlbHkgb3J0aG9nb25hbCBhbmQgaW5kZXBl
bmRlbnQgb2YgYW55IGdlbmVyYWwgU00gb3Blbi9zYXZlIG9uZXMuPGJyPgomZ3Q7PGJyPgomZ3Q7
IHRyeSB0aGF0IHdpdGggdGhlIG5vdC1zby1lZGd5IChtYWluc3RyZWFtPykgYXBwbGljYXRpb25z
IDspPGJyPgo8YnI+CjwvZGl2Pkl0JiMzOTtzIG5vdCBhbnkgZGlmZmVyZW50IGZvciBhbnkgYXBw
bGljYXRpb25zLCBsb2FkaW5nIGV4aXN0aW5nIHN0dWZmIGlzPGJyPgpsb2FkaW5nIGV4aXN0aW5n
IHN0dWZmLiDCoFRoaW5ncyB3aWxsIGluZGVlZCBuZWVkIHRvIGJlIGNvcGllZCBvciBtb3ZlZC48
YnI+ClVuZm9ydHVuYXRlLCBwZXJoYXBzLCBidXQgbmVjZXNzYXJ5Ljxicj4KPGJyPgpZb3VyIGtu
ZWUtamVyayBkZXNpcmUgdG8gZGVmZW5kIHF0cmFjdG9yJiMzOTtzIHNhdmluZyBzY2hlbWUgYXQg
YWxsIGNvc3RzPGJyPgp3aXRoIGEgZGVhdGgtYnktZW1vdGljb24gYmxpdHprcmllZyBpcyBvYnNj
dXJpbmcgdGhlIGZhY3QgdGhhdCBhbGwgb2Y8YnI+CnRoaXMgaXMgaW5oZXJlbnQgdG8gc2Vzc2lv
biBtYW5hZ2VtZW50LiDCoFF0cmFjdG9yIGhhcyBwcm9ibGVtcyB3aXRoIGl0PGJyPgpiZWNhdXNl
IHF0cmFjdG9yIGhhcyBwcm9ibGVtcyB3aXRoIGl0LiDCoFRoZXJlIGlzIG5vIHdvcmtpbmcgc2No
ZW1lPGJyPgpxdHJhY3RvciB3b3VsZCBoYXZlIGxlc3MgcHJvYmxlbXMgd2l0aCwgYmVjYXVzZSB0
aGV5IGFyZSBpbmhlcmVudDxicj4KcHJvYmxlbXMgd2l0aCBxdHJhY3RvciArIFNNLCBub3QgdGhl
IFNNIGl0c2VsZi48YnI+Cjxicj4KQmFjayBpbiB0aGUgcmVhbG0gb2YgJnF1b3Q7c29sdmluZyBw
cm9ibGVtcyZxdW90OyByYXRoZXIgdGhhbiAmcXVvdDtpbmZsYXRpbmcgZWdvcyZxdW90Oyw8YnI+
CnRoZXJlIGFyZSB0d28gYXBwcm9hY2hlcyB5b3UgY2FuIHVzZTo8YnI+Cjxicj4KMSkgQ29tcGxl
dGVseSBzYXZlIGV2ZXJ5dGhpbmcgd2l0aGluIHRoZSBTTSBkaXJlY3Rvcnk8YnI+CjIpIE1ha2Ug
eW91ciBYTUwgZmlsZSBwb2ludCB0byBsaW5rcyBpbiB0aGUgU00gZGlyZWN0b3J5IHdoaWNoIHBv
aW50IHRvPGJyPgp0aGUgY29uZmlndXJlZCBzdG9yZSBsb2NhdGlvbjxicj4KPGJyPgpTb3VuZCBm
YW1pbGlhcj8gwqBJdCBzaG91bGQsIGJlY2F1c2UgaXQmIzM5O3MgcHJlY2lzZWx5IHdoYXQgZXZl
cnkgb3RoZXIgYXBwPGJyPgpoYXMgdG8gZG8gdG8gcmVmZXIgdG8gJnF1b3Q7ZXh0ZXJuYWwgZmls
ZXMmcXVvdDsuIMKgUXRyYWN0b3IganVzdCB1c2VzIGV2ZXJ5IGZpbGU8YnI+CmFzIGV4dGVybmFs
IGZpbGVzLjxicj4KPGJyPgpPZiBjb3Vyc2UsIG51bWJlciAyIGlzIGNvbXBsZXRlbHkgcG9pbnRs
ZXNzIGFuZCBzaWxseSB1bmxlc3Mgc2Vzc2lvbnM8YnI+CnNoYXJlIHRoZXNlIGZpbGVzLCBidXQg
dGhhdCBkb2VzbiYjMzk7dCByZWFsbHkgbWF0dGVyLiDCoFRoZSBzb2x1dGlvbiBpcyB0aGU8YnI+
CnNhbWUgaW4gYW55IGNhc2UuPGJyPgo8YnI+CllvdSBtYXkgbm90IHBhcnRpY3VsYXJseSBsaWtl
IHRoaXMgYmVjYXVzZSBxdHJhY3RvciBkb2VzIG5vdCBjdXJyZW50bHk8YnI+CnNhdmUgaW4gZWl0
aGVyIHdheSwgbWVhbmluZyB5b3UgaGF2ZSB0byBpbXBsZW1lbnQgYSBuZXcgc2F2aW5nIHNjaGVt
ZSw8YnI+CmJ1dC4uLiB3ZWxsLCBxdHJhY3RvciBzaW1wbHkgZG9lc24mIzM5O3QgY3VycmVudGx5
IHNhdmUgaW4gYSB3YXkgdGhhdCBtYWtlczxicj4KU00gd29yay4gwqBUbyBtYWtlIGl0IGRvIHNv
LCB5ZXAsIG9idmlvdXNseSBnb25uYSBiZSBhIGJpdCBvZiB3b3JrLDxicj4KYmVjYXVzZSBpdCBk
b2VzbiYjMzk7dCByaWdodCBub3cuPGJyPgo8YnI+CklmIHlvdSBkb24mIzM5O3Qgd2FudCB0byBz
dXBwb3J0IGl0LCB0aGVuIHNpbXBseSBkb24mIzM5O3Qgc3VwcG9ydCBpdCwgYnV0IGRvbiYjMzk7
dDxicj4KdHJ5IHRvIHBhaW50IHRoYXQgYXMgYSBmYWlsaW5nIG9mIHRoZSBTTS4gwqBJdCYjMzk7
cyBub3QuPGJyPgo8c3BhbiBjbGFzcz0iSE9FblpiIj48Zm9udCBjb2xvcj0iIzg4ODg4OCI+PGJy
PgotZHI8YnI+CjwvZm9udD48L3NwYW4+PGRpdiBjbGFzcz0iSE9FblpiIj48ZGl2IGNsYXNzPSJo
NSI+PGJyPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj5EZWFsaW5nIHdpdGggZXhp
c3RpbmcgcHJvamVjdHMgaXMgd2hhdCB0aGUgb3B0aW9uYWwgJnF1b3Q7SW1wb3J0IHRvIFNlc3Np
b24mcXVvdDsgYW5kICZxdW90O0V4cG9ydCBmcm9tIFNlc3Npb24mcXVvdDsgY29tbWFuZHMgYXJl
IHRoZXJlIGZvci4gVGhlc2UgYXJlIGJhc2ljYWxseSBPcGVuIGFuZCBTYXZlIEFzIGJ1dCB3aXRo
ICpkZWZpbmVkKiBzZW1hbnRpY3MuIDxicj4KPGJyPkFueXdheSwgRldJVyB0aGUgd2F5IEkgaW1w
b3J0ZWQgYWxsIG15IHByZS1leGlzdGluZyBwcm9qZWN0IHRvIE5TTSB3YXMgdmVyeSBzaW1wbGU6
PGJyPjxicj4xKSBDcmVhdGUgYSBuZXcgc2Vzc2lvbiBhbmQgYWRkIGFsbCB0aGUgY2xpZW50cyB5
b3UgdXNlZCBpbiB5b3VyIG5vbi1tYW5hZ2VkIHNldHVwLjxicj4yKSBDbG9zZSB0aGF0IHNlc3Np
b24gYW5kIG92ZXJ3cml0ZSB0aGUgdGhlIHVuaXF1ZWx5IG5hbWVkIHByb2plY3QgZmlsZXMvZGly
ZWN0b3JpZXMgdGhhdCB0aGUgTlNNIGNsaWVudHMgaGF2ZSBjcmVhdGVkIHdpdGggdGhlIG9uZXMg
ZnJvbSB5b3VyIG5vbi1tYW5hZ2VkLXNldHVwPGJyPgozKSBPcGVuIHRoZSBwcm9qZWN0IGFuZCBy
ZXN0b3JlIEpBQ0sgY29ubmVjdGlvbnMgKGVpdGhlciBtYW51YWxseSBvciB3aXRoIHNvbWUgb3Ro
ZXIgcGF0Y2hiYXkpIGFuZCBzYXZlIHNvIHRoYXQgSkFDS1BhdGNoIHdpbGwga25vdyB0aGUgZ3Jh
cGguPGJyPjQpIFJpbnNlIGFuZCByZXBlYXQgZm9yIG90aGVyIHByZS1leGlzdGluZyBwcm9qZWN0
cy48YnI+PGJyPlNpbmNlIHRoZSBzeXN0ZW0gd2FzIGRlc2lnbmVkIHRvIHdvcmsgd2l0aCB0aGUg
VW5peCBmaWxlcy9kaXJlY3RvcmllcyBtb2RlbCAoaW5zdGVhZCBvZiBlLmcuIGEgZGF0YWJhc2Up
LCBJIGRvbiYjMzk7dCBjb25zaWRlciB0aGUgdXNlciBtdiYjMzk7aW5nLCBzeW1saW5raW5nIGV0
YyB0byBiZSBoYWNrcywgYnV0IGp1c3Qgbm9ybWFsIHVzYWdlLjxicj4KPGJyPkRlcGVuZGluZyBv
biBob3cgb3JnYW5pemVkIHlvdXIgcHJlLWV4aXN0aW5nIHByb2plY3RzIHdlcmUsIG11Y2ggb2Yg
dGhpcyBjYW4gYmUgYXV0b21hdGVkIHdpdGggc2NyaXB0aW5nLiBJZiBhIGNsaWVudCBpbXBsZW1l
bnRzIGFuIEltcG9ydCB0byBTZXNzaW9uIG1lbnUgb3B0aW9uLCB0aGVuIGJhc2ljYWxseSBpdCB3
b3VsZCBqdXN0IGhhdmUgdG8gZG8gdGhlIGNwIG9yIG12IGl0c2VsZiAob3IgaWYgaXQgbGFja3Mg
aGVhdnkgc3RhdGUsIHRoZW4ganVzdCBvcGVuIHRoZSBmaWxlIGFuZCBiZSBwcmVwYXJlZCB0byBz
YXZlIGl0IHVuZGVyIHRoZSBOU00gcGF0aCB3aGVuIHRoZSB0aW1lIGNvbWVzLikgQnV0IHRoZSBT
TSBoYXMgbm90aGluZyB0byBkbyB3aXRoIGl0Ljxicj4KPGJyPjxicj7CoDwvZGl2PjwvZGl2Pgo=

--===============3462274340207236349==--


From d@drobilla.net Thu Apr  5 18:56:04 2012
From: David Robillard <d@drobilla.net>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Thu, 05 Apr 2012 18:56:04 +0000
Message-ID: <1333652159.23779.44.camel@verne.drobilla.net>
In-Reply-To:
 <CAGhWSSbOtM7Ps1pTVHmBbuzugGNp+Ct7tO_=3TMhP5LeDyLyfQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8580570940166460590=="

--===============8580570940166460590==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Thu, 2012-04-05 at 11:14 -0700, J. Liles wrote:
[...]
> 
> Dealing with existing projects is what the optional "Import to
> Session" and "Export from Session" commands are there for. These are
> basically Open and Save As but with *defined* semantics. 

My mistake, I was just going by what Rui wrote and didn't refer back.

> Anyway, FWIW the way I imported all my pre-existing project to NSM was
> very simple:
> 
> 1) Create a new session and add all the clients you used in your
> non-managed setup.
> 2) Close that session and overwrite the the uniquely named project
> files/directories that the NSM clients have created with the ones from
> your non-managed-setup
> 3) Open the project and restore JACK connections (either manually or
> with some other patchbay) and save so that JACKPatch will know the
> graph.
> 4) Rinse and repeat for other pre-existing projects.
> 
> Since the system was designed to work with the Unix files/directories
> model (instead of e.g. a database), I don't consider the user mv'ing,
> symlinking etc to be hacks, but just normal usage.
> 
> Depending on how organized your pre-existing projects were, much of
> this can be automated with scripting. If a client implements an Import
> to Session menu option, then basically it would just have to do the cp
> or mv itself (or if it lacks heavy state, then just open the file and
> be prepared to save it under the NSM path when the time comes.) But
> the SM has nothing to do with it.

Makes sense.

>From a user friendly POV it would of course be nice if apps implement
that, though, as you say, the SM has nothing to do with it.  That the
actual stuff that needs to happen is something the user *could* easily
do if they wanted to is a good thing.

-dr




--===============8580570940166460590==--


From andreas.ruge@gmx.de Thu Apr  5 19:15:02 2012
From: Andreas Ruge <andreas.ruge@gmx.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: [LAD] ddptools 0.8.7a released
Date: Thu, 05 Apr 2012 19:15:02 +0000
Message-ID: <4F7DEF28.2030400@gmx.de>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8792848421833492823=="

--===============8792848421833492823==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hello everyone,

I've released ddptools 0.8.7a, a set of command line programs to
create, read and export audio from DDP images. This release fixes a
potentially critical bug in the cue2ddp command and introduces some
minor enhancements:

* when verifying DDP checksums ddpinfo now searches the DDP
directory for checksums files, it supports a variety of file formats
and is known to woek with the checksums generated by md5sum,
ExactFile, Pyramix/Gear, SADiE, Sequoia, Sonoris, Wave Editor, and
DSP Quattro.

* for OSX ddptools now now comes as three-way universal binary
including i386, i86_64 and ppc (32bit)

Details are found at http://ddp.andreasruge.de.

Feedback and testing is very welcome!

Best
Andreas


--===============8792848421833492823==--


From rncbc@rncbc.org Thu Apr  5 20:38:51 2012
From: Rui Nuno Capela <rncbc@rncbc.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Thu, 05 Apr 2012 20:38:51 +0000
Message-ID: <4F7E02F9.3040204@rncbc.org>
In-Reply-To:
 <CAGhWSSbOtM7Ps1pTVHmBbuzugGNp+Ct7tO_=3TMhP5LeDyLyfQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7625322822241715985=="

--===============7625322822241715985==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/05/2012 07:14 PM, J. Liles wrote:
>
> On Thu, Apr 5, 2012 at 10:48 AM, David Robillard <d(a)drobilla.net
> <mailto:d(a)drobilla.net>> wrote:
>
>     On Thu, 2012-04-05 at 12:14 +0100, Rui Nuno Capela wrote:
>      > On 04/05/2012 12:25 AM, David Robillard wrote:
>      > > On Tue, 2012-04-03 at 18:04 +0100, Rui Nuno Capela wrote:
>      > > [...]
>      > >> ardour gets all its stuff under one own session directory, on
>     a per
>      > >> session/project basis, iirc just like NSM mandates,
>      > >>
>      > >> bbbuuuuuut...:) making that one and the same directory as from an
>      > >> outsider/independent session manager like NSM is asking for a
>     lot of
>      > >> file and symlink juggling, if you ask me
>     [...]
>      > > A directory of files is a directory of files.  The format
>     Ardour would
>      > > save to inside of a session is precisely the same format it already
>      > > saves in, perhaps with some things being links.
>     [...]
>      > ok then.
>      >
>      > but again, i was implying about the NSM session directory location
>      > restriction, not ardour's session/project directory/file format.
>
>     ... You specifically asked for input about Ardour's directories.
>
>     You keep calling the *goal* here a "restriction".  Look, if you want to
>     just save an XML file with references to files who knows where, feel
>     free.  Nobody is going to break in to your house and hold a gun to your
>     head and make you do otherwise.
>
>     However, then any session containing qtractor will be fragile and
>     unarchivable.  Why?  Because the way you saved INHERENTLY makes that so.
>
>     This isn't some arbitrary NSM "restriction" to make Rui Nuno Capela's
>     life miserable, it's simply a necessary condition to make the desired
>     behaviour possible.
>
>      > iow. what if, assuming Ardour were about a fully-compliant NSM client
>      > and you want to open an existing Ardour session, one you've been
>     working
>      > hard previously but stand-lone ie. outside the NSM umbrella? i
>     read that
>      > you'll have to copy or move all ardour's session files _manually_
>     first,
>      > or symlink at best, into the NSM's central/root directory and
>     guess what
>      > and where. that's the kind of "cheat" or "juggling" i was telling you
>      > about :)
>
>     I agree that "open" should clearly work.  The same amount of juggling
>     would have to happen regardless.
>
>      > otoh, if its native(gui file menu)-open is available, it would be
>     dead
>      > simple to get an existing qtractor project into a NSM session and
>      > behold: later, the NSM would just save (a new stanza) of the qtractor
>      > session/state file under the SM's designated central directory
>     location
>      > and that's perfect for qtractor, see? because all qtractor media
>     content
>      > files are external and independent of the state file. and if you (the
>      > user) selects the archive/zip bundle format (.qtz suffix) as default,
>      > then we'll get *all* qtractor project stuff under the nominated NSM
>      > session directory tree (already compressed into one single
>     archive/zip
>      > file, though)
>
>     Assuming, conveniently, that all existing sessions are not archived
>     (.qtz) and all SM ones are.  Otherwise, it's the exact same situation as
>     any other program.  Notably, in this scheme, it's exactly the same for
>     any qtractor session saved within the SM.  Same as Ardour but you tarred
>     it.
>
>      > perhaps, automatic symlinking of all the external files could be also
>      > doable at the NSM-Save instant, 'coz qtractor state is, among other
>      > important things, an inventory map of all those files anyway--some
>      > invasive coding required, though ;)
>      >
>      > looks like, after all, that qtractor could stand compliant to
>     both NSM
>      > levels 0 and 1+, in one fine blow, only if those file menu
>     restrictions
>      > get subverted or just plainly ignored:o) and all the code to
>     comply with
>      > the basic NSM API announce, open, save, close... gets eventually
>     coded
>      > in, of course
>
>     One fine blow that just so happens to be qtractor *not* saving in the
>     way you are so vehemently defending ;)
>
>      > aha. this seems the case for "edgy" applications like qtractor, when
>      > their own file new, open, save, and save as... menu operations
>     are made
>      > completely orthogonal and independent of any general SM open/save
>     ones.
>      >
>      > try that with the not-so-edgy (mainstream?) applications ;)
>
>     It's not any different for any applications, loading existing stuff is
>     loading existing stuff.  Things will indeed need to be copied or moved.
>     Unfortunate, perhaps, but necessary.
>
>     Your knee-jerk desire to defend qtractor's saving scheme at all costs
>     with a death-by-emoticon blitzkrieg is obscuring the fact that all of
>     this is inherent to session management.  Qtractor has problems with it
>     because qtractor has problems with it.  There is no working scheme
>     qtractor would have less problems with, because they are inherent
>     problems with qtractor + SM, not the SM itself.
>
>     Back in the realm of "solving problems" rather than "inflating egos",
>     there are two approaches you can use:
>
>     1) Completely save everything within the SM directory
>     2) Make your XML file point to links in the SM directory which point to
>     the configured store location
>
>     Sound familiar?  It should, because it's precisely what every other app
>     has to do to refer to "external files".  Qtractor just uses every file
>     as external files.
>
>     Of course, number 2 is completely pointless and silly unless sessions
>     share these files, but that doesn't really matter.  The solution is the
>     same in any case.
>
>     You may not particularly like this because qtractor does not currently
>     save in either way, meaning you have to implement a new saving scheme,
>     but... well, qtractor simply doesn't currently save in a way that makes
>     SM work.  To make it do so, yep, obviously gonna be a bit of work,
>     because it doesn't right now.
>
>     If you don't want to support it, then simply don't support it, but don't
>     try to paint that as a failing of the SM.  It's not.
>
>     -dr
>
>
> Dealing with existing projects is what the optional "Import to Session"
> and "Export from Session" commands are there for. These are basically
> Open and Save As but with *defined* semantics.
>
> Anyway, FWIW the way I imported all my pre-existing project to NSM was
> very simple:
>
> 1) Create a new session and add all the clients you used in your
> non-managed setup.
> 2) Close that session and overwrite the the uniquely named project
> files/directories that the NSM clients have created with the ones from
> your non-managed-setup
> 3) Open the project and restore JACK connections (either manually or
> with some other patchbay) and save so that JACKPatch will know the graph.
> 4) Rinse and repeat for other pre-existing projects.
>
> Since the system was designed to work with the Unix files/directories
> model (instead of e.g. a database), I don't consider the user mv'ing,
> symlinking etc to be hacks, but just normal usage.
>
> Depending on how organized your pre-existing projects were, much of this
> can be automated with scripting. If a client implements an Import to
> Session menu option, then basically it would just have to do the cp or
> mv itself (or if it lacks heavy state, then just open the file and be
> prepared to save it under the NSM path when the time comes.) But the SM
> has nothing to do with it.
>

so we all agree now that gui file menu "open" and "save as ..." should 
be enabled but with an "import from..." and "export to..." semantics 
respectively, when in managed mode

that concludes the discussion, on my call at least.

byee
-- 
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org

--===============7625322822241715985==--


From Thierry.Coduys@le-hub.org Fri Apr  6 10:33:49 2012
From: Thierry Coduys <Thierry.Coduys@le-hub.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: [LAD] LoMus 2012
Date: Fri, 06 Apr 2012 10:33:49 +0000
Message-ID: <9BF583AA-5B47-4B76-85C6-283D425D65A5@le-hub.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8109122109401941457=="

--===============8109122109401941457==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Appel =C3=A0 contribution / Call for participation
D=C3=A9sol=C3=A9 en cas d=E2=80=99envois multiples / sorry for possible cross=
posting

LoMus 2012

=C3=80 la recherche des logiciels libres pour la cr=C3=A9ation sonore et inte=
rmedia

Pour sa quatri=C3=A8me =C3=A9dition, Lomus 2012 s=E2=80=99adresse =C3=A0 tous=
 ceux qui s=E2=80=99aventurent dans le d=C3=A9veloppement de logiciels libres=
 musicaux ou de logiciels libres qui peuvent contribuer au processus de la cr=
=C3=A9ation musicale.

Un prix sera remis aux logiciels qui font preuve non seulement d=E2=80=99inno=
vation, mais notamment d=E2=80=99inventivit=C3=A9 face aux enjeux actuels de =
la cr=C3=A9ation musicale.

Calendrier
6 avril 2012 - Appel =C3=A0 soumissions
25 avril 2012 - Date limite de soumission des logiciels
30 avril 2012 - Notification d'acceptation
11 mai 2012 - Remise du prix lors des JIM 2012

Info : http://concours.afim-asso.org/
JIM2012 : http://www.jim2012.be


LoMus 2012

In search of open-source software for musical and intermedia creation

For its fourth edition, Lomus 2012 invites music and audio open-source softwa=
re creators to submit original projects that either directly or indirectly co=
ntribute to musical creation.

A prize will be awarded to open-source sofware that proves to be not only inn=
ovatory but also inventive in the present context of music and audio creation.

Calendar
April 6, 2012 - Call for submissions=20
April 25, 2012 - Submission deadline=20
April 30, 2012 - Admission notification=20
May 11, 2012 - JIM Awards Ceremony

Info: http://concours.afim-asso.org/
JIM2012 : http://www.jim2012.be



--===============8109122109401941457==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13
ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z
cGFjZTsgIj5BcHBlbCDgIGNvbnRyaWJ1dGlvbiAvIENhbGwgZm9yIHBhcnRpY2lwYXRpb248YnI+
ROlzb2zpIGVuIGNhcyBkkmVudm9pcyBtdWx0aXBsZXMgLyBzb3JyeSBmb3IgcG9zc2libGUgY3Jv
c3Nwb3N0aW5nPGRpdj48YnI+PC9kaXY+PGRpdj48YiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyAi
PkxvTXVzIDIwMTI8L2I+PGJyPjxkaXY+PGRpdj48ZGl2Pjxicj48YiBzdHlsZT0iZm9udC1zaXpl
OiAxNHB4OyAiPsAgbGEgcmVjaGVyY2hlIGRlcyBsb2dpY2llbHMgbGlicmVzIHBvdXIgbGEgY3Lp
YXRpb24gc29ub3JlIGV0IGludGVybWVkaWE8L2I+PGJyIHN0eWxlPSJmb250LXNpemU6IDEzcHg7
ICI+PGJyPlBvdXIgc2EgcXVhdHJp6G1lIOlkaXRpb24sIExvbXVzIDIwMTIgc5JhZHJlc3NlIOAg
dG91cyBjZXV4IHF1aSBzkmF2ZW50dXJlbnQgZGFucyBsZSBk6XZlbG9wcGVtZW50IGRlIGxvZ2lj
aWVscyBsaWJyZXMgbXVzaWNhdXggb3UgZGUgbG9naWNpZWxzIGxpYnJlcyBxdWkmbmJzcDtwZXV2
ZW50IGNvbnRyaWJ1ZXIgYXUgcHJvY2Vzc3VzIGRlIGxhIGNy6WF0aW9uIG11c2ljYWxlLjxicj48
YnI+VW4gcHJpeCBzZXJhIHJlbWlzIGF1eCBsb2dpY2llbHMgcXVpIGZvbnQgcHJldXZlIG5vbiBz
ZXVsZW1lbnQgZJJpbm5vdmF0aW9uLCBtYWlzIG5vdGFtbWVudCBkkmludmVudGl2aXTpIGZhY2Ug
YXV4IGVuamV1eCBhY3R1ZWxzIGRlIGxhIGNy6WF0aW9uIG11c2ljYWxlLjxicj48YnI+PGI+Q2Fs
ZW5kcmllcjwvYj48YnI+PGI+NiBhdnJpbCAyMDEyIC0mbmJzcDs8L2I+QXBwZWwg4CBzb3VtaXNz
aW9uczxicj48Yj4yNSBhdnJpbCAyMDEyIC0mbmJzcDs8L2I+RGF0ZSBsaW1pdGUgZGUgc291bWlz
c2lvbiBkZXMgbG9naWNpZWxzPC9kaXY+PGRpdj48Yj4zMCBhdnJpbCAyMDEyIC0mbmJzcDs8L2I+
Tm90aWZpY2F0aW9uIGQnYWNjZXB0YXRpb248L2Rpdj48ZGl2PjxiPjExIG1haSAyMDEyIC0mbmJz
cDs8L2I+UmVtaXNlIGR1IHByaXggbG9ycyBkZXMgSklNIDIwMTI8L2Rpdj48ZGl2Pjxicj48Yj5J
bmZvPC9iPiZuYnNwOzombmJzcDs8YSBocmVmPSJodHRwOi8vY29uY291cnMuYWZpbS1hc3NvLm9y
Zy8iPmh0dHA6Ly9jb25jb3Vycy5hZmltLWFzc28ub3JnLzwvYT48L2Rpdj48ZGl2PjxzcGFuIGNs
YXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmE7IGZvbnQt
c2l6ZTogMTBweDsgIj48Yj5KSU0yMDEyIDo8L2I+PC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1z
dHlsZS1zcGFuIiBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmE7IGZvbnQtc2l6ZTogMTBweDsg
Ij4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3d3dy5qaW0yMDEyLmJlLyI+aHR0cDovL3d3
dy5qaW0yMDEyLmJlPC9hPjxicj48YnI+PC9kaXY+PGRpdj48YiBzdHlsZT0iZm9udC1zaXplOiAx
NHB4OyAiPjxicj48L2I+PC9kaXY+PGRpdj48YiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyAiPkxv
TXVzIDIwMTI8L2I+PC9kaXY+PGRpdj48YiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyAiPjxicj48
L2I+PC9kaXY+PGRpdj48YiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyAiPkluIHNlYXJjaCBvZiBv
cGVuLXNvdXJjZSBzb2Z0d2FyZSBmb3IgbXVzaWNhbCBhbmQgaW50ZXJtZWRpYSBjcmVhdGlvbjwv
Yj48YnIgc3R5bGU9ImZvbnQtc2l6ZTogMTNweDsgIj48YnI+Rm9yIGl0cyBmb3VydGggZWRpdGlv
biwgTG9tdXMgMjAxMiBpbnZpdGVzIG11c2ljIGFuZCBhdWRpbyBvcGVuLXNvdXJjZSBzb2Z0d2Fy
ZSBjcmVhdG9ycyB0byBzdWJtaXQgb3JpZ2luYWwgcHJvamVjdHMgdGhhdCBlaXRoZXIgZGlyZWN0
bHkgb3IgaW5kaXJlY3RseSZuYnNwO2NvbnRyaWJ1dGUgdG8gbXVzaWNhbCBjcmVhdGlvbi48YnI+
PGJyPkEgcHJpemUgd2lsbCBiZSBhd2FyZGVkIHRvIG9wZW4tc291cmNlIHNvZndhcmUgdGhhdCBw
cm92ZXMgdG8gYmUgbm90IG9ubHkgaW5ub3ZhdG9yeSBidXQgYWxzbyBpbnZlbnRpdmUgaW4gdGhl
IHByZXNlbnQgY29udGV4dCBvZiBtdXNpYyBhbmQgYXVkaW8gY3JlYXRpb24uPGJyPjxicj48YiBz
dHlsZT0iZm9udC1zaXplOiAxM3B4OyAiPkNhbGVuZGFyPC9iPjwvZGl2PjxkaXY+PGI+QXByaWwg
NiwgMjAxMjwvYj4mbmJzcDstIENhbGwgZm9yIHN1Ym1pc3Npb25zJm5ic3A7PC9kaXY+PGRpdj48
Yj5BcHJpbCAyNSwgMjAxMjwvYj4mbmJzcDstIFN1Ym1pc3Npb24gZGVhZGxpbmUmbmJzcDs8L2Rp
dj48ZGl2PjxiPkFwcmlsIDMwLCAyMDEyPC9iPiZuYnNwOy0gQWRtaXNzaW9uIG5vdGlmaWNhdGlv
biZuYnNwOzwvZGl2PjxkaXY+PGI+TWF5IDExLCAyMDEyPC9iPiZuYnNwOy0mbmJzcDtKSU0mbmJz
cDtBd2FyZHMgQ2VyZW1vbnk8L2Rpdj48ZGl2Pjxicj48Yj5JbmZvPC9iPjombmJzcDs8YSBocmVm
PSJodHRwOi8vY29uY291cnMuYWZpbS1hc3NvLm9yZy8iPmh0dHA6Ly9jb25jb3Vycy5hZmltLWFz
c28ub3JnLzwvYT48L2Rpdj48ZGl2PjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHls
ZT0iZm9udC1mYW1pbHk6IFZlcmRhbmE7IGZvbnQtc2l6ZTogMTBweDsgIj48Yj5KSU0yMDEyIDo8
L2I+PC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1mYW1p
bHk6IFZlcmRhbmE7IGZvbnQtc2l6ZTogMTBweDsgIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0
cDovL3d3dy5qaW0yMDEyLmJlIj5odHRwOi8vd3d3LmppbTIwMTIuYmU8L2E+PC9kaXY+PC9kaXY+
PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4=

--===============8109122109401941457==--


From neil@neilcsmith.net Fri Apr  6 18:15:42 2012
From: Neil C Smith <neil@neilcsmith.net>
To: linux-audio-dev@lists.linuxaudio.org
Subject: [LAD] [ANN] JAudioLibs v1.0.120123 (JNAJack Java<>JACK improvements)
Date: Fri, 06 Apr 2012 18:15:42 +0000
Message-ID:
 <CAHvRSod+iP+2hOuF28QnteDSrR460EJi05GdzyR6q9E=+rjRaw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3564597931601497274=="

--===============3564597931601497274==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi All,

JAudioLibs v1.0.120123 is now available from
http://code.google.com/p/java-audio-utils

There's only one major change in this release - the addition of
JNAJack support for JNA's new CallbackThreadInitializer, which was
specifically requested for JNAJack, and brings a big improvement in
CPU usage.

Use of JNA 3.4.0+ is now highly recommended, and JNAJack will emit a
warning if an earlier version of JNA is detected (though it will still
work).

There are no API changes.

Full release notes are available at
http://code.google.com/p/java-audio-utils/wiki/ReleaseNotes

As you may have guessed from the version number, this is actually the
code from the January release of Praxis
(http://code.google.com/p/praxis/).  The delay in releasing separately
was caused by a) the desire to test and b) a manic couple of months!
;-)

Best wishes,

Neil

-- 
Neil C Smith
Artist : Technologist : Adviser
http://neilcsmith.net

--===============3564597931601497274==--


From joelz@pobox.com Fri Apr  6 19:06:56 2012
From: Joel Roth <joelz@pobox.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Fri, 06 Apr 2012 19:06:56 +0000
Message-ID: <20120406190650.GB12185@sprite>
In-Reply-To: <4F7CAB45.5050700@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5873209170381045843=="

--===============5873209170381045843==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Wed, Apr 04, 2012 at 10:12:53PM +0200, rosea.grammostola wrote:
> Afaik, NSM gives us all we users need when it comes to LAU session
> management.... Correct me if I'm wrong.

It would be great if the core functionality of NSM
could be separated out from the GUI to support
console users and environments where X may not
be available.

Regards,

Joel
-- 
Joel Roth

--===============5873209170381045843==--


From malnourite@gmail.com Fri Apr  6 20:07:59 2012
From: "J. Liles" <malnourite@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Fri, 06 Apr 2012 20:07:59 +0000
Message-ID:
 <CAGhWSSZS-D5exCQQyS8VR3CEu7LtYi8U=J7H8tzpRMGoVxugSA@mail.gmail.com>
In-Reply-To: <20120406190650.GB12185@sprite>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7782340922589634340=="

--===============7782340922589634340==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Fri, Apr 6, 2012 at 12:06 PM, Joel Roth <joelz(a)pobox.com> wrote:

> On Wed, Apr 04, 2012 at 10:12:53PM +0200, rosea.grammostola wrote:
> > Afaik, NSM gives us all we users need when it comes to LAU session
> > management.... Correct me if I'm wrong.
>
> It would be great if the core functionality of NSM
> could be separated out from the GUI to support
> console users and environments where X may not
> be available.
>

FYI. This is already a matter of fact... the GUI communicates with nsmd via
OSC. nsmd can be run without the GUI and controlled via osc (there's a
program included in the distribution called send_osc to allow this kind of
thing to be done via shell scripts).



--===============7782340922589634340==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PGJyPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gRnJpLCBBcHIgNiwgMjAxMiBhdCAx
MjowNiBQTSwgSm9lbCBSb3RoIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmpv
ZWx6QHBvYm94LmNvbSI+am9lbHpAcG9ib3guY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj48
YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDti
b3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4KPGRpdiBjbGFzcz0i
aW0iPk9uIFdlZCwgQXByIDA0LCAyMDEyIGF0IDEwOjEyOjUzUE0gKzAyMDAsIHJvc2VhLmdyYW1t
b3N0b2xhIHdyb3RlOjxicj4KJmd0OyBBZmFpaywgTlNNIGdpdmVzIHVzIGFsbCB3ZSB1c2VycyBu
ZWVkIHdoZW4gaXQgY29tZXMgdG8gTEFVIHNlc3Npb248YnI+CjwvZGl2PiZndDsgbWFuYWdlbWVu
dC4uLi4gQ29ycmVjdCBtZSBpZiBJJiMzOTttIHdyb25nLjxicj4KPGJyPgpJdCB3b3VsZCBiZSBn
cmVhdCBpZiB0aGUgY29yZSBmdW5jdGlvbmFsaXR5IG9mIE5TTTxicj4KY291bGQgYmUgc2VwYXJh
dGVkIG91dCBmcm9tIHRoZSBHVUkgdG8gc3VwcG9ydDxicj4KY29uc29sZSB1c2VycyBhbmQgZW52
aXJvbm1lbnRzIHdoZXJlIFggbWF5IG5vdDxicj4KYmUgYXZhaWxhYmxlLjxicj48L2Jsb2NrcXVv
dGU+PGRpdj48YnI+RllJLiBUaGlzIGlzIGFscmVhZHkgYSBtYXR0ZXIgb2YgZmFjdC4uLiB0aGUg
R1VJIGNvbW11bmljYXRlcyB3aXRoIG5zbWQgdmlhIE9TQy4gbnNtZCBjYW4gYmUgcnVuIHdpdGhv
dXQgdGhlIEdVSSBhbmQgY29udHJvbGxlZCB2aWEgb3NjICh0aGVyZSYjMzk7cyBhIHByb2dyYW0g
aW5jbHVkZWQgaW4gdGhlIGRpc3RyaWJ1dGlvbiBjYWxsZWQgc2VuZF9vc2MgdG8gYWxsb3cgdGhp
cyBraW5kIG9mIHRoaW5nIHRvIGJlIGRvbmUgdmlhIHNoZWxsIHNjcmlwdHMpLjxicj4KPGJyPjwv
ZGl2PjwvZGl2Pjxicj4K

--===============7782340922589634340==--


From list@nilsgey.de Sat Apr  7 16:57:15 2012
From: Nils <list@nilsgey.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: [LAD] Laborejo Release 0.2 Announcement
Date: Sat, 07 Apr 2012 16:57:15 +0000
Message-ID: <20120407185924.531bf6b8@nilsgey.de>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0384723333501215568=="

--===============0384723333501215568==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Exactly one month after the first release, here is Laborejo 0.2!

Laborejo, Esperanto for "Workshop", is used to craft music through
notation. It is a Lilypond GUI frontend, a MIDI creator and finally a
tool collection to inspire and help you compose. It works by reducing
music-redundancy and by seperating layout and data.

The next release is scheduled for May, 8th. One month from now.

Before you read the details make sure to connect to Laborejos Facebook,
Twitter or Google Plus! https://www.facebook.com/Laborejo
https://twitter.com/#!/Laborejo
https://plus.google.com/b/116744898976321238325/

Screenshot (Laborejo and Lilypond, side by side):
http://www.laborejo.org/images/screenshots/latestscreenshot.png

This is the release of version 0.2
Download: https://github.com/nilsgey/Laborejo/tarball/0.2
Dependencies: http://www.laborejo.org/documentation

Linux Instructions: Unpack, cd into the created directoy, execute:
./laborejo-qt.sh

Then use the number- and cursor keys for immediate success! 
Check Help->Manual for navigational and note/rest entry keys.
Everything else is in the menus.

New since version 0.1:
- Repeats, Alternate Ends and Jumps in various forms. The main Feature
for this release.
- Playback Trigger ("Only reduce volume in the second repeat" or "Mute
track if python weather module reports rain")
- Master Track (Merges with every other Track. Use to structure your
piece, make global changes, change tempo etc.)
- Various Commands like "Join Selection to Chord" and "Add Octave to
Chord/Selection" 
- The usual bread&butter bugfixing and improving.

Most important known problems:
* This is Alpha Grade Software. Don't use for long-term work. However,
the produced midis and PDFs will last forever.
* There is no built-in jack midi output yet. You have to export midi
files.
* Documentation is nearly non-existent.

Have fun, it would be nice to hear from you!

Nils
http://www.laborejo.org

--===============0384723333501215568==--


From egor.sanin@gmail.com Sun Apr  8 16:36:34 2012
From: Egor Sanin <egor.sanin@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: [LAD]  c/jack question
Date: Sun, 08 Apr 2012 16:36:34 +0000
Message-ID:
 <CALVwFW9r=3oLusgAB31V-=Sr9PLsGYFSCvEF6df3tdkCv97R4Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0277169701622383529=="

--===============0277169701622383529==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Pardon the newb question, but why does:

a) this work
---------------------------------------------
#include <jack/jack.h>

jack_position_t pos;
jack_transport_state_t state;
jack_nframes_t frame;

int process (jack_nframes_t nframes, void *arg) {
    state = jack_transport_query (client, &pos);
    frame = pos.frame;
}
---------------------------------------------

b) this segfaults
---------------------------------------------
#include <jack/jack.h>

jack_position_t *pos;
jack_transport_state_t state;
jack_nframes_t frame;

int process (jack_nframes_t nframes, void *arg) {
    state = jack_transport_query (client, pos);
    frame = pos->frame;
}

Thanks

--===============0277169701622383529==--


From mark.d.mccurry@gmail.com Sun Apr  8 16:49:43 2012
From: Mark McCurry <mark.d.mccurry@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] c/jack question
Date: Sun, 08 Apr 2012 16:49:43 +0000
Message-ID:
 <CAFVXzJ=ONz=Y23Vd+Jj=R8d_GCCEpagwn3gbB70akHqGBW_CPw@mail.gmail.com>
In-Reply-To:
 <CALVwFW9r=3oLusgAB31V-=Sr9PLsGYFSCvEF6df3tdkCv97R4Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5665566538699934677=="

--===============5665566538699934677==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

> Pardon the newb question, but why does: ...
This is a fairly simple C mistake.
In A, &pos refers to valid chunk of memory, thus when
jack_transport_query operates on it, it has a valid piece of memory to
work with.
In B, pos (IIRC) would be initialized to NULL as it is in the file scope.
So when you call jack_transport_query, you have provided a pointer to
NULL, where any memory access will be invalid.

If you set pos in B to be a pointer to a valid object (chunk of
memory) then it should work fine (ie refer to a global object or an
object allocated on the heap with malloc or friends).

--Mark

--===============5665566538699934677==--


From egor.sanin@gmail.com Sun Apr  8 17:01:53 2012
From: Egor Sanin <egor.sanin@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] c/jack question
Date: Sun, 08 Apr 2012 17:01:53 +0000
Message-ID:
 <CALVwFW-PdKHqru47mzv9kqnuynXYXAYgKbPqO2SGKYU6+qFafw@mail.gmail.com>
In-Reply-To:
 <CAFVXzJ=ONz=Y23Vd+Jj=R8d_GCCEpagwn3gbB70akHqGBW_CPw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0634618400076510271=="

--===============0634618400076510271==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi Mark,

> In A, &pos refers to valid chunk of memory, thus when
> jack_transport_query operates on it, it has a valid piece of memory to
> work with.

Got it, thanks!

> In B, pos (IIRC) would be initialized to NULL as it is in the file scope.
> So when you call jack_transport_query, you have provided a pointer to
> NULL, where any memory access will be invalid.

But then why does jack_transport_query not give any error when it is
passed a NULL pointer in the form of pos?
If I remove the line
frame =3D pos->frame;
from B, the code runs, state is set properly and jackd doesn't report problem=
s.

Thanks for you help.

--===============0634618400076510271==--


From linux-audio-dev@windows3.de Sun Apr  8 17:21:13 2012
From: Dennis Schulmeister <linux-audio-dev@windows3.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] c/jack question
Date: Sun, 08 Apr 2012 17:21:13 +0000
Message-ID: <20120408192107.a49881a601391222d5d4c2b5@windows3.de>
In-Reply-To:
 <CALVwFW-PdKHqru47mzv9kqnuynXYXAYgKbPqO2SGKYU6+qFafw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7395939685784481084=="

--===============7395939685784481084==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Sun, 8 Apr 2012 13:01:50 -0400
Egor Sanin <egor.sanin(a)gmail.com> wrote:

> But then why does jack_transport_query not give any error when it is
> passed a NULL pointer in the form of pos?
> If I remove the line
> frame =3D pos->frame;
> from B, the code runs, state is set properly and jackd doesn't report probl=
ems.

I didn't look at the jack api, but calling jack_transport_query with a
null-pointer might be valid. In that case jack assumes you're not
interested in position data. iow, the jack authors didn't forget to
check for null-pointers.

Dennis

--=20
Dennis Schulmeister - Schifferstr. 1 - 76189 Karlsruhe - Germany
Tel: +49 721/5978883 - Fax: +49 721/5978882 -  Mob: +49 152/01994400
eMail: dennis(a)windows3.de - web: there-is.no-ip.org

--===============7395939685784481084==--


From joelz@pobox.com Sun Apr  8 17:38:47 2012
From: Joel Roth <joelz@pobox.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Sun, 08 Apr 2012 17:38:47 +0000
Message-ID: <20120408173842.GA31071@sprite>
In-Reply-To:
 <CAGhWSSZS-D5exCQQyS8VR3CEu7LtYi8U=J7H8tzpRMGoVxugSA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5808207115269280897=="

--===============5808207115269280897==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Fri, Apr 06, 2012 at 01:07:57PM -0700, J. Liles wrote:
> On Fri, Apr 6, 2012 at 12:06 PM, Joel Roth <joelz(a)pobox.com> wrote:
> 
> > On Wed, Apr 04, 2012 at 10:12:53PM +0200, rosea.grammostola wrote:
> > > Afaik, NSM gives us all we users need when it comes to LAU session
> > > management.... Correct me if I'm wrong.
> >
> > It would be great if the core functionality of NSM
> > could be separated out from the GUI to support
> > console users and environments where X may not
> > be available.
> >
> 
> FYI. This is already a matter of fact... the GUI communicates with nsmd via
> OSC. nsmd can be run without the GUI and controlled via osc (there's a
> program included in the distribution called send_osc to allow this kind of
> thing to be done via shell scripts).

That's great to know. I also see that CPAN has a couple of
modules for handling OSC.


-- 
Joel Roth

--===============5808207115269280897==--


From gabrbedd@gmail.com Sun Apr  8 17:43:19 2012
From: "Gabriel M. Beddingfield" <gabrbedd@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] c/jack question
Date: Sun, 08 Apr 2012 17:43:19 +0000
Message-ID: <4F81CE33.6050101@gmail.com>
In-Reply-To:
 <CALVwFW-PdKHqru47mzv9kqnuynXYXAYgKbPqO2SGKYU6+qFafw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0508220942640660603=="

--===============0508220942640660603==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On 04/08/2012 12:01 PM, Egor Sanin wrote:
>> In B, pos (IIRC) would be initialized to NULL as it is in the file scope.
>> So when you call jack_transport_query, you have provided a pointer to
>> NULL, where any memory access will be invalid.
>
> But then why does jack_transport_query not give any error when it is
> passed a NULL pointer in the form of pos?

Because it's valid to do this according to the docs:

=20
http://jackaudio.org/files/docs/html/group__TransportControl.html#ga5f08eb71a=
5ee5431a3d756af5729d5aa

If pos is NULL it just ignores it.  It's not an error at all.

OTOH, if pos is uninitialized, then jack will try to write the data to=20
whatever random address in in pos... and that will usually segfault.

> If I remove the line
> frame =3D pos->frame;
> from B, the code runs, state is set properly and jackd doesn't report probl=
ems.

This suggests that pos is indeed NULL, and you tried to dereference a=20
null pointer... which will always segfault.

-gabriel

--===============0508220942640660603==--


From egor.sanin@gmail.com Sun Apr  8 22:49:22 2012
From: Egor Sanin <egor.sanin@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] c/jack question
Date: Sun, 08 Apr 2012 22:49:22 +0000
Message-ID:
 <CALVwFW_E7Hfk75TiTtVROzuVjjM-0LLreubFJjM2Hexj0ptrJg@mail.gmail.com>
In-Reply-To: <4F81CE33.6050101@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2773833285205768171=="

--===============2773833285205768171==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

> http://jackaudio.org/files/docs/html/group__TransportControl.html#ga5f08eb7=
1a5ee5431a3d756af5729d5aa
>
> If pos is NULL it just ignores it.  It's not an error at all.

Aha!  I missed that, thanks for clarifying.


Thanks guys.

--===============2773833285205768171==--


From rosea.grammostola@gmail.com Mon Apr  9 15:28:31 2012
From: "rosea.grammostola" <rosea.grammostola@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Mon, 09 Apr 2012 15:28:31 +0000
Message-ID: <4F82FFFA.2020405@gmail.com>
In-Reply-To: <20120406190650.GB12185@sprite>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5308363308097411547=="

--===============5308363308097411547==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/06/2012 09:06 PM, Joel Roth wrote:
> On Wed, Apr 04, 2012 at 10:12:53PM +0200, rosea.grammostola wrote:
>> Afaik, NSM gives us all we users need when it comes to LAU session
>> management.... Correct me if I'm wrong.
>
> It would be great if the core functionality of NSM
> could be separated out from the GUI to support
> console users and environments where X may not
> be available.

So that's already the case. Anyway thanks for trying :) Only developers 
are able to convince me on fundamental flaws of the NSM design atm. In 
this regard, it might be good if JackSession developers speak out about 
the current situation, now we have NSM and JackSession. They probably 
see those fundamental flaws or disadvantages in NSM. Or they maybe see 
particular advantages of JackSession or even NSM.

Let me summarize my personal findings as a JackSession and NSM user:

Personally I saw it as an advantage of JackSession, that it has JACK 
involved and that it only needs the JACK dependency. After the comments 
by Fons and by trying NSM myself, I think that it is an advantage of NSM 
instead, that it is independent of JACK. It's more easy to add apps 
without JACK support to the session and to keep apps with JACK support 
outside the session (by purpose). It gives you as a user more freedom 
and flexibility overall and so I think it's a better design choice. 
These advantages out weights the disadvantage of having one extra 
dependency to support NSM (liblo).

In terms of workflow, I prefer NSM above JackSession. Not only the fact 
that it is possible to easily launch apps without session support 
(without conf files), but also that it does what you expect from a 
session manager, OOTB. Close applications, fast, easy and safe saving. 
Quick and easy changing from one session to another etc.

The fact that NSM asks supported clients to act coherently and 
predictable is another advantage. I think it gives you as a user a 
simple and clear workflow. An disadvantage of this might be that a 
little more is expected from the devs of the clients, but as far as I 
understood that's isn't much extra effort to support it and also there 
are no fundamental objections yet, apart from the fact apps which 
doesn't have a centralized save location (qtractor), have more problems 
with this. I think this is a problem in that app as others pointed out. 
Moreover there are not many apps with this behavior.

In summary and to conclude: After using Ladish and especially 
JackSession, I think NSM is the best solution for the session puzzle so 
far and likely for the coming years. This is a personal user 
perspective, devs could think otherwise, but I didn't see a good reason 
for this so far.

Thanks. The list is yours again ;)

\r








--===============5308363308097411547==--


From fons@linuxaudio.org Mon Apr  9 16:03:19 2012
From: Fons Adriaensen <fons@linuxaudio.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Mon, 09 Apr 2012 16:03:19 +0000
Message-ID: <20120409160258.GA31907@linuxaudio.org>
In-Reply-To: <4F82FFFA.2020405@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4601570162924790529=="

--===============4601570162924790529==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Mon, Apr 09, 2012 at 05:27:54PM +0200, rosea.grammostola wrote:

> Personally I saw it as an advantage of JackSession, that it has JACK  
> involved and that it only needs the JACK dependency. After the comments  
> by Fons and by trying NSM myself, I think that it is an advantage of NSM  
> instead, that it is independent of JACK. It's more easy to add apps  
> without JACK support to the session and to keep apps with JACK support  
> outside the session (by purpose). It gives you as a user more freedom  
> and flexibility overall and so I think it's a better design choice.  
> These advantages out weights the disadvantage of having one extra  
> dependency to support NSM (liblo).

Liblo is *not* a dependency of any app using NSM. Since the NSM protocol
specifies the actual messages, an app can send an receive them whatever
code or library the developer prefers. In fact NSM does not add any
dependencies at all.


To ensure things stay like that, I'd like to see the following
added to the NSM specs:

* All communication is done using simple OSC messages,
* i.e. without using bundles or wildcards. 

That way even the most basic OSC support would be enough to
use NSM. And with the protocol as it stands, nothing is lost.


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)


--===============4601570162924790529==--


From malnourite@gmail.com Mon Apr  9 16:35:30 2012
From: "J. Liles" <malnourite@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Mon, 09 Apr 2012 16:35:30 +0000
Message-ID:
 <CAGhWSSbC2rc=p1Rab6ujyVoKLNO2buFdqYND0yu_ds9Wrh0dcg@mail.gmail.com>
In-Reply-To: <20120409160258.GA31907@linuxaudio.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5598575113523718244=="

--===============5598575113523718244==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Mon, Apr 9, 2012 at 9:03 AM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:

> On Mon, Apr 09, 2012 at 05:27:54PM +0200, rosea.grammostola wrote:
>
> > Personally I saw it as an advantage of JackSession, that it has JACK
> > involved and that it only needs the JACK dependency. After the comments
> > by Fons and by trying NSM myself, I think that it is an advantage of NSM
> > instead, that it is independent of JACK. It's more easy to add apps
> > without JACK support to the session and to keep apps with JACK support
> > outside the session (by purpose). It gives you as a user more freedom
> > and flexibility overall and so I think it's a better design choice.
> > These advantages out weights the disadvantage of having one extra
> > dependency to support NSM (liblo).
>
> Liblo is *not* a dependency of any app using NSM. Since the NSM protocol
> specifies the actual messages, an app can send an receive them whatever
> code or library the developer prefers. In fact NSM does not add any
> dependencies at all.
>
>
> To ensure things stay like that, I'd like to see the following
> added to the NSM specs:
>
> * All communication is done using simple OSC messages,
> * i.e. without using bundles or wildcards.
>
> That way even the most basic OSC support would be enough to
> use NSM. And with the protocol as it stands, nothing is lost.
>
>
This is true. Liblo is not a hard dependency. Anything that can
send/receive OSC messages should work. It definitely doesn't use wildcards
and I haven't actually found a use for OSC wildcards yet period, so I don't
have a problem with officially avoiding them. Bundles are useful for some
things (especially when delivering a list like response, because OSC has no
more obvious way to indicate 'end of list'), and aren't very complicated at
the stream level (just ordinary messages preceded by something that says,
'hey, this is a bundle of such and such length'), but, yeah, I don't have
any idea how many of the OSC implementations out there support them. With
liblo, it's only *generating* the bundle that is complicated. Receiving it
is easy.The lowest common denominator here (that people are likely to
actually use) is probably the Python OSC implementation. And, anyway, the
current implementation doesn't use them for anything (if it did, it would
probably use them for the session list response [not something most clients
will even use] and the announce response/open pair [all clients use this
one]).



--===============5598575113523718244==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PGJyPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gTW9uLCBBcHIgOSwgMjAxMiBhdCA5
OjAzIEFNLCBGb25zIEFkcmlhZW5zZW4gPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWls
dG86Zm9uc0BsaW51eGF1ZGlvLm9yZyI+Zm9uc0BsaW51eGF1ZGlvLm9yZzwvYT4mZ3Q7PC9zcGFu
PiB3cm90ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2lu
OjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+
CjxkaXYgY2xhc3M9ImltIj5PbiBNb24sIEFwciAwOSwgMjAxMiBhdCAwNToyNzo1NFBNICswMjAw
LCByb3NlYS5ncmFtbW9zdG9sYSB3cm90ZTo8YnI+Cjxicj4KJmd0OyBQZXJzb25hbGx5IEkgc2F3
IGl0IGFzIGFuIGFkdmFudGFnZSBvZiBKYWNrU2Vzc2lvbiwgdGhhdCBpdCBoYXMgSkFDSzxicj4K
Jmd0OyBpbnZvbHZlZCBhbmQgdGhhdCBpdCBvbmx5IG5lZWRzIHRoZSBKQUNLIGRlcGVuZGVuY3ku
IEFmdGVyIHRoZSBjb21tZW50czxicj4KJmd0OyBieSBGb25zIGFuZCBieSB0cnlpbmcgTlNNIG15
c2VsZiwgSSB0aGluayB0aGF0IGl0IGlzIGFuIGFkdmFudGFnZSBvZiBOU008YnI+CiZndDsgaW5z
dGVhZCwgdGhhdCBpdCBpcyBpbmRlcGVuZGVudCBvZiBKQUNLLiBJdCYjMzk7cyBtb3JlIGVhc3kg
dG8gYWRkIGFwcHM8YnI+CiZndDsgd2l0aG91dCBKQUNLIHN1cHBvcnQgdG8gdGhlIHNlc3Npb24g
YW5kIHRvIGtlZXAgYXBwcyB3aXRoIEpBQ0sgc3VwcG9ydDxicj4KJmd0OyBvdXRzaWRlIHRoZSBz
ZXNzaW9uIChieSBwdXJwb3NlKS4gSXQgZ2l2ZXMgeW91IGFzIGEgdXNlciBtb3JlIGZyZWVkb208
YnI+CiZndDsgYW5kIGZsZXhpYmlsaXR5IG92ZXJhbGwgYW5kIHNvIEkgdGhpbmsgaXQmIzM5O3Mg
YSBiZXR0ZXIgZGVzaWduIGNob2ljZS48YnI+CiZndDsgVGhlc2UgYWR2YW50YWdlcyBvdXQgd2Vp
Z2h0cyB0aGUgZGlzYWR2YW50YWdlIG9mIGhhdmluZyBvbmUgZXh0cmE8YnI+CiZndDsgZGVwZW5k
ZW5jeSB0byBzdXBwb3J0IE5TTSAobGlibG8pLjxicj4KPGJyPgo8L2Rpdj5MaWJsbyBpcyAqbm90
KiBhIGRlcGVuZGVuY3kgb2YgYW55IGFwcCB1c2luZyBOU00uIFNpbmNlIHRoZSBOU00gcHJvdG9j
b2w8YnI+CnNwZWNpZmllcyB0aGUgYWN0dWFsIG1lc3NhZ2VzLCBhbiBhcHAgY2FuIHNlbmQgYW4g
cmVjZWl2ZSB0aGVtIHdoYXRldmVyPGJyPgpjb2RlIG9yIGxpYnJhcnkgdGhlIGRldmVsb3BlciBw
cmVmZXJzLiBJbiBmYWN0IE5TTSBkb2VzIG5vdCBhZGQgYW55PGJyPgpkZXBlbmRlbmNpZXMgYXQg
YWxsLjxicj4KPGJyPgo8YnI+ClRvIGVuc3VyZSB0aGluZ3Mgc3RheSBsaWtlIHRoYXQsIEkmIzM5
O2QgbGlrZSB0byBzZWUgdGhlIGZvbGxvd2luZzxicj4KYWRkZWQgdG8gdGhlIE5TTSBzcGVjczo8
YnI+Cjxicj4KKiBBbGwgY29tbXVuaWNhdGlvbiBpcyBkb25lIHVzaW5nIHNpbXBsZSBPU0MgbWVz
c2FnZXMsPGJyPgoqIGkuZS4gd2l0aG91dCB1c2luZyBidW5kbGVzIG9yIHdpbGRjYXJkcy48YnI+
Cjxicj4KVGhhdCB3YXkgZXZlbiB0aGUgbW9zdCBiYXNpYyBPU0Mgc3VwcG9ydCB3b3VsZCBiZSBl
bm91Z2ggdG88YnI+CnVzZSBOU00uIEFuZCB3aXRoIHRoZSBwcm90b2NvbCBhcyBpdCBzdGFuZHMs
IG5vdGhpbmcgaXMgbG9zdC48YnI+CjxkaXYgY2xhc3M9ImltIEhPRW5aYiI+PGJyPjwvZGl2Pjwv
YmxvY2txdW90ZT48ZGl2Pjxicj5UaGlzIGlzIHRydWUuIExpYmxvIGlzIG5vdCBhIGhhcmQgZGVw
ZW5kZW5jeS4gQW55dGhpbmcgdGhhdCBjYW4gc2VuZC9yZWNlaXZlIE9TQyBtZXNzYWdlcyBzaG91
bGQgd29yay4gSXQgZGVmaW5pdGVseSBkb2VzbiYjMzk7dCB1c2Ugd2lsZGNhcmRzIGFuZCBJIGhh
dmVuJiMzOTt0IGFjdHVhbGx5IGZvdW5kIGEgdXNlIGZvciBPU0Mgd2lsZGNhcmRzIHlldCBwZXJp
b2QsIHNvIEkgZG9uJiMzOTt0IGhhdmUgYSBwcm9ibGVtIHdpdGggb2ZmaWNpYWxseSBhdm9pZGlu
ZyB0aGVtLiBCdW5kbGVzIGFyZSB1c2VmdWwgZm9yIHNvbWUgdGhpbmdzIChlc3BlY2lhbGx5IHdo
ZW4gZGVsaXZlcmluZyBhIGxpc3QgbGlrZSByZXNwb25zZSwgYmVjYXVzZSBPU0MgaGFzIG5vIG1v
cmUgb2J2aW91cyB3YXkgdG8gaW5kaWNhdGUgJiMzOTtlbmQgb2YgbGlzdCYjMzk7KSwgYW5kIGFy
ZW4mIzM5O3QgdmVyeSBjb21wbGljYXRlZCBhdCB0aGUgc3RyZWFtIGxldmVsIChqdXN0IG9yZGlu
YXJ5IG1lc3NhZ2VzIHByZWNlZGVkIGJ5IHNvbWV0aGluZyB0aGF0IHNheXMsICYjMzk7aGV5LCB0
aGlzIGlzIGEgYnVuZGxlIG9mIHN1Y2ggYW5kIHN1Y2ggbGVuZ3RoJiMzOTspLCBidXQsIHllYWgs
IEkgZG9uJiMzOTt0IGhhdmUgYW55IGlkZWEgaG93IG1hbnkgb2YgdGhlIE9TQyBpbXBsZW1lbnRh
dGlvbnMgb3V0IHRoZXJlIHN1cHBvcnQgdGhlbS4gV2l0aCBsaWJsbywgaXQmIzM5O3Mgb25seSAq
Z2VuZXJhdGluZyogdGhlIGJ1bmRsZSB0aGF0IGlzIGNvbXBsaWNhdGVkLiBSZWNlaXZpbmcgaXQg
aXMgZWFzeS5UaGUgbG93ZXN0IGNvbW1vbiBkZW5vbWluYXRvciBoZXJlICh0aGF0IHBlb3BsZSBh
cmUgbGlrZWx5IHRvIGFjdHVhbGx5IHVzZSkgaXMgcHJvYmFibHkgdGhlIFB5dGhvbiBPU0MgaW1w
bGVtZW50YXRpb24uIEFuZCwgYW55d2F5LCB0aGUgY3VycmVudCBpbXBsZW1lbnRhdGlvbiBkb2Vz
biYjMzk7dCB1c2UgdGhlbSBmb3IgYW55dGhpbmcgKGlmIGl0IGRpZCwgaXQgd291bGQgcHJvYmFi
bHkgdXNlIHRoZW0gZm9yIHRoZSBzZXNzaW9uIGxpc3QgcmVzcG9uc2UgW25vdCBzb21ldGhpbmcg
bW9zdCBjbGllbnRzIHdpbGwgZXZlbiB1c2VdIGFuZCB0aGUgYW5ub3VuY2UgcmVzcG9uc2Uvb3Bl
biBwYWlyIFthbGwgY2xpZW50cyB1c2UgdGhpcyBvbmVdKS48YnI+Cjxicj48L2Rpdj48L2Rpdj4K

--===============5598575113523718244==--


From fons@linuxaudio.org Mon Apr  9 17:10:30 2012
From: Fons Adriaensen <fons@linuxaudio.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Mon, 09 Apr 2012 17:10:30 +0000
Message-ID: <20120409171029.GC31907@linuxaudio.org>
In-Reply-To:
 <CAGhWSSbC2rc=p1Rab6ujyVoKLNO2buFdqYND0yu_ds9Wrh0dcg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2007656500284299993=="

--===============2007656500284299993==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Mon, Apr 09, 2012 at 09:35:27AM -0700, J. Liles wrote:

> This is true. Liblo is not a hard dependency. Anything that can
> send/receive OSC messages should work. It definitely doesn't use wildcards
> and I haven't actually found a use for OSC wildcards yet period,

Same here... In all cases where I've wanted to say 'all' objects
of some sort (e.g. set all faders to 'off'), those objects are
indexed by integers anyway and not as part of the destination. So 
all it takes is some 'escape' value such as -1.

> so I don't
> have a problem with officially avoiding them. Bundles are useful for some
> things (especially when delivering a list like response, because OSC has no
> more obvious way to indicate 'end of list'),

'[' and ']' in the format are used to start and end arrays, lists, etc..

> and aren't very complicated at the stream level 

True, but note that the ability to receive bundles implies honouring
timestamps. A library that does accept bundles but ignores timestamps
would be considered buggy. It's this that turns what could otherwise
be something very simple and minimal into a more complex affair,
requiring a different API and in theory also unbounded storage.

I never understood why the OSC designers combined bundling and
timestamping, as either of them is useful without the other.

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)


--===============2007656500284299993==--


From kaspar.bumke@gmail.com Tue Apr 10 20:32:04 2012
From: Kaspar Bumke <kaspar.bumke@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] Midi Channel routing with hardware?
Date: Tue, 10 Apr 2012 20:32:04 +0000
Message-ID:
 <CAB+dmjidRxm-1=hD-x3b8BmH=FJMhM91+vq48WktFsk==RywxQ@mail.gmail.com>
In-Reply-To: <20120322215413.1e7dabc9@nilsgey.de>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3728963360794206233=="

--===============3728963360794206233==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi,

tl;dr: Is there a cheap midi hardware that just gets midi information in
> and routes it out, except on a different, single, channel which I can
> change easily up and down directly on the hardware?
>

There is hardware stuff out there. Have a look for "hardware midi filter"
or "hardware midi event processor". This one for instance:
http://www.midisolutions.com/prodevp.htm

I have never used any of these so I can't say much more about them.

I know I can do the channel routing directly on my linux computer, after
> receiving the data and before sending it to a sampler. But that is
> inconvenient.
>

You could write something in mididings that would could route the incoming
midi data to different channels depending on what you press on your
footpedal: http://das.nasophon.de/mididings/

Regards,

Kaspar



On 22 March 2012 20:54, Nils <list(a)nilsgey.de> wrote:

> Hello list,
>
> tl;dr: Is there a cheap midi hardware that just gets midi information in
> and routes it out, except on a different, single, channel which I can
> change easily up and down directly on the hardware?
>
> Long version:
> Recently my master keyboard broke. It was just a cheap, used m-audio
> keystation 49e. I did not buy a new master-keyboard because I have a Roland
> HP207e digital piano here which is vastly superior when it comes to actual
> playing. Sadly not to control midi data.
>
> I have a Behringer BCF2000 here which I connected to my keyboard now, so I
> should be able to do something with it, but there is one thing missing:
> Channel Changes.
>
> Anybody who worked with Linuxsampler knows that channel switching is very
> important to switch instruments, while program changes are neglectable.
>
> So maybe there is a way to use my piano, which always sends on the first
> channel (except I dive into inaccessible menus) if
> a) I find a way to shortcut the "change channel" command, but I don't know
> how. It has midi in and a usb connector, but that is not used to control
> it, just to send and receive midi data. Incoming data gets interpreted like
> a sampler does.
>
> b) There is a way to use my BCF2000. I am very inexperienced with that
> thing.
>
> c) There is a cheap standalone hardware, just a "little box", I can plugin
> between my linux box and the piano, which re-routes the midi data, like I
> mentioned in the short version above.
>
> d) I build something myself, a small linux plug computer where I somehow
> attach two buttons (ch up and dow) and use the usb connections. At least
> the cables are cheaper :)  But this is the most unrealistic method,
> although it might be the most interesting one.
>
>
> Maybe you know something?
>
> Nils
>
> P.S. I know I can do the channel routing directly on my linux computer,
> after receiving the data and before sending it to a sampler. But that is
> inconvenient.
>
>
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>



--===============3728963360794206233==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

SGksPGJyPjxicj48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOjBwdCAwcHQgMHB0IDAuOGV4O2Jv
cmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiIGNs
YXNzPSJnbWFpbF9xdW90ZSI+CnRsO2RyOiBJcyB0aGVyZSBhIGNoZWFwIG1pZGkgaGFyZHdhcmUg
dGhhdCBqdXN0IGdldHMgbWlkaSBpbmZvcm1hdGlvbiBpbgogYW5kIHJvdXRlcyBpdCBvdXQsIGV4
Y2VwdCBvbiBhIGRpZmZlcmVudCwgc2luZ2xlLCBjaGFubmVsIHdoaWNoIEkgY2FuIApjaGFuZ2Ug
ZWFzaWx5IHVwIGFuZCBkb3duIGRpcmVjdGx5IG9uIHRoZSBoYXJkd2FyZT88YnI+PC9ibG9ja3F1
b3RlPjxkaXY+PGJyPlRoZXJlIGlzIGhhcmR3YXJlIHN0dWZmIG91dCB0aGVyZS4gSGF2ZSBhIGxv
b2sgZm9yICZxdW90O2hhcmR3YXJlIG1pZGkgZmlsdGVyJnF1b3Q7IG9yICZxdW90O2hhcmR3YXJl
IG1pZGkgZXZlbnQgcHJvY2Vzc29yJnF1b3Q7LiBUaGlzIG9uZSBmb3IgaW5zdGFuY2U6IDxhIGhy
ZWY9Imh0dHA6Ly93d3cubWlkaXNvbHV0aW9ucy5jb20vcHJvZGV2cC5odG0iPmh0dHA6Ly93d3cu
bWlkaXNvbHV0aW9ucy5jb20vcHJvZGV2cC5odG08L2E+PGJyPgoKPGJyPkkgaGF2ZSBuZXZlciB1
c2VkIGFueSBvZiB0aGVzZSBzbyBJIGNhbiYjMzk7dCBzYXkgbXVjaCBtb3JlIGFib3V0IHRoZW0u
PGJyPjxicj48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOjBwdCAwcHQgMHB0IDAuOGV4O2JvcmRl
ci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiIGNsYXNz
PSJnbWFpbF9xdW90ZSI+IEkga25vdyBJIGNhbiBkbyB0aGUgY2hhbm5lbCByb3V0aW5nIGRpcmVj
dGx5IG9uIG15IGxpbnV4IGNvbXB1dGVyLCAKYWZ0ZXIgcmVjZWl2aW5nIHRoZSBkYXRhIGFuZCBi
ZWZvcmUgc2VuZGluZyBpdCB0byBhIHNhbXBsZXIuIEJ1dCB0aGF0IGlzCiBpbmNvbnZlbmllbnQu
PGJyPjwvYmxvY2txdW90ZT48ZGl2Pjxicj5Zb3UgY291bGQgd3JpdGUgc29tZXRoaW5nIGluIG1p
ZGlkaW5ncyB0aGF0IHdvdWxkIGNvdWxkIHJvdXRlIHRoZSBpbmNvbWluZyBtaWRpIGRhdGEgdG8g
ZGlmZmVyZW50IGNoYW5uZWxzIGRlcGVuZGluZyBvbiB3aGF0IHlvdSBwcmVzcyBvbiB5b3VyIGZv
b3RwZWRhbDogPGEgaHJlZj0iaHR0cDovL2Rhcy5uYXNvcGhvbi5kZS9taWRpZGluZ3MvIj5odHRw
Oi8vZGFzLm5hc29waG9uLmRlL21pZGlkaW5ncy88L2E+PGJyPgoKPGJyPlJlZ2FyZHMsPGJyPjxi
cj5LYXNwYXI8YnI+PC9kaXY+oDxicj48L2Rpdj48YnI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1
b3RlIj5PbiAyMiBNYXJjaCAyMDEyIDIwOjU0LCBOaWxzIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEg
aHJlZj0ibWFpbHRvOmxpc3RAbmlsc2dleS5kZSI+bGlzdEBuaWxzZ2V5LmRlPC9hPiZndDs8L3Nw
YW4+IHdyb3RlOjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJn
aW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4
Ij4KCkhlbGxvIGxpc3QsPGJyPgo8YnI+CnRsO2RyOiBJcyB0aGVyZSBhIGNoZWFwIG1pZGkgaGFy
ZHdhcmUgdGhhdCBqdXN0IGdldHMgbWlkaSBpbmZvcm1hdGlvbiBpbiBhbmQgcm91dGVzIGl0IG91
dCwgZXhjZXB0IG9uIGEgZGlmZmVyZW50LCBzaW5nbGUsIGNoYW5uZWwgd2hpY2ggSSBjYW4gY2hh
bmdlIGVhc2lseSB1cCBhbmQgZG93biBkaXJlY3RseSBvbiB0aGUgaGFyZHdhcmU/PGJyPgo8YnI+
CkxvbmcgdmVyc2lvbjo8YnI+ClJlY2VudGx5IG15IG1hc3RlciBrZXlib2FyZCBicm9rZS4gSXQg
d2FzIGp1c3QgYSBjaGVhcCwgdXNlZCBtLWF1ZGlvIGtleXN0YXRpb24gNDllLiBJIGRpZCBub3Qg
YnV5IGEgbmV3IG1hc3Rlci1rZXlib2FyZCBiZWNhdXNlIEkgaGF2ZSBhIFJvbGFuZCBIUDIwN2Ug
ZGlnaXRhbCBwaWFubyBoZXJlIHdoaWNoIGlzIHZhc3RseSBzdXBlcmlvciB3aGVuIGl0IGNvbWVz
IHRvIGFjdHVhbCBwbGF5aW5nLiBTYWRseSBub3QgdG8gY29udHJvbCBtaWRpIGRhdGEuPGJyPgoK
Cjxicj4KSSBoYXZlIGEgQmVocmluZ2VyIEJDRjIwMDAgaGVyZSB3aGljaCBJIGNvbm5lY3RlZCB0
byBteSBrZXlib2FyZCBub3csIHNvIEkgc2hvdWxkIGJlIGFibGUgdG8gZG8gc29tZXRoaW5nIHdp
dGggaXQsIGJ1dCB0aGVyZSBpcyBvbmUgdGhpbmcgbWlzc2luZzogQ2hhbm5lbCBDaGFuZ2VzLjxi
cj4KPGJyPgpBbnlib2R5IHdobyB3b3JrZWQgd2l0aCBMaW51eHNhbXBsZXIga25vd3MgdGhhdCBj
aGFubmVsIHN3aXRjaGluZyBpcyB2ZXJ5IGltcG9ydGFudCB0byBzd2l0Y2ggaW5zdHJ1bWVudHMs
IHdoaWxlIHByb2dyYW0gY2hhbmdlcyBhcmUgbmVnbGVjdGFibGUuPGJyPgo8YnI+ClNvIG1heWJl
IHRoZXJlIGlzIGEgd2F5IHRvIHVzZSBteSBwaWFubywgd2hpY2ggYWx3YXlzIHNlbmRzIG9uIHRo
ZSBmaXJzdCBjaGFubmVsIChleGNlcHQgSSBkaXZlIGludG8gaW5hY2Nlc3NpYmxlIG1lbnVzKSBp
Zjxicj4KYSkgSSBmaW5kIGEgd2F5IHRvIHNob3J0Y3V0IHRoZSAmcXVvdDtjaGFuZ2UgY2hhbm5l
bCZxdW90OyBjb21tYW5kLCBidXQgSSBkb24mIzM5O3Qga25vdyBob3cuIEl0IGhhcyBtaWRpIGlu
IGFuZCBhIHVzYiBjb25uZWN0b3IsIGJ1dCB0aGF0IGlzIG5vdCB1c2VkIHRvIGNvbnRyb2wgaXQs
IGp1c3QgdG8gc2VuZCBhbmQgcmVjZWl2ZSBtaWRpIGRhdGEuIEluY29taW5nIGRhdGEgZ2V0cyBp
bnRlcnByZXRlZCBsaWtlIGEgc2FtcGxlciBkb2VzLjxicj4KCgo8YnI+CmIpIFRoZXJlIGlzIGEg
d2F5IHRvIHVzZSBteSBCQ0YyMDAwLiBJIGFtIHZlcnkgaW5leHBlcmllbmNlZCB3aXRoIHRoYXQg
dGhpbmcuPGJyPgo8YnI+CmMpIFRoZXJlIGlzIGEgY2hlYXAgc3RhbmRhbG9uZSBoYXJkd2FyZSwg
anVzdCBhICZxdW90O2xpdHRsZSBib3gmcXVvdDssIEkgY2FuIHBsdWdpbiBiZXR3ZWVuIG15IGxp
bnV4IGJveCBhbmQgdGhlIHBpYW5vLCB3aGljaCByZS1yb3V0ZXMgdGhlIG1pZGkgZGF0YSwgbGlr
ZSBJIG1lbnRpb25lZCBpbiB0aGUgc2hvcnQgdmVyc2lvbiBhYm92ZS48YnI+Cjxicj4KZCkgSSBi
dWlsZCBzb21ldGhpbmcgbXlzZWxmLCBhIHNtYWxsIGxpbnV4IHBsdWcgY29tcHV0ZXIgd2hlcmUg
SSBzb21laG93IGF0dGFjaCB0d28gYnV0dG9ucyAoY2ggdXAgYW5kIGRvdykgYW5kIHVzZSB0aGUg
dXNiIGNvbm5lY3Rpb25zLiBBdCBsZWFzdCB0aGUgY2FibGVzIGFyZSBjaGVhcGVyIDopIKBCdXQg
dGhpcyBpcyB0aGUgbW9zdCB1bnJlYWxpc3RpYyBtZXRob2QsIGFsdGhvdWdoIGl0IG1pZ2h0IGJl
IHRoZSBtb3N0IGludGVyZXN0aW5nIG9uZS48YnI+CgoKPGJyPgo8YnI+Ck1heWJlIHlvdSBrbm93
IHNvbWV0aGluZz88YnI+Cjxicj4KTmlsczxicj4KPGJyPgpQLlMuIEkga25vdyBJIGNhbiBkbyB0
aGUgY2hhbm5lbCByb3V0aW5nIGRpcmVjdGx5IG9uIG15IGxpbnV4IGNvbXB1dGVyLCBhZnRlciBy
ZWNlaXZpbmcgdGhlIGRhdGEgYW5kIGJlZm9yZSBzZW5kaW5nIGl0IHRvIGEgc2FtcGxlci4gQnV0
IHRoYXQgaXMgaW5jb252ZW5pZW50Ljxicj4KPGJyPgo8YnI+Cjxicj4KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+CkxpbnV4LWF1ZGlvLWRldiBtYWls
aW5nIGxpc3Q8YnI+CjxhIGhyZWY9Im1haWx0bzpMaW51eC1hdWRpby1kZXZAbGlzdHMubGludXhh
dWRpby5vcmciPkxpbnV4LWF1ZGlvLWRldkBsaXN0cy5saW51eGF1ZGlvLm9yZzwvYT48YnI+Cjxh
IGhyZWY9Imh0dHA6Ly9saXN0cy5saW51eGF1ZGlvLm9yZy9saXN0aW5mby9saW51eC1hdWRpby1k
ZXYiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbGlzdHMubGludXhhdWRpby5vcmcvbGlzdGluZm8v
bGludXgtYXVkaW8tZGV2PC9hPjxicj4KPC9ibG9ja3F1b3RlPjwvZGl2Pjxicj4K

--===============3728963360794206233==--


From diehl@umich.edu Wed Apr 11 00:46:54 2012
From: Edward Diehl <diehl@umich.edu>
To: linux-audio-dev@lists.linuxaudio.org
Subject: [LAD] How to get NSM?
Date: Wed, 11 Apr 2012 00:46:54 +0000
Message-ID: <330cf12d6a37c01c12ead3e7eb1788a8@umich.edu>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0815787624064910978=="

--===============0815787624064910978==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


I've seen the lengthy discussion of NSM and decided I'd like to give it a
whirl, but I cannot figure out where the code lives.  As far as I can see
http://non.tuxfamily.org/nsm/ has no mention of how to get the code.  So
how do I get (git?) it? Thanks  

--===============0815787624064910978==--


From mark.d.mccurry@gmail.com Wed Apr 11 00:55:09 2012
From: Mark McCurry <mark.d.mccurry@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] How to get NSM?
Date: Wed, 11 Apr 2012 00:55:09 +0000
Message-ID:
 <CAFVXzJkOVBo9i7Nkmz8LVsE-T7D_egSB=HZe96CU3y8-3xv9qw@mail.gmail.com>
In-Reply-To: <330cf12d6a37c01c12ead3e7eb1788a8@umich.edu>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1505559162601324762=="

--===============1505559162601324762==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

> I've seen the lengthy discussion of NSM and decided I'd like to give it a
> whirl, but I cannot figure out where the code lives.  As far as I can see
> http://non.tuxfamily.org/nsm/ has no mention of how to get the code.  So
> how do I get (git?) it? Thanks

Its code seems to currently be in the same repo as Non-DAW.
Here is the clone command:
git clone git://git.tuxfamily.org/gitroot/non/daw.git

--Mark

--===============1505559162601324762==--


From louigi.verona@gmail.com Wed Apr 11 05:20:31 2012
From: Louigi Verona <louigi.verona@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: [LAD] midi and audio connections apps output
Date: Wed, 11 Apr 2012 05:20:31 +0000
Message-ID:
 <CADqqn4-1vG4RbsRDUsEY2C37dbGiS1d2dHvSuUBUMKw3fkW=gw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2692216402193188287=="

--===============2692216402193188287==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hey guys!

I was wondering if JACK, QJackCtl or Patchage or any other programs that
manage audio and midi connections in JACK can output a list of connections
they currently make in text format?
The idea is that when scripting, you would use things like:

jack_disconnect rakarrack-01:out_1 system:playback_1
jack_disconnect rakarrack-01:out_2 system:playback_2

jack_connect specimen:out_left rakarrack:in_1
jack_connect specimen:out_right rakarrack:in_2

It would be pretty cool if when using Patchage you could, for instance, ask
it to output a similar connections list that you would copy and put in your
script.

I do notice though, that it probably would not output disconnect messages,
but only connect ones. But this is still help.

-- 
Louigi Verona
http://www.louigiverona.ru/



--===============2692216402193188287==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

SGV5IGd1eXMhPGJyPjxicj5JIHdhcyB3b25kZXJpbmcgaWYgSkFDSywgUUphY2tDdGwgb3IgUGF0
Y2hhZ2Ugb3IgYW55IG90aGVyIHByb2dyYW1zIHRoYXQgbWFuYWdlIGF1ZGlvIGFuZCBtaWRpIGNv
bm5lY3Rpb25zIGluIEpBQ0sgY2FuIG91dHB1dCBhIGxpc3Qgb2YgY29ubmVjdGlvbnMgdGhleSBj
dXJyZW50bHkgbWFrZSBpbiB0ZXh0IGZvcm1hdD88YnI+VGhlIGlkZWEgaXMgdGhhdCB3aGVuIHNj
cmlwdGluZywgeW91IHdvdWxkIHVzZSB0aGluZ3MgbGlrZTo8YnI+Cjxicj5qYWNrX2Rpc2Nvbm5l
Y3QgcmFrYXJyYWNrLTAxOm91dF8xIHN5c3RlbTpwbGF5YmFja18xPGJyPmphY2tfZGlzY29ubmVj
dCByYWthcnJhY2stMDE6b3V0XzIgc3lzdGVtOnBsYXliYWNrXzI8YnI+PGJyPmphY2tfY29ubmVj
dCBzcGVjaW1lbjpvdXRfbGVmdCByYWthcnJhY2s6aW5fMTxicj5qYWNrX2Nvbm5lY3Qgc3BlY2lt
ZW46b3V0X3JpZ2h0IHJha2FycmFjazppbl8yPGJyPjxicj4KSXQgd291bGQgYmUgcHJldHR5IGNv
b2wgaWYgd2hlbiB1c2luZyBQYXRjaGFnZSB5b3UgY291bGQsIGZvciBpbnN0YW5jZSwgYXNrIGl0
IHRvIG91dHB1dCBhIHNpbWlsYXIgY29ubmVjdGlvbnMgbGlzdCB0aGF0IHlvdSB3b3VsZCBjb3B5
IGFuZCBwdXQgaW4geW91ciBzY3JpcHQuPGJyPjxicj5JIGRvIG5vdGljZSB0aG91Z2gsIHRoYXQg
aXQgcHJvYmFibHkgd291bGQgbm90IG91dHB1dCBkaXNjb25uZWN0IG1lc3NhZ2VzLCBidXQgb25s
eSBjb25uZWN0IG9uZXMuIEJ1dCB0aGlzIGlzIHN0aWxsIGhlbHAuPGJyIGNsZWFyPSJhbGwiPgo8
YnI+LS0gPGJyPkxvdWlnaSBWZXJvbmE8YnI+PGEgaHJlZj0iaHR0cDovL3d3dy5sb3VpZ2l2ZXJv
bmEucnUvIj5odHRwOi8vd3d3LmxvdWlnaXZlcm9uYS5ydS88L2E+PGJyPgo=

--===============2692216402193188287==--


From rosea.grammostola@gmail.com Wed Apr 11 10:08:44 2012
From: "rosea.grammostola" <rosea.grammostola@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] How to get NSM?
Date: Wed, 11 Apr 2012 10:08:44 +0000
Message-ID: <4F855804.6040005@gmail.com>
In-Reply-To:
 <CAFVXzJkOVBo9i7Nkmz8LVsE-T7D_egSB=HZe96CU3y8-3xv9qw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8998502706947885830=="

--===============8998502706947885830==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/11/2012 02:55 AM, Mark McCurry wrote:
>> I've seen the lengthy discussion of NSM and decided I'd like to give it a
>> whirl, but I cannot figure out where the code lives.  As far as I can see
>> http://non.tuxfamily.org/nsm/ has no mention of how to get the code.  So
>> how do I get (git?) it? Thanks
>
> Its code seems to currently be in the same repo as Non-DAW.
> Here is the clone command:
> git clone git://git.tuxfamily.org/gitroot/non/daw.git

Apart from the master branch, there is also a next branch with new stuff 
and a nsm-proxy branch for the new proxy app.

--===============8998502706947885830==--


From thijsvanseveren@gmail.com Wed Apr 11 10:14:44 2012
From: thijs van severen <thijsvanseveren@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] How to get NSM?
Date: Wed, 11 Apr 2012 10:14:44 +0000
Message-ID:
 <CA+SyvD4vm2n7moL8eQxSUSwY95xa7f14TPKMXq0z96DtXQe5GQ@mail.gmail.com>
In-Reply-To: <4F855804.6040005@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4160607637647366039=="

--===============4160607637647366039==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

2012/4/11 rosea.grammostola <rosea.grammostola(a)gmail.com>

> On 04/11/2012 02:55 AM, Mark McCurry wrote:
>
>> I've seen the lengthy discussion of NSM and decided I'd like to give it a
>>> whirl, but I cannot figure out where the code lives.  As far as I can see
>>> http://non.tuxfamily.org/nsm/ has no mention of how to get the code.  So
>>> how do I get (git?) it? Thanks
>>>
>>
>> Its code seems to currently be in the same repo as Non-DAW.
>> Here is the clone command:
>> git clone git://git.tuxfamily.org/**gitroot/non/daw.git<http://git.tuxfami=
ly.org/gitroot/non/daw.git>
>>
>
> Apart from the master branch, there is also a next branch with new stuff
> and a nsm-proxy branch for the new proxy app.
>


are there plans to get it in KXstudio repo's ?



> ______________________________**_________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.**linuxaudio.org<Linux-audio-dev(a)lists.linuxaudio=
.org>
> http://lists.linuxaudio.org/**listinfo/linux-audio-dev<http://lists.linuxau=
dio.org/listinfo/linux-audio-dev>
>



--=20

follow me on my Audio & Linux blog <http://audio-and-linux.blogspot.com/> !



--===============4160607637647366039==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjIwMTIvNC8xMSByb3NlYS5ncmFtbW9zdG9sYSA8c3Bh
biBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpyb3NlYS5ncmFtbW9zdG9sYUBnbWFpbC5j
b20iPnJvc2VhLmdyYW1tb3N0b2xhQGdtYWlsLmNvbTwvYT4mZ3Q7PC9zcGFuPjxicj48YmxvY2tx
dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXIt
bGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4KCk9uIDA0LzExLzIwMTIgMDI6
NTUgQU0sIE1hcmsgTWNDdXJyeSB3cm90ZTo8YnI+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x
dW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlk
O3BhZGRpbmctbGVmdDoxZXgiPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9
Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVm
dDoxZXgiPgpJJiMzOTt2ZSBzZWVuIHRoZSBsZW5ndGh5IGRpc2N1c3Npb24gb2YgTlNNIGFuZCBk
ZWNpZGVkIEkmIzM5O2QgbGlrZSB0byBnaXZlIGl0IGE8YnI+CndoaXJsLCBidXQgSSBjYW5ub3Qg
ZmlndXJlIG91dCB3aGVyZSB0aGUgY29kZSBsaXZlcy4goEFzIGZhciBhcyBJIGNhbiBzZWU8YnI+
CjxhIGhyZWY9Imh0dHA6Ly9ub24udHV4ZmFtaWx5Lm9yZy9uc20vIiB0YXJnZXQ9Il9ibGFuayI+
aHR0cDovL25vbi50dXhmYW1pbHkub3JnL25zbS88L2E+IGhhcyBubyBtZW50aW9uIG9mIGhvdyB0
byBnZXQgdGhlIGNvZGUuIKBTbzxicj4KaG93IGRvIEkgZ2V0IChnaXQ/KSBpdD8gVGhhbmtzPGJy
Pgo8L2Jsb2NrcXVvdGU+Cjxicj4KSXRzIGNvZGUgc2VlbXMgdG8gY3VycmVudGx5IGJlIGluIHRo
ZSBzYW1lIHJlcG8gYXMgTm9uLURBVy48YnI+CkhlcmUgaXMgdGhlIGNsb25lIGNvbW1hbmQ6PGJy
PgpnaXQgY2xvbmUgZ2l0Oi8vPGEgaHJlZj0iaHR0cDovL2dpdC50dXhmYW1pbHkub3JnL2dpdHJv
b3Qvbm9uL2Rhdy5naXQiIHRhcmdldD0iX2JsYW5rIj5naXQudHV4ZmFtaWx5Lm9yZy88dT48L3U+
Z2l0cm9vdC9ub24vZGF3LmdpdDwvYT48YnI+CjwvYmxvY2txdW90ZT4KPGJyPgpBcGFydCBmcm9t
IHRoZSBtYXN0ZXIgYnJhbmNoLCB0aGVyZSBpcyBhbHNvIGEgbmV4dCBicmFuY2ggd2l0aCBuZXcg
c3R1ZmYgYW5kIGEgbnNtLXByb3h5IGJyYW5jaCBmb3IgdGhlIG5ldyBwcm94eSBhcHAuPGJyPjwv
YmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PmFyZSB0aGVyZSBw
bGFucyB0byBnZXQgaXQgaW4gS1hzdHVkaW8gcmVwbyYjMzk7cyA/PC9kaXY+Cgo8ZGl2Pjxicj48
L2Rpdj48ZGl2PqA8L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJt
YXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6
MWV4Ij4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHU+PC91Pl9fX19fX19fX19fX19f
X19fPGJyPgpMaW51eC1hdWRpby1kZXYgbWFpbGluZyBsaXN0PGJyPgo8YSBocmVmPSJtYWlsdG86
TGludXgtYXVkaW8tZGV2QGxpc3RzLmxpbnV4YXVkaW8ub3JnIiB0YXJnZXQ9Il9ibGFuayI+TGlu
dXgtYXVkaW8tZGV2QGxpc3RzLjx1PjwvdT5saW51eGF1ZGlvLm9yZzwvYT48YnI+CjxhIGhyZWY9
Imh0dHA6Ly9saXN0cy5saW51eGF1ZGlvLm9yZy9saXN0aW5mby9saW51eC1hdWRpby1kZXYiIHRh
cmdldD0iX2JsYW5rIj5odHRwOi8vbGlzdHMubGludXhhdWRpby5vcmcvPHU+PC91Pmxpc3RpbmZv
L2xpbnV4LWF1ZGlvLWRldjwvYT48YnI+CjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PGJyIGNsZWFy
PSJhbGwiPjxkaXY+PGJyPjwvZGl2Pi0tIDxicj48YnI+PGRpdj5mb2xsb3cgbWUgb24gbXmgPGEg
aHJlZj0iaHR0cDovL2F1ZGlvLWFuZC1saW51eC5ibG9nc3BvdC5jb20vIiB0YXJnZXQ9Il9ibGFu
ayI+QXVkaW8gJmFtcDsgTGludXggYmxvZzwvYT4gITwvZGl2Pjxicj4K

--===============4160607637647366039==--


From rosea.grammostola@gmail.com Wed Apr 11 10:16:00 2012
From: "rosea.grammostola" <rosea.grammostola@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] How to get NSM?
Date: Wed, 11 Apr 2012 10:16:00 +0000
Message-ID: <4F8559BD.2000402@gmail.com>
In-Reply-To:
 <CA+SyvD4vm2n7moL8eQxSUSwY95xa7f14TPKMXq0z96DtXQe5GQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4563441884451371437=="

--===============4563441884451371437==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/11/2012 12:14 PM, thijs van severen wrote:
> 2012/4/11 rosea.grammostola <rosea.grammostola(a)gmail.com
> <mailto:rosea.grammostola(a)gmail.com>>
>
>     On 04/11/2012 02:55 AM, Mark McCurry wrote:
>
>             I've seen the lengthy discussion of NSM and decided I'd like
>             to give it a
>             whirl, but I cannot figure out where the code lives.  As far
>             as I can see
>             http://non.tuxfamily.org/nsm/ has no mention of how to get
>             the code.  So
>             how do I get (git?) it? Thanks
>
>
>         Its code seems to currently be in the same repo as Non-DAW.
>         Here is the clone command:
>         git clone git://git.tuxfamily.org/__gitroot/non/daw.git
>         <http://git.tuxfamily.org/gitroot/non/daw.git>
>
>
>     Apart from the master branch, there is also a next branch with new
>     stuff and a nsm-proxy branch for the new proxy app.
>
>
>
> are there plans to get it in KXstudio repo's ?
afaik the maintainer will add NSM support to Carla (?), so I'm sure it will.

--===============4563441884451371437==--


From adi@drcomp.erfurt.thur.de Wed Apr 11 10:27:43 2012
From: Adrian Knoth <adi@drcomp.erfurt.thur.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] midi and audio connections apps output
Date: Wed, 11 Apr 2012 10:27:43 +0000
Message-ID: <20120411102737.GU5534@ltw.loris.tv>
In-Reply-To:
 <CADqqn4-1vG4RbsRDUsEY2C37dbGiS1d2dHvSuUBUMKw3fkW=gw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4006450654022611926=="

--===============4006450654022611926==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Wed, Apr 11, 2012 at 09:20:23AM +0400, Louigi Verona wrote:

> Hey guys!

Hi!

> I was wondering if JACK, QJackCtl or Patchage or any other programs that
> manage audio and midi connections in JACK can output a list of connections
> they currently make in text format?

jack_lsp -c


HTH

-- 
mail: adi(a)thur.de  	http://adi.thur.de	PGP/GPG: key via keyserver


--===============4006450654022611926==--


From xbran@web.de Wed Apr 11 10:55:25 2012
From: Emanuel Rumpf <xbran@web.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] How to get NSM?
Date: Wed, 11 Apr 2012 10:55:25 +0000
Message-ID:
 <CAGQuJFJBS+b7pRrm+wpRmdRasHysfoeg-4ZB3VbWTmx5jQm9ww@mail.gmail.com>
In-Reply-To: <4F855804.6040005@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0300874764307623356=="

--===============0300874764307623356==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Am 11. April 2012 12:08 schrieb rosea.grammostola <rosea.grammostola(a)gmail.=
com>:
>> git clone git://git.tuxfamily.org/gitroot/non/daw.git
>
>
> Apart from the master branch, there is also a next branch with new stuff and
> a nsm-proxy branch for the new proxy app.
>
proxy app  - what's that ?

--=20
E.R.

--===============0300874764307623356==--


From adi@drcomp.erfurt.thur.de Wed Apr 11 11:01:54 2012
From: Adrian Knoth <adi@drcomp.erfurt.thur.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] midi and audio connections apps output
Date: Wed, 11 Apr 2012 11:01:54 +0000
Message-ID: <20120411110149.GV5534@ltw.loris.tv>
In-Reply-To:
 <CADqqn48yFOmM_dN+AHEvqocwUyMH8RRw0QbuRUsAgj3e_fKvSQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5008399739280766964=="

--===============5008399739280766964==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Wed, Apr 11, 2012 at 02:47:11PM +0400, Louigi Verona wrote:

Please keep LAD at least CC'ed.

[jack_lsp -c]
> However, this command seems to give the list of available ports. It does
> not show which ones are connected.

It does show the connections, that's why jack_lsp -h says

           -c, --connections     List connections to/from each port

$ jack_lsp -c
[..]
system:capture_34
system:capture_35
system:capture_36
system:playback_1
   PulseAudio JACK Sink:front-left
   MPlayer [9864]:out_0
system:playback_2
   PulseAudio JACK Sink:front-right
   MPlayer [9864]:out_1
system:playback_3
system:playback_4
system:playback_5
[..]

Obviously, "MPlayer [9864]:out_0" and "PulseAudio JACK Sink:front-left"
are both connected to "system:playback_1", likewise for
system:playback_2.

In contrast, system:playback_{3,4,5..} are not connected.



-- 
mail: adi(a)thur.de  	http://adi.thur.de	PGP/GPG: key via keyserver


--===============5008399739280766964==--


From rosea.grammostola@gmail.com Wed Apr 11 11:02:46 2012
From: "rosea.grammostola" <rosea.grammostola@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] How to get NSM?
Date: Wed, 11 Apr 2012 11:02:46 +0000
Message-ID: <4F8564B3.2050405@gmail.com>
In-Reply-To:
 <CAGQuJFJBS+b7pRrm+wpRmdRasHysfoeg-4ZB3VbWTmx5jQm9ww@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1471600261615439390=="

--===============1471600261615439390==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On 04/11/2012 12:55 PM, Emanuel Rumpf wrote:
> Am 11. April 2012 12:08 schrieb rosea.grammostola<rosea.grammostola(a)gmail=
.com>:
>>> git clone git://git.tuxfamily.org/gitroot/non/daw.git
>>
>>
>> Apart from the master branch, there is also a next branch with new stuff a=
nd
>> a nsm-proxy branch for the new proxy app.
>>
> proxy app  - what's that ?
>

If you build the nsm-proxy branch, you're able to add the client=20
nsm-proxy, which allows you to load apps without a state or without NSM=20
support and add some arguments to it as you would do on the command line.

\r

--===============1471600261615439390==--


From louigi.verona@gmail.com Wed Apr 11 11:05:04 2012
From: Louigi Verona <louigi.verona@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] midi and audio connections apps output
Date: Wed, 11 Apr 2012 11:05:04 +0000
Message-ID:
 <CADqqn48g_8uj952W+bFCBL5MMzMBkNWpqnHPAEdfEYzjDgVMYg@mail.gmail.com>
In-Reply-To: <20120411110149.GV5534@ltw.loris.tv>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8469291990104043424=="

--===============8469291990104043424==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Ah, thanks for clearing this up for me. I loaded a simple session and it
had numbers 1 and 2 only which I took simply for port numbers.

On Wed, Apr 11, 2012 at 3:01 PM, Adrian Knoth <adi(a)drcomp.erfurt.thur.de>wr=
ote:

> On Wed, Apr 11, 2012 at 02:47:11PM +0400, Louigi Verona wrote:
>
> Please keep LAD at least CC'ed.
>
> [jack_lsp -c]
> > However, this command seems to give the list of available ports. It does
> > not show which ones are connected.
>
> It does show the connections, that's why jack_lsp -h says
>
>           -c, --connections     List connections to/from each port
>
> $ jack_lsp -c
> [..]
> system:capture_34
> system:capture_35
> system:capture_36
> system:playback_1
>   PulseAudio JACK Sink:front-left
>   MPlayer [9864]:out_0
> system:playback_2
>   PulseAudio JACK Sink:front-right
>   MPlayer [9864]:out_1
> system:playback_3
> system:playback_4
> system:playback_5
> [..]
>
> Obviously, "MPlayer [9864]:out_0" and "PulseAudio JACK Sink:front-left"
> are both connected to "system:playback_1", likewise for
> system:playback_2.
>
> In contrast, system:playback_{3,4,5..} are not connected.
>
>
>
> --
> mail: adi(a)thur.de       http://adi.thur.de      PGP/GPG: key via keyserver
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>



--=20
Louigi Verona
http://www.louigiverona.ru/



--===============8469291990104043424==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

QWgsIHRoYW5rcyBmb3IgY2xlYXJpbmcgdGhpcyB1cCBmb3IgbWUuIEkgbG9hZGVkIGEgc2ltcGxl
IHNlc3Npb24gYW5kIGl0IGhhZCBudW1iZXJzIDEgYW5kIDIgb25seSB3aGljaCBJIHRvb2sgc2lt
cGx5IGZvciBwb3J0IG51bWJlcnMuPGJyPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24g
V2VkLCBBcHIgMTEsIDIwMTIgYXQgMzowMSBQTSwgQWRyaWFuIEtub3RoIDxzcGFuIGRpcj0ibHRy
Ij4mbHQ7PGEgaHJlZj0ibWFpbHRvOmFkaUBkcmNvbXAuZXJmdXJ0LnRodXIuZGUiPmFkaUBkcmNv
bXAuZXJmdXJ0LnRodXIuZGU8L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPgo8YmxvY2txdW90ZSBj
bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDox
cHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij5PbiBXZWQsIEFwciAxMSwgMjAxMiBhdCAw
Mjo0NzoxMVBNICswNDAwLCBMb3VpZ2kgVmVyb25hIHdyb3RlOjxicj4KPGJyPgpQbGVhc2Uga2Vl
cCBMQUQgYXQgbGVhc3QgQ0MmIzM5O2VkLjxicj4KPGJyPgpbamFja19sc3AgLWNdPGJyPgo8ZGl2
IGNsYXNzPSJpbSI+Jmd0OyBIb3dldmVyLCB0aGlzIGNvbW1hbmQgc2VlbXMgdG8gZ2l2ZSB0aGUg
bGlzdCBvZiBhdmFpbGFibGUgcG9ydHMuIEl0IGRvZXM8YnI+CiZndDsgbm90IHNob3cgd2hpY2gg
b25lcyBhcmUgY29ubmVjdGVkLjxicj4KPGJyPgo8L2Rpdj5JdCBkb2VzIHNob3cgdGhlIGNvbm5l
Y3Rpb25zLCB0aGF0JiMzOTtzIHdoeSBqYWNrX2xzcCAtaCBzYXlzPGJyPgo8YnI+CiCgIKAgoCCg
IKAgLWMsIC0tY29ubmVjdGlvbnMgoCCgIExpc3QgY29ubmVjdGlvbnMgdG8vZnJvbSBlYWNoIHBv
cnQ8YnI+Cjxicj4KJCBqYWNrX2xzcCAtYzxicj4KWy4uXTxicj4Kc3lzdGVtOmNhcHR1cmVfMzQ8
YnI+CnN5c3RlbTpjYXB0dXJlXzM1PGJyPgpzeXN0ZW06Y2FwdHVyZV8zNjxicj4Kc3lzdGVtOnBs
YXliYWNrXzE8YnI+CiCgIFB1bHNlQXVkaW8gSkFDSyBTaW5rOmZyb250LWxlZnQ8YnI+CiCgIE1Q
bGF5ZXIgWzk4NjRdOm91dF8wPGJyPgpzeXN0ZW06cGxheWJhY2tfMjxicj4KIKAgUHVsc2VBdWRp
byBKQUNLIFNpbms6ZnJvbnQtcmlnaHQ8YnI+CiCgIE1QbGF5ZXIgWzk4NjRdOm91dF8xPGJyPgpz
eXN0ZW06cGxheWJhY2tfMzxicj4Kc3lzdGVtOnBsYXliYWNrXzQ8YnI+CnN5c3RlbTpwbGF5YmFj
a181PGJyPgpbLi5dPGJyPgo8YnI+Ck9idmlvdXNseSwgJnF1b3Q7TVBsYXllciBbOTg2NF06b3V0
XzAmcXVvdDsgYW5kICZxdW90O1B1bHNlQXVkaW8gSkFDSyBTaW5rOmZyb250LWxlZnQmcXVvdDs8
YnI+CmFyZSBib3RoIGNvbm5lY3RlZCB0byAmcXVvdDtzeXN0ZW06cGxheWJhY2tfMSZxdW90Oywg
bGlrZXdpc2UgZm9yPGJyPgpzeXN0ZW06cGxheWJhY2tfMi48YnI+Cjxicj4KSW4gY29udHJhc3Qs
IHN5c3RlbTpwbGF5YmFja197Myw0LDUuLn0gYXJlIG5vdCBjb25uZWN0ZWQuPGJyPgo8ZGl2IGNs
YXNzPSJIT0VuWmIiPjxkaXYgY2xhc3M9Img1Ij48YnI+Cjxicj4KPGJyPgotLTxicj4KbWFpbDog
PGEgaHJlZj0ibWFpbHRvOmFkaUB0aHVyLmRlIj5hZGlAdGh1ci5kZTwvYT4goCCgIKAgPGEgaHJl
Zj0iaHR0cDovL2FkaS50aHVyLmRlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2FkaS50aHVyLmRl
PC9hPiCgIKAgoFBHUC9HUEc6IGtleSB2aWEga2V5c2VydmVyPGJyPgo8YnI+Cl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPgpMaW51eC1hdWRpby1kZXYg
bWFpbGluZyBsaXN0PGJyPgo8YSBocmVmPSJtYWlsdG86TGludXgtYXVkaW8tZGV2QGxpc3RzLmxp
bnV4YXVkaW8ub3JnIj5MaW51eC1hdWRpby1kZXZAbGlzdHMubGludXhhdWRpby5vcmc8L2E+PGJy
Pgo8YSBocmVmPSJodHRwOi8vbGlzdHMubGludXhhdWRpby5vcmcvbGlzdGluZm8vbGludXgtYXVk
aW8tZGV2IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2xpc3RzLmxpbnV4YXVkaW8ub3JnL2xpc3Rp
bmZvL2xpbnV4LWF1ZGlvLWRldjwvYT48YnI+CjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rp
dj48YnI+PGJyIGNsZWFyPSJhbGwiPjxicj4tLSA8YnI+TG91aWdpIFZlcm9uYTxicj48YSBocmVm
PSJodHRwOi8vd3d3LmxvdWlnaXZlcm9uYS5ydS8iPmh0dHA6Ly93d3cubG91aWdpdmVyb25hLnJ1
LzwvYT48YnI+Cg==

--===============8469291990104043424==--


From rosea.grammostola@gmail.com Wed Apr 11 12:43:28 2012
From: "rosea.grammostola" <rosea.grammostola@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 11 Apr 2012 12:43:28 +0000
Message-ID: <4F857C4C.4080409@gmail.com>
In-Reply-To: <20120409171029.GC31907@linuxaudio.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2475794910422450538=="

--===============2475794910422450538==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

It might be a good idea to discuss NSM (and it's implementation) and 
compare it with other Session Managers, at LAC2012. Such a conference 
could be a nice opportunity to share ideas to improve Linuxaudio session 
management in general. Unfortunately I'm not able to attend this year.

For those who go, have fun! :)

Regards,
\r

--===============2475794910422450538==--


From dlphillips@woh.rr.com Wed Apr 11 13:18:26 2012
From: Dave Phillips <dlphillips@woh.rr.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 11 Apr 2012 13:18:26 +0000
Message-ID: <4F8584A1.6000201@woh.rr.com>
In-Reply-To: <4F857C4C.4080409@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8914028718638689475=="

--===============8914028718638689475==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/11/2012 08:42 AM, rosea.grammostola wrote:
> It might be a good idea to discuss NSM (and it's implementation) and 
> compare it with other Session Managers, at LAC2012. Such a conference 
> could be a nice opportunity to share ideas to improve Linuxaudio 
> session management in general. Unfortunately I'm not able to attend 
> this year.
>
> For those who go, have fun! :)

Hey Dirk,

We'll miss you ! I still tell people about the fellow who approached me 
on a train platform in Dublin and asked if I was Dave Phillips. :)  
Well, I hope we'll see you next year, and I'll be sure to hoist a few 
for you during the symposia.

Best,

dp



--===============8914028718638689475==--


From rosea.grammostola@gmail.com Wed Apr 11 13:37:08 2012
From: "rosea.grammostola" <rosea.grammostola@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 11 Apr 2012 13:37:08 +0000
Message-ID: <4F8588DE.20303@gmail.com>
In-Reply-To: <4F8584A1.6000201@woh.rr.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8732605911042038891=="

--===============8732605911042038891==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/11/2012 03:18 PM, Dave Phillips wrote:
> Hey Dirk,
>
> We'll miss you ! I still tell people about the fellow who approached me
> on a train platform in Dublin and asked if I was Dave Phillips.

Hehe, I did the same when I saw Bono standing at Dublin central. He 
still tells his friends about it to. Must feel good apparently, when 
you're famous and people you have no clue about, recognize you in the 
middle of a crowd :)

Have a good time!

--===============8732605911042038891==--


From rennabh@gmail.com Wed Apr 11 14:31:14 2012
From: Renato <rennabh@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 11 Apr 2012 14:31:14 +0000
Message-ID: <20120411162801.4f76d054@gmail.com>
In-Reply-To: <4F8588DE.20303@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5548392124139196367=="

--===============5548392124139196367==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Wed, 11 Apr 2012 15:36:30 +0200
"rosea.grammostola" <rosea.grammostola(a)gmail.com> wrote:

> On 04/11/2012 03:18 PM, Dave Phillips wrote:
> > Hey Dirk,
> >
> > We'll miss you ! I still tell people about the fellow who
> > approached me on a train platform in Dublin and asked if I was Dave
> > Phillips.
> 
> Hehe, I did the same when I saw Bono standing at Dublin central. 

rosea.grammostola AKA Dublin's station stalker ;)

renato

--===============5548392124139196367==--


From malnourite@gmail.com Wed Apr 11 16:32:04 2012
From: "J. Liles" <malnourite@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] NSM - handling large files
Date: Wed, 11 Apr 2012 16:32:04 +0000
Message-ID:
 <CAGhWSSYrEbh5e+Mgw6O=DU87AK-v0=Dtkw8gDuAgR=p7LhN4zg@mail.gmail.com>
In-Reply-To: <4F857C4C.4080409@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0053162339204438523=="

--===============0053162339204438523==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Wed, Apr 11, 2012 at 5:42 AM, rosea.grammostola <
rosea.grammostola(a)gmail.com> wrote:

> It might be a good idea to discuss NSM (and it's implementation) and
> compare it with other Session Managers, at LAC2012. Such a conference could
> be a nice opportunity to share ideas to improve Linuxaudio session
> management in general. Unfortunately I'm not able to attend this year.
>
> For those who go, have fun! :)
>
> Regards,
> \r
>
>
Since I will not attending, those who do are recommended to print this out
and display it where it will be visible to the presenters in my absence:

http://www.quickmeme.com/meme/3oqu2r/

(/me was torn between this and "Not sure if stupid/or works for Microsoft")

Have fun y'all!



--===============0053162339204438523==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBXZWQsIEFwciAxMSwgMjAxMiBhdCA1OjQy
IEFNLCByb3NlYS5ncmFtbW9zdG9sYSA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0
bzpyb3NlYS5ncmFtbW9zdG9sYUBnbWFpbC5jb20iPnJvc2VhLmdyYW1tb3N0b2xhQGdtYWlsLmNv
bTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3Rl
IiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFk
ZGluZy1sZWZ0OjFleCI+Ckl0IG1pZ2h0IGJlIGEgZ29vZCBpZGVhIHRvIGRpc2N1c3MgTlNNIChh
bmQgaXQmIzM5O3MgaW1wbGVtZW50YXRpb24pIGFuZCBjb21wYXJlIGl0IHdpdGggb3RoZXIgU2Vz
c2lvbiBNYW5hZ2VycywgYXQgTEFDMjAxMi4gU3VjaCBhIGNvbmZlcmVuY2UgY291bGQgYmUgYSBu
aWNlIG9wcG9ydHVuaXR5IHRvIHNoYXJlIGlkZWFzIHRvIGltcHJvdmUgTGludXhhdWRpbyBzZXNz
aW9uIG1hbmFnZW1lbnQgaW4gZ2VuZXJhbC4gVW5mb3J0dW5hdGVseSBJJiMzOTttIG5vdCBhYmxl
IHRvIGF0dGVuZCB0aGlzIHllYXIuPGJyPgoKPGJyPgpGb3IgdGhvc2Ugd2hvIGdvLCBoYXZlIGZ1
biEgOik8YnI+Cjxicj4KUmVnYXJkcyw8YnI+ClxyPGRpdiBjbGFzcz0iSE9FblpiIj48ZGl2IGNs
YXNzPSJoNSI+PGJyPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj5TaW5jZSBJIHdp
bGwgbm90IGF0dGVuZGluZywgdGhvc2Ugd2hvIGRvIGFyZSByZWNvbW1lbmRlZCB0byBwcmludCB0
aGlzIG91dCBhbmQgZGlzcGxheSBpdCB3aGVyZSBpdCB3aWxsIGJlIHZpc2libGUgdG8gdGhlIHBy
ZXNlbnRlcnMgaW4gbXkgYWJzZW5jZTo8YnI+Cjxicj48YSBocmVmPSJodHRwOi8vd3d3LnF1aWNr
bWVtZS5jb20vbWVtZS8zb3F1MnIvIj5odHRwOi8vd3d3LnF1aWNrbWVtZS5jb20vbWVtZS8zb3F1
MnIvPC9hPjxicj48YnI+KC9tZSB3YXMgdG9ybiBiZXR3ZWVuIHRoaXMgYW5kICZxdW90O05vdCBz
dXJlIGlmIHN0dXBpZC9vciB3b3JrcyBmb3IgTWljcm9zb2Z0JnF1b3Q7KTxicj48YnI+SGF2ZSBm
dW4geSYjMzk7YWxsITxicj48YnI+CjwvZGl2PjwvZGl2Pgo=

--===============0053162339204438523==--


From rosea.grammostola@gmail.com Wed Apr 11 17:47:29 2012
From: "rosea.grammostola" <rosea.grammostola@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] How to get NSM?
Date: Wed, 11 Apr 2012 17:47:29 +0000
Message-ID: <4F85C38B.3080301@gmail.com>
In-Reply-To: <4F8564B3.2050405@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2528209010440321221=="

--===============2528209010440321221==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/11/2012 01:02 PM, rosea.grammostola wrote:
> On 04/11/2012 12:55 PM, Emanuel Rumpf wrote:
>> Am 11. April 2012 12:08 schrieb
>> rosea.grammostola<rosea.grammostola(a)gmail.com>:
>>>> git clone git://git.tuxfamily.org/gitroot/non/daw.git
>>>
>>>
>>> Apart from the master branch, there is also a next branch with new
>>> stuff and
>>> a nsm-proxy branch for the new proxy app.
>>>
>> proxy app - what's that ?
>>
>
> If you build the nsm-proxy branch, you're able to add the client
> nsm-proxy, which allows you to load apps without a state or without NSM
> support and add some arguments to it as you would do on the command line.
>
> \r

This script should work to load LinuxSampler as binary in a nsm-proxy. 
The lscp file should be loaded via the argument option in the nsm-proxy.
Only problem I have, it doesn't kill LinuxSampler, when I stop the 
nsm-proxy or the session. I probably miss something, maybe someone can 
test it too.


#!/bin/bash

linuxsampler &

LSPID=$!

# wait for LS to init
sleep 4;

# tell it what file to load
cat "$1" | nc localhost 8888

#handle SIGTERM from NSM by killing LS.
trap 'kill -TERM $LSPID' SIGTERM

#wait for LS to die naturally
wait $LSPID

--===============2528209010440321221==--


From nettings@stackingdwarves.net Wed Apr 11 17:55:47 2012
From: =?utf-8?q?J=C3=B6rn?= Nettingsmeier <nettings@stackingdwarves.net>
To: linux-audio-dev@lists.linuxaudio.org
Subject: [LAD] Linux Audio Conference 2012 at CCRMA - live stream coverage
 starting tomorrow
Date: Wed, 11 Apr 2012 17:55:47 +0000
Message-ID: <4F85C59C.60203@stackingdwarves.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5980778747149912336=="

--===============5980778747149912336==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi *!


On behalf of the conference organizers, we would like to invite you to 
join the Linux Audio Conference 2012, kindly hosted by the Center for 
Computer Research in Music and Acoustics (CCRMA) at Stanford University.

The conference will start tomorrow, Thursday April 12, at 10:00 PST 
(that's UTC - 0700). Please refer to the schedule at

    http://lac.linuxaudio.org/2012/program

for detailed information.

We will be streaming all paper presentations live in Ogg Theora/Ogg 
Vorbis format. Users of the Firefox browser should be able to watch this 
natively without any plugins. For users of other browsers, we recommend 
VLC, a cross-platform media player which you can download from 
http://videolan.org.

You are invited to join us on IRC while you're watching the streams, the 
conference channel is #lac2012 on freenode.net, to be accessed with the 
chat client of your choice, or via 
http://webchat.freenode.net/?channels=lac2012
Remote participants can post their questions or remarks on this channel, 
and a local chat operator here in Stanford will then relay them to the 
presenters and the local audience. You can also use this channel to get 
help in case of viewing problems.

All presentations will be recorded and uploaded for off-line watching 
within a day or so.

Needless to say, access to all streams is free of charge. This is all 
about open source after all :)

The primary stream relay is available at

    http://ccrma.stanford.edu:8080 (located on the west coast of the US).

A secondary relay which is preferrable for European users is at

    http://streamer.stackingdwarves.net (located in Germany).


Best regards,


the LAC stream team.


--===============5980778747149912336==--


From d@drobilla.net Sat Apr 14 02:42:41 2012
From: David Robillard <d@drobilla.net>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] Plugin CV ports (WAS:  AMS LV2 plugins: Version 0.0.6)
Date: Sat, 14 Apr 2012 02:42:41 +0000
Message-ID: <1334371354.19959.4.camel@verne.drobilla.net>
In-Reply-To: <1331495624.13607.24.camel@verne.drobilla.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0600827829762638065=="

--===============0600827829762638065==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Sun, 2012-03-11 at 15:53 -0400, David Robillard wrote:
> I implemented cv:CVPort[1] for these plugins (a CVPort is just an
> AudioPort that works as a control)
> [...]

Since the cv-port extension was literally just this one URI, the port
type doesn't really introduce anything new (same format as
lv2:AudioPort, used like an lv2:ControlPort), and abuse of audio ports
for this has been around since the early LADSPA days, I just moved this
to the core spec.  So, lv2:CVPort is the type now.

Cheers,

-dr, attempting to minimize the shotgun-blast-of-extensions thing


--===============0600827829762638065==--


From andreas.degert@googlemail.com Sat Apr 14 22:19:59 2012
From: Andreas Degert <andreas.degert@googlemail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: [LAD] Guitarix release 0.22.0
Date: Sat, 14 Apr 2012 22:19:59 +0000
Message-ID:
 <CAHccUrK4iuUBFuSpG0QnF0CU+g0Mv_s32_WRRLwk58T4iro5eg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7653658916056111345=="

--===============7653658916056111345==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

After two beta releases, we are proud to announce the final release
"drag-on-fly" guitarix2-0.22.0.

Guitarix is a tube amplifier simulation for jack, with effect modules
and an additional stereo effect chain.

Download from http://sourceforge.net/projects/guitarix/

You can find some screenshots and explanations of the new version in

https://sourceforge.net/apps/mediawiki/guitarix/index.php?title=EnhancedUI

Things that changed since the beta2 release:

 * many small fixes and enhancements
 * compile fixes for several environments
 * convolver unit
   * fixed crash
   * presets like for other rack units (instead of the old "favourites")
 * for beta users: parameter scaling for Vibe unit changed.
   if you stored a preset with Vibe settings you'll have to
   adjust the values (sorry).
 * if you see corrupted graphics in screen animations: it is probably a
   video driver bug. You can try to set Option "EXAPixmaps" "off" at the
   end of the device section in xorg.conf (location depending on system,
   e.g. /etc/X11/xorg.conf.d/ati.conf).


Announcement text from the beta releases:

Many things changed in the user interface. You can move rack units
by drag and drop (reflecting the signal flow), store individual
settings for each rack unit and use preset banks with several settings
for the whole rack. It's easy to take our "factory presets" and make
your own customized bank, or make your own from scratch and share it
on the Guitarix forum.

There is a new "live play mode" with only the info you need on stage
(it's fullscreen, no other penguins around), and a preset picking mode
with a foot switch (midi or usb, or if you don't have one even the
space bar of your keyboard) and the strings of your guitar to switch
settings.

Rack units are now put into categories, and two new ones are a noise
gate for high noise levels and a univibe emulation. Thanks go to the
developer of abGate and the nice guys from Rakarrack who helped
porting their univibe code and made the inclusion of it possible.

This is already too long, please check it out and give feedback if you
find a problem, this version is still beta.

Please refer to our project page for more information:

       http://guitarix.sourceforge.net/

download site:
       http://sourceforge.net/projects/guitarix/

please report bugs and suggestions in our forum:
       http://sourceforge.net/apps/phpbb/guitarix/

here you can find a couple of examples produced by guitarix users:
       http://sourceforge.net/apps/phpbb/guitarix/viewtopic.php?f=11&t=83

have fun

_________________________________________________________________________


For extra Impulse Responses, guitarix uses the zita-convolver library,
and, for resampling we use zita-resampler, both written by Fons
Adriaensen.

        http://kokkinizita.linuxaudio.org/linuxaudio/index.html

We use the marvellous faust compiler to build the amp and most effects
and will say thanks to

        : Julius Smith
        http://ccrma.stanford.edu/realsimple/faust/

        : Albert Graef
        http://q-lang.sourceforge.net/examples.html#Faust

        : Yann Orlary
        http://faust.grame.fr/
________________________________________________________________________


       guitarix development team

--===============7653658916056111345==--


From jens.andreasen@comhem.se Sun Apr 15 04:33:50 2012
From: Jens M Andreasen <jens.andreasen@comhem.se>
To: linux-audio-dev@lists.linuxaudio.org
Subject: [LAD] 3.4-rc2-rt2, -EXPORT_SYMBOL_GPL
Date: Sun, 15 Apr 2012 04:33:50 +0000
Message-ID: <1334464386.7644.6.camel@mx44.linux.dk>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8272451006730062819=="

--===============8272451006730062819==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit



Looks like the Nvidia driver just got happily married to realtime, low
latency Linux - again, no?  .. From tglx:


http://article.gmane.org/gmane.linux.rt.user/8150

Changes since 3.4-rc2-rt2: ...

  * Remove the _GPL restriction from a few exports

    This restores the status quo of pre 3.0 RT versions. 
	  
    I fundamentally hate this change, but the point is, that RT
    replaces non GPL exports with GPL ones and therefor breaks
    "legitimate" abuses of the kernel.

    OTOH I've been exposed to source code of some secret sauce
    drivers. That makes me believe that in a lot of cases the reason
    for not disclosing the driver code is that publishing might put
    the innocent and unprepared reader in danger of gastric ulcer and
    eyecancer.

    So I commit this change for health protection reasons.



-- 
JMA - Harlequin
http://web.comhem.se/mx44turbo/cute/harlequin.mp3


--===============8272451006730062819==--


From audiomobster@googlemail.com Sun Apr 15 15:57:53 2012
From: Ulrich-Lorenz =?utf-8?q?Schl=C3=BCter?= <audiomobster@googlemail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: [LAD] jackmixdesk undefined references
Date: Sun, 15 Apr 2012 15:57:53 +0000
Message-ID: <4F8AEF4D.3040607@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8433342540570060707=="

--===============8433342540570060707==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hello there.

Can these files be a cause for undefined references when compiling?
I have to compile them into the binary, because phat from svn makes
problems.

configure.ac


> dnl Require autoconf version >= 2.57
> AC_PREREQ(2.57)
>
> dnl ############# Initialization
>
> AC_INIT([jackmixdesk], [0.4], [audio-mobster(a)gmx.de])
>
> AC_CONFIG_SRCDIR([mixdesk.c])
> AC_CANONICAL_SYSTEM
>
> dnl Version 1.7 of automake is recommended
> AM_INIT_AUTOMAKE([1.7])
> AM_CONFIG_HEADER([config.h])
>
>
> dnl ############# Compiler and tools Checks
>
> AC_PROG_CC
> AC_PROG_INSTALL
> AC_PROG_LN_S
> AC_C_INLINE
>
>
> dnl ############## Library Checks
>
> AC_CHECK_LIB([m], [sqrt], , [AC_MSG_ERROR(Can't find libm)])
> AC_CHECK_LIB([m], [powf])
>
> # Check for libjack (need 0.100.0 for jack_client_open)
> PKG_CHECK_MODULES(JACK, jack >= 0.100.0)
>
> # Check for liblash
> PKG_CHECK_MODULES(LASH, lash-1.0)
>
> # Check for liblo
> PKG_CHECK_MODULES(LO, liblo >= 0.23)
>
> # Check for libxml2
> PKG_CHECK_MODULES(XML2, libxml-2.0 >= 2.6.27)
>
> # Check for GTK 2.0
> PKG_CHECK_MODULES(GTK, gtk+-2.0, HAVE_GTK="Yes", HAVE_GTK="No")
>
> # Check for libX11
> PKG_CHECK_MODULES(X11, x11, HAVE_X11="Yes", HAVE_X11="No")
>
> # Check for libgnomecanvas
> PKG_CHECK_MODULES(LIBGNOMECANVAS, libgnomecanvas-2.0,
> HAVE_LIBGNOMECANVAS="Yes", HAVE_LIBGNOMECANVAS="No")
>
> # Check for libidn
> PKG_CHECK_MODULES(IDN, libidn, HAVE_IDN="Yes", HAVE_IDN="No")
>
>
> dnl ############## Decide what to build
>
> BUILD_PROGRAMS="jackmixdesk"
>
> if test "x$HAVE_GTK" == "xYes"
>    test "x$HAVE_LIBGNOMECANVAS" == "xYes"
>    test "x$HAVE_IDN" == "xYes"
>    test "x$HAVE_X11" == "xYes"
> then
>     BUILD_PROGRAMS="$BUILD_PROGRAMS jackmixdesk_gtk"
> else
>     AC_MSG_WARN([Not building GTK frontend due to missing libraries])
> fi  
>
> AC_SUBST(BUILD_PROGRAMS)
>
>
>
> dnl ############## Header Checks
>
> AC_HEADER_STDC
> AC_CHECK_HEADERS([stdlib.h string.h strings.h sys/time.h unistd.h])
>
> # Checks for typedefs, structures, and compiler characteristics.
> AC_C_CONST
> AC_C_INLINE
> AC_TYPE_SIZE_T
> AC_TYPE_SIGNAL
>
> # Checks for library functions.
> AC_FUNC_MALLOC
>
> AC_CONFIG_FILES([Makefile])
>
> AC_OUTPUT
Makefile.am


> AUTOMAKE_OPTIONS = foreign
>
> bin_PROGRAMS = @BUILD_PROGRAMS@
> EXTRA_PROGRAMS = jackmixdesk jackmixdesk_gtk
>
> jackmixdesk_SOURCES = mixdesk.c db.h
>
> jackmixdesk_CFLAGS = -Wall -O2 @JACK_CFLAGS@ @LASH_CFLAGS@ @LO_CFLAGS@
> @XML2_CFLAGS@
>
> jackmixdesk_LDFLAGS = -lm @JACK_LIBS@ @LASH_LIBS@ @LO_LIBS@ @XML2_LIBS@
>
> jackmixdesk_gtk_SOURCES = config.h phatknob.h phatknob.c \
> phatvfanslider.c phathfanslider.c \
> phatkeyboard.c phatpad.h phatvkeyboard.h phatkeyboard.h  phatprivate.h \
> phathfanslider.h  phathkeyboard.c phatprivate.c  phatfanslider.h\
> phathkeyboard.h phatpad.c phatvfanslider.h mixdesk_gtk.c
>
> jackmixdesk_gtk_CFLAGS = -Wall -O2 @JACK_CFLAGS@ @IDN_CFLAGS@
> @LO_CFLAGS@ \
> @GTK_CFLAGS@ @LIBGNOMECANVAS_CFLAGS@ @LASH_CFLAGS@ @XML2_CFLAGS@
> @X11_CFLAGS@ -DINSTALL_DIR=\"$(datadir)\"
>
> jackmixdesk_gtk_LDFLAGS = -lm @JACK_LIBS@ @IDN_LIBS@ @LO_LIBS@
> @GTK_LIBS@ @X11_LIBS@ \
> @LIBGNOMECANVAS_LIBS@ @LASH_LIBS@ @XML2_LIBS@
>
> pixmapdir =$(datadir)/$(PACKAGE)/pixmaps
> pixmap_DATA = knob.png
>
> licensedir =$(datadir)/doc/$(PACKAGE)-$(VERSION)
> license_DATA = COPYING
>
> readmedir =$(datadir)/doc/$(PACKAGE)-$(VERSION)
> readme_DATA = README
>
> svgdiagramdir =$(datadir)/doc/$(PACKAGE)-$(VERSION)
> svgdiagram_DATA = jackmixdesk.svg
>
> pngdiagramdir =$(datadir)/doc/$(PACKAGE)-$(VERSION)
> pngdiagram_DATA = jackmixdesk.png
>
> tododir =$(datadir)/doc/$(PACKAGE)-$(VERSION)
> todo_DATA = TODO
>
> EXTRA_DIST = autogen.sh TODO doc/jackmixdesk.svg
Thanks a lot

Uli





--===============8433342540570060707==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PGh0bWw+CiAgPGhlYWQ+CgogICAgPG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250
ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9SVNPLTg4NTktMTUiPgogIDwvaGVhZD4KICA8Ym9keSBi
Z2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAwIj4KICAgIDxkaXYgY2xhc3M9Im1vei10ZXh0
LXBsYWluIiB3cmFwPSJ0cnVlIiBncmFwaGljYWwtcXVvdGU9InRydWUiCiAgICAgIHN0eWxlPSJm
b250LWZhbWlseTogLW1vei1maXhlZDsgZm9udC1zaXplOiAxMnB4OyIgbGFuZz0ieC13ZXN0ZXJu
Ij4KICAgICAgPHByZSB3cmFwPSIiPkhlbGxvIHRoZXJlLgoKQ2FuIHRoZXNlIGZpbGVzIGJlIGEg
Y2F1c2UgZm9yIHVuZGVmaW5lZCByZWZlcmVuY2VzIHdoZW4gY29tcGlsaW5nPwpJIGhhdmUgdG8g
Y29tcGlsZSB0aGVtIGludG8gdGhlIGJpbmFyeSwgYmVjYXVzZSBwaGF0IGZyb20gc3ZuIG1ha2Vz
CnByb2JsZW1zLgoKY29uZmlndXJlLmFjCgo8L3ByZT4KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0i
Y2l0ZSIgc3R5bGU9ImNvbG9yOiAjMDAwMDAwOyI+CiAgICAgICAgPHByZSB3cmFwPSIiPmRubCBS
ZXF1aXJlIGF1dG9jb25mIHZlcnNpb24gJmd0Oz0gMi41NwpBQ19QUkVSRVEoMi41NykKCmRubCAj
IyMjIyMjIyMjIyMjIEluaXRpYWxpemF0aW9uCgpBQ19JTklUKFtqYWNrbWl4ZGVza10sIFswLjRd
LCBbPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOmF1ZGlv
LW1vYnN0ZXJAZ214LmRlIj5hdWRpby1tb2JzdGVyQGdteC5kZTwvYT5dKQoKQUNfQ09ORklHX1NS
Q0RJUihbbWl4ZGVzay5jXSkKQUNfQ0FOT05JQ0FMX1NZU1RFTQoKZG5sIFZlcnNpb24gMS43IG9m
IGF1dG9tYWtlIGlzIHJlY29tbWVuZGVkCkFNX0lOSVRfQVVUT01BS0UoWzEuN10pCkFNX0NPTkZJ
R19IRUFERVIoW2NvbmZpZy5oXSkKCgpkbmwgIyMjIyMjIyMjIyMjIyBDb21waWxlciBhbmQgdG9v
bHMgQ2hlY2tzCgpBQ19QUk9HX0NDCkFDX1BST0dfSU5TVEFMTApBQ19QUk9HX0xOX1MKQUNfQ19J
TkxJTkUKCgpkbmwgIyMjIyMjIyMjIyMjIyMgTGlicmFyeSBDaGVja3MKCkFDX0NIRUNLX0xJQihb
bV0sIFtzcXJ0XSwgLCBbQUNfTVNHX0VSUk9SKENhbid0IGZpbmQgbGlibSldKQpBQ19DSEVDS19M
SUIoW21dLCBbcG93Zl0pCgojIENoZWNrIGZvciBsaWJqYWNrIChuZWVkIDAuMTAwLjAgZm9yIGph
Y2tfY2xpZW50X29wZW4pClBLR19DSEVDS19NT0RVTEVTKEpBQ0ssIGphY2sgJmd0Oz0gMC4xMDAu
MCkKCiMgQ2hlY2sgZm9yIGxpYmxhc2gKUEtHX0NIRUNLX01PRFVMRVMoTEFTSCwgbGFzaC0xLjAp
CgojIENoZWNrIGZvciBsaWJsbwpQS0dfQ0hFQ0tfTU9EVUxFUyhMTywgbGlibG8gJmd0Oz0gMC4y
MykKCiMgQ2hlY2sgZm9yIGxpYnhtbDIKUEtHX0NIRUNLX01PRFVMRVMoWE1MMiwgbGlieG1sLTIu
MCAmZ3Q7PSAyLjYuMjcpCgojIENoZWNrIGZvciBHVEsgMi4wClBLR19DSEVDS19NT0RVTEVTKEdU
SywgZ3RrKy0yLjAsIEhBVkVfR1RLPSJZZXMiLCBIQVZFX0dUSz0iTm8iKQoKIyBDaGVjayBmb3Ig
bGliWDExClBLR19DSEVDS19NT0RVTEVTKFgxMSwgeDExLCBIQVZFX1gxMT0iWWVzIiwgSEFWRV9Y
MTE9Ik5vIikKCiMgQ2hlY2sgZm9yIGxpYmdub21lY2FudmFzClBLR19DSEVDS19NT0RVTEVTKExJ
QkdOT01FQ0FOVkFTLCBsaWJnbm9tZWNhbnZhcy0yLjAsCkhBVkVfTElCR05PTUVDQU5WQVM9Illl
cyIsIEhBVkVfTElCR05PTUVDQU5WQVM9Ik5vIikKCiMgQ2hlY2sgZm9yIGxpYmlkbgpQS0dfQ0hF
Q0tfTU9EVUxFUyhJRE4sIGxpYmlkbiwgSEFWRV9JRE49IlllcyIsIEhBVkVfSUROPSJObyIpCgoK
ZG5sICMjIyMjIyMjIyMjIyMjIERlY2lkZSB3aGF0IHRvIGJ1aWxkCgpCVUlMRF9QUk9HUkFNUz0i
amFja21peGRlc2siCgppZiB0ZXN0ICJ4JEhBVkVfR1RLIiA9PSAieFllcyIKICAgdGVzdCAieCRI
QVZFX0xJQkdOT01FQ0FOVkFTIiA9PSAieFllcyIKICAgdGVzdCAieCRIQVZFX0lETiIgPT0gInhZ
ZXMiCiAgIHRlc3QgIngkSEFWRV9YMTEiID09ICJ4WWVzIgp0aGVuCiAgICBCVUlMRF9QUk9HUkFN
Uz0iJEJVSUxEX1BST0dSQU1TIGphY2ttaXhkZXNrX2d0ayIKZWxzZQogICAgQUNfTVNHX1dBUk4o
W05vdCBidWlsZGluZyBHVEsgZnJvbnRlbmQgZHVlIHRvIG1pc3NpbmcgbGlicmFyaWVzXSkKZmkg
IAoKQUNfU1VCU1QoQlVJTERfUFJPR1JBTVMpCgoKCmRubCAjIyMjIyMjIyMjIyMjIyBIZWFkZXIg
Q2hlY2tzCgpBQ19IRUFERVJfU1REQwpBQ19DSEVDS19IRUFERVJTKFtzdGRsaWIuaCBzdHJpbmcu
aCBzdHJpbmdzLmggc3lzL3RpbWUuaCB1bmlzdGQuaF0pCgojIENoZWNrcyBmb3IgdHlwZWRlZnMs
IHN0cnVjdHVyZXMsIGFuZCBjb21waWxlciBjaGFyYWN0ZXJpc3RpY3MuCkFDX0NfQ09OU1QKQUNf
Q19JTkxJTkUKQUNfVFlQRV9TSVpFX1QKQUNfVFlQRV9TSUdOQUwKCiMgQ2hlY2tzIGZvciBsaWJy
YXJ5IGZ1bmN0aW9ucy4KQUNfRlVOQ19NQUxMT0MKCkFDX0NPTkZJR19GSUxFUyhbTWFrZWZpbGVd
KQoKQUNfT1VUUFVUCjwvcHJlPgogICAgICA8L2Jsb2NrcXVvdGU+CiAgICAgIDxwcmUgd3JhcD0i
Ij4KTWFrZWZpbGUuYW0KCjwvcHJlPgogICAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHls
ZT0iY29sb3I6ICMwMDAwMDA7Ij4KICAgICAgICA8cHJlIHdyYXA9IiI+QVVUT01BS0VfT1BUSU9O
UyA9IGZvcmVpZ24KCmJpbl9QUk9HUkFNUyA9IEBCVUlMRF9QUk9HUkFNU0AKRVhUUkFfUFJPR1JB
TVMgPSBqYWNrbWl4ZGVzayBqYWNrbWl4ZGVza19ndGsKCmphY2ttaXhkZXNrX1NPVVJDRVMgPSBt
aXhkZXNrLmMgZGIuaAoKamFja21peGRlc2tfQ0ZMQUdTID0gLVdhbGwgLU8yIEBKQUNLX0NGTEFH
U0AgQExBU0hfQ0ZMQUdTQCBATE9fQ0ZMQUdTQApAWE1MMl9DRkxBR1NACgpqYWNrbWl4ZGVza19M
REZMQUdTID0gLWxtIEBKQUNLX0xJQlNAIEBMQVNIX0xJQlNAIEBMT19MSUJTQCBAWE1MMl9MSUJT
QAoKamFja21peGRlc2tfZ3RrX1NPVVJDRVMgPSBjb25maWcuaCBwaGF0a25vYi5oIHBoYXRrbm9i
LmMgXApwaGF0dmZhbnNsaWRlci5jIHBoYXRoZmFuc2xpZGVyLmMgXApwaGF0a2V5Ym9hcmQuYyBw
aGF0cGFkLmggcGhhdHZrZXlib2FyZC5oIHBoYXRrZXlib2FyZC5oICBwaGF0cHJpdmF0ZS5oIFwK
cGhhdGhmYW5zbGlkZXIuaCAgcGhhdGhrZXlib2FyZC5jIHBoYXRwcml2YXRlLmMgIHBoYXRmYW5z
bGlkZXIuaFwKcGhhdGhrZXlib2FyZC5oIHBoYXRwYWQuYyBwaGF0dmZhbnNsaWRlci5oIG1peGRl
c2tfZ3RrLmMKCmphY2ttaXhkZXNrX2d0a19DRkxBR1MgPSAtV2FsbCAtTzIgQEpBQ0tfQ0ZMQUdT
QCBASUROX0NGTEFHU0AKQExPX0NGTEFHU0AgXApAR1RLX0NGTEFHU0AgQExJQkdOT01FQ0FOVkFT
X0NGTEFHU0AgQExBU0hfQ0ZMQUdTQCBAWE1MMl9DRkxBR1NACkBYMTFfQ0ZMQUdTQCAtRElOU1RB
TExfRElSPVwiJChkYXRhZGlyKVwiCgpqYWNrbWl4ZGVza19ndGtfTERGTEFHUyA9IC1sbSBASkFD
S19MSUJTQCBASUROX0xJQlNAIEBMT19MSUJTQApAR1RLX0xJQlNAIEBYMTFfTElCU0AgXApATElC
R05PTUVDQU5WQVNfTElCU0AgQExBU0hfTElCU0AgQFhNTDJfTElCU0AKCnBpeG1hcGRpciA9JChk
YXRhZGlyKS8kKFBBQ0tBR0UpL3BpeG1hcHMKcGl4bWFwX0RBVEEgPSBrbm9iLnBuZwoKbGljZW5z
ZWRpciA9JChkYXRhZGlyKTxpIGNsYXNzPSJtb3otdHh0LXNsYXNoIj48c3BhbiBjbGFzcz0ibW96
LXR4dC10YWciPi88L3NwYW4+ZG9jPHNwYW4gY2xhc3M9Im1vei10eHQtdGFnIj4vPC9zcGFuPjwv
aT4kKFBBQ0tBR0UpLSQoVkVSU0lPTikKbGljZW5zZV9EQVRBID0gQ09QWUlORwoKcmVhZG1lZGly
ID0kKGRhdGFkaXIpPGkgY2xhc3M9Im1vei10eHQtc2xhc2giPjxzcGFuIGNsYXNzPSJtb3otdHh0
LXRhZyI+Lzwvc3Bhbj5kb2M8c3BhbiBjbGFzcz0ibW96LXR4dC10YWciPi88L3NwYW4+PC9pPiQo
UEFDS0FHRSktJChWRVJTSU9OKQpyZWFkbWVfREFUQSA9IFJFQURNRQoKc3ZnZGlhZ3JhbWRpciA9
JChkYXRhZGlyKTxpIGNsYXNzPSJtb3otdHh0LXNsYXNoIj48c3BhbiBjbGFzcz0ibW96LXR4dC10
YWciPi88L3NwYW4+ZG9jPHNwYW4gY2xhc3M9Im1vei10eHQtdGFnIj4vPC9zcGFuPjwvaT4kKFBB
Q0tBR0UpLSQoVkVSU0lPTikKc3ZnZGlhZ3JhbV9EQVRBID0gamFja21peGRlc2suc3ZnCgpwbmdk
aWFncmFtZGlyID0kKGRhdGFkaXIpPGkgY2xhc3M9Im1vei10eHQtc2xhc2giPjxzcGFuIGNsYXNz
PSJtb3otdHh0LXRhZyI+Lzwvc3Bhbj5kb2M8c3BhbiBjbGFzcz0ibW96LXR4dC10YWciPi88L3Nw
YW4+PC9pPiQoUEFDS0FHRSktJChWRVJTSU9OKQpwbmdkaWFncmFtX0RBVEEgPSBqYWNrbWl4ZGVz
ay5wbmcKCnRvZG9kaXIgPSQoZGF0YWRpcik8aSBjbGFzcz0ibW96LXR4dC1zbGFzaCI+PHNwYW4g
Y2xhc3M9Im1vei10eHQtdGFnIj4vPC9zcGFuPmRvYzxzcGFuIGNsYXNzPSJtb3otdHh0LXRhZyI+
Lzwvc3Bhbj48L2k+JChQQUNLQUdFKS0kKFZFUlNJT04pCnRvZG9fREFUQSA9IFRPRE8KCkVYVFJB
X0RJU1QgPSBhdXRvZ2VuLnNoIFRPRE8gZG9jL2phY2ttaXhkZXNrLnN2Zwo8L3ByZT4KICAgICAg
PC9ibG9ja3F1b3RlPgogICAgICA8cHJlIHdyYXA9IiI+VGhhbmtzIGEgbG90CgpVbGkKCjwvcHJl
PgogICAgPC9kaXY+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==

--===============8433342540570060707==--


From robin@gareus.org Mon Apr 16 02:18:41 2012
From: Robin Gareus <robin@gareus.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: [LAD] lac repercussions
Date: Mon, 16 Apr 2012 02:18:41 +0000
Message-ID: <4F8B817A.6050805@gareus.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8542801068978897034=="

--===============8542801068978897034==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

All right!

While LAC is waning, there's a few things we should announce:

Most importantly Krzysztof Gawlas won our LAC soundtrack competition.
You'll hear his piece as soon as we get the video archive of the
conference online which will likely be next week-end. Thanks to everyone
who submitted a soundtrack.

For all who did not tune into the live-stream of the closing-ceremony:
LAC2013 will take place at IEM, Graz; in spring 2013.

If you have been at LAC and took picture or video recordings, we'd like
to hear from you - please send us a link to lac(a)linuxaudio.org

greetings from CCRMA,
robin

--===============8542801068978897034==--


From audiomobster@googlemail.com Mon Apr 16 13:07:40 2012
From: Ulrich-Lorenz =?utf-8?q?Schl=C3=BCter?= <audiomobster@googlemail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: [LAD] jackmixdesk undefined references
Date: Mon, 16 Apr 2012 13:07:40 +0000
Message-ID: <4F8C18E6.3080401@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8471500585371848062=="

--===============8471500585371848062==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hello there.

Can these files be a cause for undefined references when compiling?
I have to compile them into the binary, because phat from svn makes
problems.

configure.ac



> dnl Require autoconf version >= 2.57
> AC_PREREQ(2.57)
>
> dnl ############# Initialization
>
> AC_INIT([jackmixdesk], [0.4], [audio-mobster(a)gmx.de])
>
> AC_CONFIG_SRCDIR([mixdesk.c])
> AC_CANONICAL_SYSTEM
>
> dnl Version 1.7 of automake is recommended
> AM_INIT_AUTOMAKE([1.7])
> AM_CONFIG_HEADER([config.h])
>
>
> dnl ############# Compiler and tools Checks
>
> AC_PROG_CC
> AC_PROG_INSTALL
> AC_PROG_LN_S
> AC_C_INLINE
>
>
> dnl ############## Library Checks
>
> AC_CHECK_LIB([m], [sqrt], , [AC_MSG_ERROR(Can't find libm)])
> AC_CHECK_LIB([m], [powf])
>
> # Check for libjack (need 0.100.0 for jack_client_open)
> PKG_CHECK_MODULES(JACK, jack >= 0.100.0)
>
> # Check for liblash
> PKG_CHECK_MODULES(LASH, lash-1.0)
>
> # Check for liblo
> PKG_CHECK_MODULES(LO, liblo >= 0.23)
>
> # Check for libxml2
> PKG_CHECK_MODULES(XML2, libxml-2.0 >= 2.6.27)
>
> # Check for GTK 2.0
> PKG_CHECK_MODULES(GTK, gtk+-2.0, HAVE_GTK="Yes", HAVE_GTK="No")
>
> # Check for libX11
> PKG_CHECK_MODULES(X11, x11, HAVE_X11="Yes", HAVE_X11="No")
>
> # Check for libgnomecanvas
> PKG_CHECK_MODULES(LIBGNOMECANVAS, libgnomecanvas-2.0,
> HAVE_LIBGNOMECANVAS="Yes", HAVE_LIBGNOMECANVAS="No")
>
> # Check for libidn
> PKG_CHECK_MODULES(IDN, libidn, HAVE_IDN="Yes", HAVE_IDN="No")
>
>
> dnl ############## Decide what to build
>
> BUILD_PROGRAMS="jackmixdesk"
>
> if test "x$HAVE_GTK" == "xYes"
>    test "x$HAVE_LIBGNOMECANVAS" == "xYes"
>    test "x$HAVE_IDN" == "xYes"
>    test "x$HAVE_X11" == "xYes"
> then
>     BUILD_PROGRAMS="$BUILD_PROGRAMS jackmixdesk_gtk"
> else
>     AC_MSG_WARN([Not building GTK frontend due to missing libraries])
> fi  
>
> AC_SUBST(BUILD_PROGRAMS)
>
>
>
> dnl ############## Header Checks
>
> AC_HEADER_STDC
> AC_CHECK_HEADERS([stdlib.h string.h strings.h sys/time.h unistd.h])
>
> # Checks for typedefs, structures, and compiler characteristics.
> AC_C_CONST
> AC_C_INLINE
> AC_TYPE_SIZE_T
> AC_TYPE_SIGNAL
>
> # Checks for library functions.
> AC_FUNC_MALLOC
>
> AC_CONFIG_FILES([Makefile])
>
> AC_OUTPUT
Makefile.am



> AUTOMAKE_OPTIONS = foreign
>
> bin_PROGRAMS = @BUILD_PROGRAMS@
> EXTRA_PROGRAMS = jackmixdesk jackmixdesk_gtk
>
> jackmixdesk_SOURCES = mixdesk.c db.h
>
> jackmixdesk_CFLAGS = -Wall -O2 @JACK_CFLAGS@ @LASH_CFLAGS@ @LO_CFLAGS@
> @XML2_CFLAGS@
>
> jackmixdesk_LDFLAGS = -lm @JACK_LIBS@ @LASH_LIBS@ @LO_LIBS@ @XML2_LIBS@
>
> jackmixdesk_gtk_SOURCES = config.h phatknob.h phatknob.c \
> phatvfanslider.c phathfanslider.c \
> phatkeyboard.c phatpad.h phatvkeyboard.h phatkeyboard.h  phatprivate.h \
> phathfanslider.h  phathkeyboard.c phatprivate.c  phatfanslider.h\
> phathkeyboard.h phatpad.c phatvfanslider.h mixdesk_gtk.c
>
> jackmixdesk_gtk_CFLAGS = -Wall -O2 @JACK_CFLAGS@ @IDN_CFLAGS@
> @LO_CFLAGS@ \
> @GTK_CFLAGS@ @LIBGNOMECANVAS_CFLAGS@ @LASH_CFLAGS@ @XML2_CFLAGS@
> @X11_CFLAGS@ -DINSTALL_DIR=\"$(datadir)\"
>
> jackmixdesk_gtk_LDFLAGS = -lm @JACK_LIBS@ @IDN_LIBS@ @LO_LIBS@
> @GTK_LIBS@ @X11_LIBS@ @LIBGNOMECANVAS_LIBS@ @LASH_LIBS@ @XML2_LIBS@
>
> pixmapdir =$(datadir)/$(PACKAGE)/pixmaps
> pixmap_DATA = knob.png
>
> licensedir =$(datadir)/doc/$(PACKAGE)-$(VERSION)
> license_DATA = COPYING
>
> readmedir =$(datadir)/doc/$(PACKAGE)-$(VERSION)
> readme_DATA = README
>
> svgdiagramdir =$(datadir)/doc/$(PACKAGE)-$(VERSION)
> svgdiagram_DATA = jackmixdesk.svg
>
> pngdiagramdir =$(datadir)/doc/$(PACKAGE)-$(VERSION)
> pngdiagram_DATA = jackmixdesk.png
>
> tododir =$(datadir)/doc/$(PACKAGE)-$(VERSION)
> todo_DATA = TODO
>
> EXTRA_DIST = autogen.sh TODO doc/jackmixdesk.svg
mixdesk_gtk.c
> #include "phatfanslider.h"
> #include "phatvfanslider.h"
> #include "phathfanslider.h"
console
> /home/uli/workspace/jackmixdesk/trunk/mixdesk_gtk.c:2859: undefined
> reference to `phat_fan_slider_set_value'

Thanks a lot

Uli







--===============8471500585371848062==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PGh0bWw+CiAgPGhlYWQ+CgogICAgPG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250
ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9SVNPLTg4NTktMTUiPgogIDwvaGVhZD4KICA8Ym9keSBi
Z2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAwIj4KICAgIDxkaXYgY2xhc3M9Im1vei10ZXh0
LXBsYWluIiB3cmFwPSJ0cnVlIiBncmFwaGljYWwtcXVvdGU9InRydWUiCiAgICAgIHN0eWxlPSJm
b250LWZhbWlseTogLW1vei1maXhlZDsgZm9udC1zaXplOiAxMnB4OyIgbGFuZz0ieC13ZXN0ZXJu
Ij4KICAgICAgPHByZSB3cmFwPSIiPkhlbGxvIHRoZXJlLgoKQ2FuIHRoZXNlIGZpbGVzIGJlIGEg
Y2F1c2UgZm9yIHVuZGVmaW5lZCByZWZlcmVuY2VzIHdoZW4gY29tcGlsaW5nPwpJIGhhdmUgdG8g
Y29tcGlsZSB0aGVtIGludG8gdGhlIGJpbmFyeSwgYmVjYXVzZSBwaGF0IGZyb20gc3ZuIG1ha2Vz
CnByb2JsZW1zLgoKY29uZmlndXJlLmFjCgoKPC9wcmU+CiAgICAgIDxibG9ja3F1b3RlIHR5cGU9
ImNpdGUiIHN0eWxlPSJjb2xvcjogIzAwMDAwMDsiPgogICAgICAgIDxwcmUgd3JhcD0iIj5kbmwg
UmVxdWlyZSBhdXRvY29uZiB2ZXJzaW9uICZndDs9IDIuNTcKQUNfUFJFUkVRKDIuNTcpCgpkbmwg
IyMjIyMjIyMjIyMjIyBJbml0aWFsaXphdGlvbgoKQUNfSU5JVChbamFja21peGRlc2tdLCBbMC40
XSwgWzxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzphdWRp
by1tb2JzdGVyQGdteC5kZSI+YXVkaW8tbW9ic3RlckBnbXguZGU8L2E+XSkKCkFDX0NPTkZJR19T
UkNESVIoW21peGRlc2suY10pCkFDX0NBTk9OSUNBTF9TWVNURU0KCmRubCBWZXJzaW9uIDEuNyBv
ZiBhdXRvbWFrZSBpcyByZWNvbW1lbmRlZApBTV9JTklUX0FVVE9NQUtFKFsxLjddKQpBTV9DT05G
SUdfSEVBREVSKFtjb25maWcuaF0pCgoKZG5sICMjIyMjIyMjIyMjIyMgQ29tcGlsZXIgYW5kIHRv
b2xzIENoZWNrcwoKQUNfUFJPR19DQwpBQ19QUk9HX0lOU1RBTEwKQUNfUFJPR19MTl9TCkFDX0Nf
SU5MSU5FCgoKZG5sICMjIyMjIyMjIyMjIyMjIExpYnJhcnkgQ2hlY2tzCgpBQ19DSEVDS19MSUIo
W21dLCBbc3FydF0sICwgW0FDX01TR19FUlJPUihDYW4ndCBmaW5kIGxpYm0pXSkKQUNfQ0hFQ0tf
TElCKFttXSwgW3Bvd2ZdKQoKIyBDaGVjayBmb3IgbGliamFjayAobmVlZCAwLjEwMC4wIGZvciBq
YWNrX2NsaWVudF9vcGVuKQpQS0dfQ0hFQ0tfTU9EVUxFUyhKQUNLLCBqYWNrICZndDs9IDAuMTAw
LjApCgojIENoZWNrIGZvciBsaWJsYXNoClBLR19DSEVDS19NT0RVTEVTKExBU0gsIGxhc2gtMS4w
KQoKIyBDaGVjayBmb3IgbGlibG8KUEtHX0NIRUNLX01PRFVMRVMoTE8sIGxpYmxvICZndDs9IDAu
MjMpCgojIENoZWNrIGZvciBsaWJ4bWwyClBLR19DSEVDS19NT0RVTEVTKFhNTDIsIGxpYnhtbC0y
LjAgJmd0Oz0gMi42LjI3KQoKIyBDaGVjayBmb3IgR1RLIDIuMApQS0dfQ0hFQ0tfTU9EVUxFUyhH
VEssIGd0aystMi4wLCBIQVZFX0dUSz0iWWVzIiwgSEFWRV9HVEs9Ik5vIikKCiMgQ2hlY2sgZm9y
IGxpYlgxMQpQS0dfQ0hFQ0tfTU9EVUxFUyhYMTEsIHgxMSwgSEFWRV9YMTE9IlllcyIsIEhBVkVf
WDExPSJObyIpCgojIENoZWNrIGZvciBsaWJnbm9tZWNhbnZhcwpQS0dfQ0hFQ0tfTU9EVUxFUyhM
SUJHTk9NRUNBTlZBUywgbGliZ25vbWVjYW52YXMtMi4wLApIQVZFX0xJQkdOT01FQ0FOVkFTPSJZ
ZXMiLCBIQVZFX0xJQkdOT01FQ0FOVkFTPSJObyIpCgojIENoZWNrIGZvciBsaWJpZG4KUEtHX0NI
RUNLX01PRFVMRVMoSUROLCBsaWJpZG4sIEhBVkVfSUROPSJZZXMiLCBIQVZFX0lETj0iTm8iKQoK
CmRubCAjIyMjIyMjIyMjIyMjIyBEZWNpZGUgd2hhdCB0byBidWlsZAoKQlVJTERfUFJPR1JBTVM9
ImphY2ttaXhkZXNrIgoKaWYgdGVzdCAieCRIQVZFX0dUSyIgPT0gInhZZXMiCiAgIHRlc3QgIngk
SEFWRV9MSUJHTk9NRUNBTlZBUyIgPT0gInhZZXMiCiAgIHRlc3QgIngkSEFWRV9JRE4iID09ICJ4
WWVzIgogICB0ZXN0ICJ4JEhBVkVfWDExIiA9PSAieFllcyIKdGhlbgogICAgQlVJTERfUFJPR1JB
TVM9IiRCVUlMRF9QUk9HUkFNUyBqYWNrbWl4ZGVza19ndGsiCmVsc2UKICAgIEFDX01TR19XQVJO
KFtOb3QgYnVpbGRpbmcgR1RLIGZyb250ZW5kIGR1ZSB0byBtaXNzaW5nIGxpYnJhcmllc10pCmZp
ICAKCkFDX1NVQlNUKEJVSUxEX1BST0dSQU1TKQoKCgpkbmwgIyMjIyMjIyMjIyMjIyMgSGVhZGVy
IENoZWNrcwoKQUNfSEVBREVSX1NUREMKQUNfQ0hFQ0tfSEVBREVSUyhbc3RkbGliLmggc3RyaW5n
Lmggc3RyaW5ncy5oIHN5cy90aW1lLmggdW5pc3RkLmhdKQoKIyBDaGVja3MgZm9yIHR5cGVkZWZz
LCBzdHJ1Y3R1cmVzLCBhbmQgY29tcGlsZXIgY2hhcmFjdGVyaXN0aWNzLgpBQ19DX0NPTlNUCkFD
X0NfSU5MSU5FCkFDX1RZUEVfU0laRV9UCkFDX1RZUEVfU0lHTkFMCgojIENoZWNrcyBmb3IgbGli
cmFyeSBmdW5jdGlvbnMuCkFDX0ZVTkNfTUFMTE9DCgpBQ19DT05GSUdfRklMRVMoW01ha2VmaWxl
XSkKCkFDX09VVFBVVAo8L3ByZT4KICAgICAgPC9ibG9ja3F1b3RlPgogICAgICA8cHJlIHdyYXA9
IiI+TWFrZWZpbGUuYW0KCgo8L3ByZT4KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5
bGU9ImNvbG9yOiAjMDAwMDAwOyI+CiAgICAgICAgPHByZSB3cmFwPSIiPkFVVE9NQUtFX09QVElP
TlMgPSBmb3JlaWduCgpiaW5fUFJPR1JBTVMgPSBAQlVJTERfUFJPR1JBTVNACkVYVFJBX1BST0dS
QU1TID0gamFja21peGRlc2sgamFja21peGRlc2tfZ3RrCgpqYWNrbWl4ZGVza19TT1VSQ0VTID0g
bWl4ZGVzay5jIGRiLmgKCmphY2ttaXhkZXNrX0NGTEFHUyA9IC1XYWxsIC1PMiBASkFDS19DRkxB
R1NAIEBMQVNIX0NGTEFHU0AgQExPX0NGTEFHU0AKQFhNTDJfQ0ZMQUdTQAoKamFja21peGRlc2tf
TERGTEFHUyA9IC1sbSBASkFDS19MSUJTQCBATEFTSF9MSUJTQCBATE9fTElCU0AgQFhNTDJfTElC
U0AKCmphY2ttaXhkZXNrX2d0a19TT1VSQ0VTID0gY29uZmlnLmggcGhhdGtub2IuaCBwaGF0a25v
Yi5jIFwKcGhhdHZmYW5zbGlkZXIuYyBwaGF0aGZhbnNsaWRlci5jIFwKcGhhdGtleWJvYXJkLmMg
cGhhdHBhZC5oIHBoYXR2a2V5Ym9hcmQuaCBwaGF0a2V5Ym9hcmQuaCAgcGhhdHByaXZhdGUuaCBc
CnBoYXRoZmFuc2xpZGVyLmggIHBoYXRoa2V5Ym9hcmQuYyBwaGF0cHJpdmF0ZS5jICBwaGF0ZmFu
c2xpZGVyLmhcCnBoYXRoa2V5Ym9hcmQuaCBwaGF0cGFkLmMgcGhhdHZmYW5zbGlkZXIuaCBtaXhk
ZXNrX2d0ay5jCgpqYWNrbWl4ZGVza19ndGtfQ0ZMQUdTID0gLVdhbGwgLU8yIEBKQUNLX0NGTEFH
U0AgQElETl9DRkxBR1NACkBMT19DRkxBR1NAIFwKQEdUS19DRkxBR1NAIEBMSUJHTk9NRUNBTlZB
U19DRkxBR1NAIEBMQVNIX0NGTEFHU0AgQFhNTDJfQ0ZMQUdTQApAWDExX0NGTEFHU0AgLURJTlNU
QUxMX0RJUj1cIiQoZGF0YWRpcilcIgoKamFja21peGRlc2tfZ3RrX0xERkxBR1MgPSAtbG0gQEpB
Q0tfTElCU0AgQElETl9MSUJTQCBATE9fTElCU0AKQEdUS19MSUJTQCBAWDExX0xJQlNAIEBMSUJH
Tk9NRUNBTlZBU19MSUJTQCBATEFTSF9MSUJTQCBAWE1MMl9MSUJTQAoKcGl4bWFwZGlyID0kKGRh
dGFkaXIpLyQoUEFDS0FHRSkvcGl4bWFwcwpwaXhtYXBfREFUQSA9IGtub2IucG5nCgpsaWNlbnNl
ZGlyID0kKGRhdGFkaXIpPGkgY2xhc3M9Im1vei10eHQtc2xhc2giPjxzcGFuIGNsYXNzPSJtb3ot
dHh0LXRhZyI+Lzwvc3Bhbj5kb2M8c3BhbiBjbGFzcz0ibW96LXR4dC10YWciPi88L3NwYW4+PC9p
PiQoUEFDS0FHRSktJChWRVJTSU9OKQpsaWNlbnNlX0RBVEEgPSBDT1BZSU5HCgpyZWFkbWVkaXIg
PSQoZGF0YWRpcik8aSBjbGFzcz0ibW96LXR4dC1zbGFzaCI+PHNwYW4gY2xhc3M9Im1vei10eHQt
dGFnIj4vPC9zcGFuPmRvYzxzcGFuIGNsYXNzPSJtb3otdHh0LXRhZyI+Lzwvc3Bhbj48L2k+JChQ
QUNLQUdFKS0kKFZFUlNJT04pCnJlYWRtZV9EQVRBID0gUkVBRE1FCgpzdmdkaWFncmFtZGlyID0k
KGRhdGFkaXIpPGkgY2xhc3M9Im1vei10eHQtc2xhc2giPjxzcGFuIGNsYXNzPSJtb3otdHh0LXRh
ZyI+Lzwvc3Bhbj5kb2M8c3BhbiBjbGFzcz0ibW96LXR4dC10YWciPi88L3NwYW4+PC9pPiQoUEFD
S0FHRSktJChWRVJTSU9OKQpzdmdkaWFncmFtX0RBVEEgPSBqYWNrbWl4ZGVzay5zdmcKCnBuZ2Rp
YWdyYW1kaXIgPSQoZGF0YWRpcik8aSBjbGFzcz0ibW96LXR4dC1zbGFzaCI+PHNwYW4gY2xhc3M9
Im1vei10eHQtdGFnIj4vPC9zcGFuPmRvYzxzcGFuIGNsYXNzPSJtb3otdHh0LXRhZyI+Lzwvc3Bh
bj48L2k+JChQQUNLQUdFKS0kKFZFUlNJT04pCnBuZ2RpYWdyYW1fREFUQSA9IGphY2ttaXhkZXNr
LnBuZwoKdG9kb2RpciA9JChkYXRhZGlyKTxpIGNsYXNzPSJtb3otdHh0LXNsYXNoIj48c3BhbiBj
bGFzcz0ibW96LXR4dC10YWciPi88L3NwYW4+ZG9jPHNwYW4gY2xhc3M9Im1vei10eHQtdGFnIj4v
PC9zcGFuPjwvaT4kKFBBQ0tBR0UpLSQoVkVSU0lPTikKdG9kb19EQVRBID0gVE9ETwoKRVhUUkFf
RElTVCA9IGF1dG9nZW4uc2ggVE9ETyBkb2MvamFja21peGRlc2suc3ZnCjwvcHJlPgogICAgICA8
L2Jsb2NrcXVvdGU+CiAgICAgIG1peGRlc2tfZ3RrLmM8YnI+CiAgICAgIDxibG9ja3F1b3RlIHR5
cGU9ImNpdGUiPiNpbmNsdWRlICJwaGF0ZmFuc2xpZGVyLmgiPGJyPgogICAgICAgICNpbmNsdWRl
ICJwaGF0dmZhbnNsaWRlci5oIjxicj4KICAgICAgICAjaW5jbHVkZSAicGhhdGhmYW5zbGlkZXIu
aCI8YnI+CiAgICAgIDwvYmxvY2txdW90ZT4KICAgICAgY29uc29sZTxicj4KICAgICAgPGJsb2Nr
cXVvdGUgdHlwZT0iY2l0ZSI+L2hvbWUvdWxpL3dvcmtzcGFjZS9qYWNrbWl4ZGVzay90cnVuay9t
aXhkZXNrX2d0ay5jOjI4NTk6CiAgICAgICAgdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgcGhhdF9m
YW5fc2xpZGVyX3NldF92YWx1ZSc8L2Jsb2NrcXVvdGU+CiAgICAgIDxicj4KICAgICAgPHByZSB3
cmFwPSIiPlRoYW5rcyBhIGxvdAoKVWxpCgoKCjwvcHJlPgogICAgPC9kaXY+CiAgPC9ib2R5Pgo8
L2h0bWw+Cg==

--===============8471500585371848062==--


From jens.andreasen@comhem.se Tue Apr 17 05:11:36 2012
From: Jens M Andreasen <jens.andreasen@comhem.se>
To: linux-audio-dev@lists.linuxaudio.org
Subject: [LAD] B-Control MIDI Implementation
Date: Tue, 17 Apr 2012 05:11:36 +0000
Message-ID: <1334639436.29853.3.camel@mx44.linux.dk>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8198229037399872052=="

--===============8198229037399872052==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

An interesting PDF about the undocumented SysEx of BCR/BCF2000
- page 49 was the kicker for me

http://home.kpn.nl/f2hmjvandenberg281/download/BC/BC%20MIDI%
20Implementation.pdf 

-- 
JMA - Harlequin
http://web.comhem.se/mx44turbo/cute/harlequin.mp3


--===============8198229037399872052==--


From rncbc@rncbc.org Wed Apr 18 08:54:23 2012
From: Rui Nuno Capela <rncbc@rncbc.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: [LAD] lac2012 photos & videos
Date: Wed, 18 Apr 2012 08:54:23 +0000
Message-ID: <4F8E815F.5010206@rncbc.org>
In-Reply-To: <4F8B817A.6050805@gareus.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0558749691946063769=="

--===============0558749691946063769==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/16/2012 03:18 AM, Robin Gareus wrote:
> All right!
>
> While LAC is waning, there's a few things we should announce:
>
> Most importantly Krzysztof Gawlas won our LAC soundtrack competition.
> You'll hear his piece as soon as we get the video archive of the
> conference online which will likely be next week-end. Thanks to everyone
> who submitted a soundtrack.
>
> For all who did not tune into the live-stream of the closing-ceremony:
> LAC2013 will take place at IEM, Graz; in spring 2013.
>
> If you have been at LAC and took picture or video recordings, we'd like
> to hear from you - please send us a link to lac(a)linuxaudio.org
>

yay!

it's all over now and back home safe (i think)

there it goes:

- all my lousy unedited photos taken during the LAC2012(a)CCRMA-Stanford:
   http://www.rncbc.org/lac2012

- a couple of videos (actually 3) shot during the LSN2012(a)COHO-Stanford:
   http://www.youtube.com/user/rncbchannel

cheers
-- 
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org

--===============0558749691946063769==--


From audio-mobster@gmx.de Thu Apr 19 12:44:08 2012
From: Ulrich-Lorenz =?utf-8?q?Schl=C3=BCter?= <audio-mobster@gmx.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: [LAD] jackmixdesk undefined references
Date: Thu, 19 Apr 2012 12:44:08 +0000
Message-ID: <4F9007E0.8020305@gmx.de>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2659050861604362737=="

--===============2659050861604362737==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hello there.

Can these files be a reason for undefined references when compiling?
I have to compile them into the binary, because phat from svn makes
problems.

configure.ac

> dnl Require autoconf version >= 2.57
> AC_PREREQ(2.57)
>
> dnl ############# Initialization
>
> AC_INIT([jackmixdesk], [0.4], [audio-mobster(a)gmx.de])
>
> AC_CONFIG_SRCDIR([mixdesk.c])
> AC_CANONICAL_SYSTEM
>
> dnl Version 1.7 of automake is recommended
> AM_INIT_AUTOMAKE([1.7])
> AM_CONFIG_HEADER([config.h])
>
>
> dnl ############# Compiler and tools Checks
>
> AC_PROG_CC
> AC_PROG_INSTALL
> AC_PROG_LN_S
> AC_C_INLINE
>
>
> dnl ############## Library Checks
>
> AC_CHECK_LIB([m], [sqrt], , [AC_MSG_ERROR(Can't find libm)])
> AC_CHECK_LIB([m], [powf])
>
> # Check for libjack (need 0.100.0 for jack_client_open)
> PKG_CHECK_MODULES(JACK, jack >= 0.100.0)
>
> # Check for liblash
> PKG_CHECK_MODULES(LASH, lash-1.0)
>
> # Check for liblo
> PKG_CHECK_MODULES(LO, liblo >= 0.23)
>
> # Check for libxml2
> PKG_CHECK_MODULES(XML2, libxml-2.0 >= 2.6.27)
>
> # Check for GTK 2.0
> PKG_CHECK_MODULES(GTK, gtk+-2.0, HAVE_GTK="Yes", HAVE_GTK="No")
>
> # Check for libX11
> PKG_CHECK_MODULES(X11, x11, HAVE_X11="Yes", HAVE_X11="No")
>
> # Check for libgnomecanvas
> PKG_CHECK_MODULES(LIBGNOMECANVAS, libgnomecanvas-2.0,
> HAVE_LIBGNOMECANVAS="Yes", HAVE_LIBGNOMECANVAS="No")
>
> # Check for libidn
> PKG_CHECK_MODULES(IDN, libidn, HAVE_IDN="Yes", HAVE_IDN="No")
>
>
> dnl ############## Decide what to build
>
> BUILD_PROGRAMS="jackmixdesk"
>
> if test "x$HAVE_GTK" == "xYes"
>    test "x$HAVE_LIBGNOMECANVAS" == "xYes"
>    test "x$HAVE_IDN" == "xYes"
>    test "x$HAVE_X11" == "xYes"
> then
>     BUILD_PROGRAMS="$BUILD_PROGRAMS jackmixdesk_gtk"
> else
>     AC_MSG_WARN([Not building GTK frontend due to missing libraries])
> fi  
>
> AC_SUBST(BUILD_PROGRAMS)
>
>
>
> dnl ############## Header Checks
>
> AC_HEADER_STDC
> AC_CHECK_HEADERS([stdlib.h string.h strings.h sys/time.h unistd.h])
>
> # Checks for typedefs, structures, and compiler characteristics.
> AC_C_CONST
> AC_C_INLINE
> AC_TYPE_SIZE_T
> AC_TYPE_SIGNAL
>
> # Checks for library functions.
> AC_FUNC_MALLOC
>
> AC_CONFIG_FILES([Makefile])
>
> AC_OUTPUT
Makefile.am

> AUTOMAKE_OPTIONS = foreign
>
> bin_PROGRAMS = @BUILD_PROGRAMS@
> EXTRA_PROGRAMS = jackmixdesk jackmixdesk_gtk
>
> jackmixdesk_SOURCES = mixdesk.c db.h
>
> jackmixdesk_CFLAGS = -Wall -O2 @JACK_CFLAGS@ @LASH_CFLAGS@ @LO_CFLAGS@
> @XML2_CFLAGS@
>
> jackmixdesk_LDFLAGS = -lm @JACK_LIBS@ @LASH_LIBS@ @LO_LIBS@ @XML2_LIBS@
>
> jackmixdesk_gtk_SOURCES = config.h phatknob.h phatknob.c \
> phatvfanslider.c phathfanslider.c \
> phatkeyboard.c phatpad.h phatvkeyboard.h phatkeyboard.h  phatprivate.h \
> phathfanslider.h  phathkeyboard.c phatprivate.c  phatfanslider.h\
> phathkeyboard.h phatpad.c phatvfanslider.h mixdesk_gtk.c
>
> jackmixdesk_gtk_CFLAGS = -Wall -O2 @JACK_CFLAGS@ @IDN_CFLAGS@
> @LO_CFLAGS@ \
> @GTK_CFLAGS@ @LIBGNOMECANVAS_CFLAGS@ @LASH_CFLAGS@ @XML2_CFLAGS@
> @X11_CFLAGS@ -DINSTALL_DIR=\"$(datadir)\"
>
> jackmixdesk_gtk_LDFLAGS = -lm @JACK_LIBS@ @IDN_LIBS@ @LO_LIBS@
> @GTK_LIBS@ @X11_LIBS@ @LIBGNOMECANVAS_LIBS@ @LASH_LIBS@ @XML2_LIBS@
>
> pixmapdir =$(datadir)/$(PACKAGE)/pixmaps
> pixmap_DATA = knob.png
>
> licensedir =$(datadir)/doc/$(PACKAGE)-$(VERSION)
> license_DATA = COPYING
>
> readmedir =$(datadir)/doc/$(PACKAGE)-$(VERSION)
> readme_DATA = README
>
> svgdiagramdir =$(datadir)/doc/$(PACKAGE)-$(VERSION)
> svgdiagram_DATA = jackmixdesk.svg
>
> pngdiagramdir =$(datadir)/doc/$(PACKAGE)-$(VERSION)
> pngdiagram_DATA = jackmixdesk.png
>
> tododir =$(datadir)/doc/$(PACKAGE)-$(VERSION)
> todo_DATA = TODO
>
> EXTRA_DIST = autogen.sh TODO doc/jackmixdesk.svg
mixdesk_gtk.c

> #include "phatfanslider.h"
> #include "phatvfanslider.h"
> #include "phathfanslider.h"
console

> /home/uli/workspace/jackmixdesk/trunk/mixdesk_gtk.c:2859: undefined
> reference to `phat_fan_slider_set_value'
Thanks a lot

Uli









--===============2659050861604362737==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PGh0bWw+CiAgPGhlYWQ+CgogICAgPG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250
ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9SVNPLTg4NTktMTUiPgogIDwvaGVhZD4KICA8Ym9keSBi
Z2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAwIj4KICAgIDxkaXYgY2xhc3M9Im1vei10ZXh0
LXBsYWluIiB3cmFwPSJ0cnVlIiBncmFwaGljYWwtcXVvdGU9InRydWUiCiAgICAgIHN0eWxlPSJm
b250LWZhbWlseTogLW1vei1maXhlZDsgZm9udC1zaXplOiAxMnB4OyIgbGFuZz0ieC13ZXN0ZXJu
Ij4KICAgICAgPHByZSB3cmFwPSIiPkhlbGxvIHRoZXJlLgoKQ2FuIHRoZXNlIGZpbGVzIGJlIGEg
cmVhc29uIGZvciB1bmRlZmluZWQgcmVmZXJlbmNlcyB3aGVuIGNvbXBpbGluZz8KSSBoYXZlIHRv
IGNvbXBpbGUgdGhlbSBpbnRvIHRoZSBiaW5hcnksIGJlY2F1c2UgcGhhdCBmcm9tIHN2biBtYWtl
cwpwcm9ibGVtcy4KCmNvbmZpZ3VyZS5hYwo8L3ByZT4KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0i
Y2l0ZSIgc3R5bGU9ImNvbG9yOiAjMDAwMDAwOyI+CiAgICAgICAgPHByZSB3cmFwPSIiPmRubCBS
ZXF1aXJlIGF1dG9jb25mIHZlcnNpb24gJmd0Oz0gMi41NwpBQ19QUkVSRVEoMi41NykKCmRubCAj
IyMjIyMjIyMjIyMjIEluaXRpYWxpemF0aW9uCgpBQ19JTklUKFtqYWNrbWl4ZGVza10sIFswLjRd
LCBbPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOmF1ZGlv
LW1vYnN0ZXJAZ214LmRlIj5hdWRpby1tb2JzdGVyQGdteC5kZTwvYT5dKQoKQUNfQ09ORklHX1NS
Q0RJUihbbWl4ZGVzay5jXSkKQUNfQ0FOT05JQ0FMX1NZU1RFTQoKZG5sIFZlcnNpb24gMS43IG9m
IGF1dG9tYWtlIGlzIHJlY29tbWVuZGVkCkFNX0lOSVRfQVVUT01BS0UoWzEuN10pCkFNX0NPTkZJ
R19IRUFERVIoW2NvbmZpZy5oXSkKCgpkbmwgIyMjIyMjIyMjIyMjIyBDb21waWxlciBhbmQgdG9v
bHMgQ2hlY2tzCgpBQ19QUk9HX0NDCkFDX1BST0dfSU5TVEFMTApBQ19QUk9HX0xOX1MKQUNfQ19J
TkxJTkUKCgpkbmwgIyMjIyMjIyMjIyMjIyMgTGlicmFyeSBDaGVja3MKCkFDX0NIRUNLX0xJQihb
bV0sIFtzcXJ0XSwgLCBbQUNfTVNHX0VSUk9SKENhbid0IGZpbmQgbGlibSldKQpBQ19DSEVDS19M
SUIoW21dLCBbcG93Zl0pCgojIENoZWNrIGZvciBsaWJqYWNrIChuZWVkIDAuMTAwLjAgZm9yIGph
Y2tfY2xpZW50X29wZW4pClBLR19DSEVDS19NT0RVTEVTKEpBQ0ssIGphY2sgJmd0Oz0gMC4xMDAu
MCkKCiMgQ2hlY2sgZm9yIGxpYmxhc2gKUEtHX0NIRUNLX01PRFVMRVMoTEFTSCwgbGFzaC0xLjAp
CgojIENoZWNrIGZvciBsaWJsbwpQS0dfQ0hFQ0tfTU9EVUxFUyhMTywgbGlibG8gJmd0Oz0gMC4y
MykKCiMgQ2hlY2sgZm9yIGxpYnhtbDIKUEtHX0NIRUNLX01PRFVMRVMoWE1MMiwgbGlieG1sLTIu
MCAmZ3Q7PSAyLjYuMjcpCgojIENoZWNrIGZvciBHVEsgMi4wClBLR19DSEVDS19NT0RVTEVTKEdU
SywgZ3RrKy0yLjAsIEhBVkVfR1RLPSJZZXMiLCBIQVZFX0dUSz0iTm8iKQoKIyBDaGVjayBmb3Ig
bGliWDExClBLR19DSEVDS19NT0RVTEVTKFgxMSwgeDExLCBIQVZFX1gxMT0iWWVzIiwgSEFWRV9Y
MTE9Ik5vIikKCiMgQ2hlY2sgZm9yIGxpYmdub21lY2FudmFzClBLR19DSEVDS19NT0RVTEVTKExJ
QkdOT01FQ0FOVkFTLCBsaWJnbm9tZWNhbnZhcy0yLjAsCkhBVkVfTElCR05PTUVDQU5WQVM9Illl
cyIsIEhBVkVfTElCR05PTUVDQU5WQVM9Ik5vIikKCiMgQ2hlY2sgZm9yIGxpYmlkbgpQS0dfQ0hF
Q0tfTU9EVUxFUyhJRE4sIGxpYmlkbiwgSEFWRV9JRE49IlllcyIsIEhBVkVfSUROPSJObyIpCgoK
ZG5sICMjIyMjIyMjIyMjIyMjIERlY2lkZSB3aGF0IHRvIGJ1aWxkCgpCVUlMRF9QUk9HUkFNUz0i
amFja21peGRlc2siCgppZiB0ZXN0ICJ4JEhBVkVfR1RLIiA9PSAieFllcyIKICAgdGVzdCAieCRI
QVZFX0xJQkdOT01FQ0FOVkFTIiA9PSAieFllcyIKICAgdGVzdCAieCRIQVZFX0lETiIgPT0gInhZ
ZXMiCiAgIHRlc3QgIngkSEFWRV9YMTEiID09ICJ4WWVzIgp0aGVuCiAgICBCVUlMRF9QUk9HUkFN
Uz0iJEJVSUxEX1BST0dSQU1TIGphY2ttaXhkZXNrX2d0ayIKZWxzZQogICAgQUNfTVNHX1dBUk4o
W05vdCBidWlsZGluZyBHVEsgZnJvbnRlbmQgZHVlIHRvIG1pc3NpbmcgbGlicmFyaWVzXSkKZmkg
IAoKQUNfU1VCU1QoQlVJTERfUFJPR1JBTVMpCgoKCmRubCAjIyMjIyMjIyMjIyMjIyBIZWFkZXIg
Q2hlY2tzCgpBQ19IRUFERVJfU1REQwpBQ19DSEVDS19IRUFERVJTKFtzdGRsaWIuaCBzdHJpbmcu
aCBzdHJpbmdzLmggc3lzL3RpbWUuaCB1bmlzdGQuaF0pCgojIENoZWNrcyBmb3IgdHlwZWRlZnMs
IHN0cnVjdHVyZXMsIGFuZCBjb21waWxlciBjaGFyYWN0ZXJpc3RpY3MuCkFDX0NfQ09OU1QKQUNf
Q19JTkxJTkUKQUNfVFlQRV9TSVpFX1QKQUNfVFlQRV9TSUdOQUwKCiMgQ2hlY2tzIGZvciBsaWJy
YXJ5IGZ1bmN0aW9ucy4KQUNfRlVOQ19NQUxMT0MKCkFDX0NPTkZJR19GSUxFUyhbTWFrZWZpbGVd
KQoKQUNfT1VUUFVUCjwvcHJlPgogICAgICA8L2Jsb2NrcXVvdGU+CiAgICAgIDxwcmUgd3JhcD0i
Ij5NYWtlZmlsZS5hbQo8L3ByZT4KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9
ImNvbG9yOiAjMDAwMDAwOyI+CiAgICAgICAgPHByZSB3cmFwPSIiPkFVVE9NQUtFX09QVElPTlMg
PSBmb3JlaWduCgpiaW5fUFJPR1JBTVMgPSBAQlVJTERfUFJPR1JBTVNACkVYVFJBX1BST0dSQU1T
ID0gamFja21peGRlc2sgamFja21peGRlc2tfZ3RrCgpqYWNrbWl4ZGVza19TT1VSQ0VTID0gbWl4
ZGVzay5jIGRiLmgKCmphY2ttaXhkZXNrX0NGTEFHUyA9IC1XYWxsIC1PMiBASkFDS19DRkxBR1NA
IEBMQVNIX0NGTEFHU0AgQExPX0NGTEFHU0AKQFhNTDJfQ0ZMQUdTQAoKamFja21peGRlc2tfTERG
TEFHUyA9IC1sbSBASkFDS19MSUJTQCBATEFTSF9MSUJTQCBATE9fTElCU0AgQFhNTDJfTElCU0AK
CmphY2ttaXhkZXNrX2d0a19TT1VSQ0VTID0gY29uZmlnLmggcGhhdGtub2IuaCBwaGF0a25vYi5j
IFwKcGhhdHZmYW5zbGlkZXIuYyBwaGF0aGZhbnNsaWRlci5jIFwKcGhhdGtleWJvYXJkLmMgcGhh
dHBhZC5oIHBoYXR2a2V5Ym9hcmQuaCBwaGF0a2V5Ym9hcmQuaCAgcGhhdHByaXZhdGUuaCBcCnBo
YXRoZmFuc2xpZGVyLmggIHBoYXRoa2V5Ym9hcmQuYyBwaGF0cHJpdmF0ZS5jICBwaGF0ZmFuc2xp
ZGVyLmhcCnBoYXRoa2V5Ym9hcmQuaCBwaGF0cGFkLmMgcGhhdHZmYW5zbGlkZXIuaCBtaXhkZXNr
X2d0ay5jCgpqYWNrbWl4ZGVza19ndGtfQ0ZMQUdTID0gLVdhbGwgLU8yIEBKQUNLX0NGTEFHU0Ag
QElETl9DRkxBR1NACkBMT19DRkxBR1NAIFwKQEdUS19DRkxBR1NAIEBMSUJHTk9NRUNBTlZBU19D
RkxBR1NAIEBMQVNIX0NGTEFHU0AgQFhNTDJfQ0ZMQUdTQApAWDExX0NGTEFHU0AgLURJTlNUQUxM
X0RJUj1cIiQoZGF0YWRpcilcIgoKamFja21peGRlc2tfZ3RrX0xERkxBR1MgPSAtbG0gQEpBQ0tf
TElCU0AgQElETl9MSUJTQCBATE9fTElCU0AKQEdUS19MSUJTQCBAWDExX0xJQlNAIEBMSUJHTk9N
RUNBTlZBU19MSUJTQCBATEFTSF9MSUJTQCBAWE1MMl9MSUJTQAoKcGl4bWFwZGlyID0kKGRhdGFk
aXIpLyQoUEFDS0FHRSkvcGl4bWFwcwpwaXhtYXBfREFUQSA9IGtub2IucG5nCgpsaWNlbnNlZGly
ID0kKGRhdGFkaXIpPGkgY2xhc3M9Im1vei10eHQtc2xhc2giPjxzcGFuIGNsYXNzPSJtb3otdHh0
LXRhZyI+Lzwvc3Bhbj5kb2M8c3BhbiBjbGFzcz0ibW96LXR4dC10YWciPi88L3NwYW4+PC9pPiQo
UEFDS0FHRSktJChWRVJTSU9OKQpsaWNlbnNlX0RBVEEgPSBDT1BZSU5HCgpyZWFkbWVkaXIgPSQo
ZGF0YWRpcik8aSBjbGFzcz0ibW96LXR4dC1zbGFzaCI+PHNwYW4gY2xhc3M9Im1vei10eHQtdGFn
Ij4vPC9zcGFuPmRvYzxzcGFuIGNsYXNzPSJtb3otdHh0LXRhZyI+Lzwvc3Bhbj48L2k+JChQQUNL
QUdFKS0kKFZFUlNJT04pCnJlYWRtZV9EQVRBID0gUkVBRE1FCgpzdmdkaWFncmFtZGlyID0kKGRh
dGFkaXIpPGkgY2xhc3M9Im1vei10eHQtc2xhc2giPjxzcGFuIGNsYXNzPSJtb3otdHh0LXRhZyI+
Lzwvc3Bhbj5kb2M8c3BhbiBjbGFzcz0ibW96LXR4dC10YWciPi88L3NwYW4+PC9pPiQoUEFDS0FH
RSktJChWRVJTSU9OKQpzdmdkaWFncmFtX0RBVEEgPSBqYWNrbWl4ZGVzay5zdmcKCnBuZ2RpYWdy
YW1kaXIgPSQoZGF0YWRpcik8aSBjbGFzcz0ibW96LXR4dC1zbGFzaCI+PHNwYW4gY2xhc3M9Im1v
ei10eHQtdGFnIj4vPC9zcGFuPmRvYzxzcGFuIGNsYXNzPSJtb3otdHh0LXRhZyI+Lzwvc3Bhbj48
L2k+JChQQUNLQUdFKS0kKFZFUlNJT04pCnBuZ2RpYWdyYW1fREFUQSA9IGphY2ttaXhkZXNrLnBu
ZwoKdG9kb2RpciA9JChkYXRhZGlyKTxpIGNsYXNzPSJtb3otdHh0LXNsYXNoIj48c3BhbiBjbGFz
cz0ibW96LXR4dC10YWciPi88L3NwYW4+ZG9jPHNwYW4gY2xhc3M9Im1vei10eHQtdGFnIj4vPC9z
cGFuPjwvaT4kKFBBQ0tBR0UpLSQoVkVSU0lPTikKdG9kb19EQVRBID0gVE9ETwoKRVhUUkFfRElT
VCA9IGF1dG9nZW4uc2ggVE9ETyBkb2MvamFja21peGRlc2suc3ZnCjwvcHJlPgogICAgICA8L2Js
b2NrcXVvdGU+CiAgICAgIDxwcmUgd3JhcD0iIj5taXhkZXNrX2d0ay5jCjwvcHJlPgogICAgICA8
YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iY29sb3I6ICMwMDAwMDA7Ij4KICAgICAgICA8
cHJlIHdyYXA9IiI+I2luY2x1ZGUgInBoYXRmYW5zbGlkZXIuaCIKI2luY2x1ZGUgInBoYXR2ZmFu
c2xpZGVyLmgiCiNpbmNsdWRlICJwaGF0aGZhbnNsaWRlci5oIgo8L3ByZT4KICAgICAgPC9ibG9j
a3F1b3RlPgogICAgICA8cHJlIHdyYXA9IiI+Y29uc29sZQo8L3ByZT4KICAgICAgPGJsb2NrcXVv
dGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImNvbG9yOiAjMDAwMDAwOyI+CiAgICAgICAgPHByZSB3cmFw
PSIiPi9ob21lL3VsaS93b3Jrc3BhY2UvamFja21peGRlc2svdHJ1bmsvbWl4ZGVza19ndGsuYzoy
ODU5OiB1bmRlZmluZWQKcmVmZXJlbmNlIHRvIGBwaGF0X2Zhbl9zbGlkZXJfc2V0X3ZhbHVlJwo8
L3ByZT4KICAgICAgPC9ibG9ja3F1b3RlPgogICAgICA8cHJlIHdyYXA9IiI+VGhhbmtzIGEgbG90
CgpVbGkKCgoKCgo8L3ByZT4KICAgIDwvZGl2PgogIDwvYm9keT4KPC9odG1sPgo=

--===============2659050861604362737==--


From xbran@web.de Thu Apr 19 16:05:46 2012
From: Emanuel Rumpf <xbran@web.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] jackmixdesk undefined references
Date: Thu, 19 Apr 2012 16:05:46 +0000
Message-ID:
 <CAGQuJFJ8MeJGnv-KqGh4HS=36iRPAoX+54hJ8sp5sU7apypU6g@mail.gmail.com>
In-Reply-To: <4F9007E0.8020305@gmx.de>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6029221040790505938=="

--===============6029221040790505938==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Am 19. April 2012 14:41 schrieb Ulrich-Lorenz Schl=C3=BCter <audio-mobster(a)=
gmx.de>:
>
> /home/uli/workspace/jackmixdesk/trunk/mixdesk_gtk.c:2859: undefined
> reference to `phat_fan_slider_set_value'
>

install libphat-dev package (if ubuntu)

post output of

ls /usr/lib/libph*
ls /usr/lib/x86_64-linux-gnu/libph*

cat /etc/ld.so.conf
cat /etc/ld.so.conf.d/*

--=20
E.R.

--===============6029221040790505938==--


From audio-mobster@gmx.de Thu Apr 19 17:13:07 2012
From: Ulrich-Lorenz =?utf-8?q?Schl=C3=BCter?= <audio-mobster@gmx.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] jackmixdesk undefined references
Date: Thu, 19 Apr 2012 17:13:07 +0000
Message-ID: <4F9046E0.1060000@gmx.de>
In-Reply-To: <4F904527.9020208@gmx.de>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1387322008330449657=="

--===============1387322008330449657==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Am 19.04.2012 18:05, schrieb Emanuel Rumpf:
> Am 19. April 2012 14:41 schrieb Ulrich-Lorenz Schl=C3=BCter <audio-mobster(=
a)gmx.de>:
>> /home/uli/workspace/jackmixdesk/trunk/mixdesk_gtk.c:2859: undefined
>> reference to `phat_fan_slider_set_value'
>>
> install libphat-dev package (if ubuntu)
>
> post output of
>
> ls /usr/lib/libph*
> ls /usr/lib/x86_64-linux-gnu/libph*
>
> cat /etc/ld.so.conf
> cat /etc/ld.so.conf.d/*
>
I need a resizeable phat knob for my project, jackmixdesk. I want to
make my this project available for all users without fumbling, so I
don't want a dependency on the development package of phat. Phat dev is
even uninstallable for gentoo right now.

With best regards

Uli


--===============1387322008330449657==--


From nick@afternight.org Thu Apr 19 17:30:09 2012
From: Nick Lanham <nick@afternight.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] jackmixdesk undefined references
Date: Thu, 19 Apr 2012 17:30:09 +0000
Message-ID: <4F904B5C.1060703@afternight.org>
In-Reply-To: <4F9046E0.1060000@gmx.de>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4029238580026603316=="

--===============4029238580026603316==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

If you want a separated knob based on phatknob check out nknob from drmr:

https://github.com/nicklan/drmr/blob/master/nknob.c
https://github.com/nicklan/drmr/blob/master/nknob.h

Not re-sizable, but might be a better starting point for you.

Regards,
-Nick




On 04/19/2012 07:09 PM, Ulrich-Lorenz Schl=C3=BCter wrote:
> Am 19.04.2012 18:05, schrieb Emanuel Rumpf:
>> Am 19. April 2012 14:41 schrieb Ulrich-Lorenz Schl=C3=BCter<audio-mobster(=
a)gmx.de>:
>>> /home/uli/workspace/jackmixdesk/trunk/mixdesk_gtk.c:2859: undefined
>>> reference to `phat_fan_slider_set_value'
>>>
>> install libphat-dev package (if ubuntu)
>>
>> post output of
>>
>> ls /usr/lib/libph*
>> ls /usr/lib/x86_64-linux-gnu/libph*
>>
>> cat /etc/ld.so.conf
>> cat /etc/ld.so.conf.d/*
>>
> I need a resizeable phat knob for my project, jackmixdesk. I want to
> make my this project available for all users without fumbling, so I
> don't want a dependency on the development package of phat. Phat dev is
> even uninstallable for gentoo right now.
>
> With best regards
>
> Uli
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev

--===============4029238580026603316==--


From adi@drcomp.erfurt.thur.de Thu Apr 19 17:32:15 2012
From: Adrian Knoth <adi@drcomp.erfurt.thur.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] jackmixdesk undefined references
Date: Thu, 19 Apr 2012 17:32:15 +0000
Message-ID: <20120419173211.GW6396@ltw.loris.tv>
In-Reply-To: <4F9046E0.1060000@gmx.de>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1226368280928964913=="

--===============1226368280928964913==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Thu, Apr 19, 2012 at 07:09:52PM +0200, Ulrich-Lorenz Schlüter wrote:

> > install libphat-dev package (if ubuntu)
> >
> > post output of
> >
> > ls /usr/lib/libph*
> > ls /usr/lib/x86_64-linux-gnu/libph*
> >
> > cat /etc/ld.so.conf
> > cat /etc/ld.so.conf.d/*
> >
> I need a resizeable phat knob for my project, jackmixdesk.

Glad you mention this. Right after posting the same mail three times in
a row. ;)

> I want to make my this project available for all users without
> fumbling, so I don't want a dependency on the development package of
> phat.

Speaking with my Debian hat on, I suggest you simply specify any
external requirements in the README and trust the distribution to get it
right.

The other approach is to use an embedded copy of phat, but we (Debian)
usually don't like this approach and would probably strip it anyway.

There are pros and cons to embedded copies:

   + known to work
   + easy installation, since self-contained

   - increased memory footprint
   - additional maintenance overhead (e.g., security fixes)



> Phat dev is even uninstallable for gentoo right now.

Tell them, and they'll fix it. If nobody knows about this, it would
remain broken forever.



Just my €0.02

-- 
mail: adi(a)thur.de  	http://adi.thur.de	PGP/GPG: key via keyserver


--===============1226368280928964913==--


From audio-mobster@gmx.de Thu Apr 19 18:05:04 2012
From: Ulrich-Lorenz =?utf-8?q?Schl=C3=BCter?= <audio-mobster@gmx.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] jackmixdesk undefined references
Date: Thu, 19 Apr 2012 18:05:04 +0000
Message-ID: <4F905307.8050704@gmx.de>
In-Reply-To: <20120419173211.GW6396@ltw.loris.tv>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0482773164431893252=="

--===============0482773164431893252==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Am 19.04.2012 19:32, schrieb Adrian Knoth:
> On Thu, Apr 19, 2012 at 07:09:52PM +0200, Ulrich-Lorenz Schlüter wrote:
>
>>> install libphat-dev package (if ubuntu)
>>>
>>> post output of
>>>
>>> ls /usr/lib/libph*
>>> ls /usr/lib/x86_64-linux-gnu/libph*
>>>
>>> cat /etc/ld.so.conf
>>> cat /etc/ld.so.conf.d/*
>>>
>> I need a resizeable phat knob for my project, jackmixdesk.
> Glad you mention this. Right after posting the same mail three times in
> a row. ;)
>
>> I want to make my this project available for all users without
>> fumbling, so I don't want a dependency on the development package of
>> phat.
> Speaking with my Debian hat on, I suggest you simply specify any
> external requirements in the README and trust the distribution to get it
> right.
>
> The other approach is to use an embedded copy of phat, but we (Debian)
> usually don't like this approach and would probably strip it anyway.
>
> There are pros and cons to embedded copies:
>
>    + known to work
>    + easy installation, since self-contained
>
>    - increased memory footprint
>    - additional maintenance overhead (e.g., security fixes)
>
>
>
>> Phat dev is even uninstallable for gentoo right now.
> Tell them, and they'll fix it. If nobody knows about this, it would
> remain broken forever.
>
>
>
> Just my €0.02
>
Really sorry for that triple post. I did not receive my first two mails
back from the list, only a "message rejected" and really really had some
impatience.

I reported the phat problem at Gentoo bugzilla because it's an ebuild
bug afaik, it was closed as invalid and I was told, this is not a
support forum. From the pro-audio list there is no response. Okay wrong
order, list first then bugzilla!

Shouldn't be such a problem to see if there is something wrong with my
build system for someone who's more common with autogen than me.

Sincerely

Uli


--===============0482773164431893252==--


From audio-mobster@gmx.de Thu Apr 19 18:28:32 2012
From: Ulrich-Lorenz =?utf-8?q?Schl=C3=BCter?= <audio-mobster@gmx.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] jackmixdesk undefined references
Date: Thu, 19 Apr 2012 18:28:32 +0000
Message-ID: <4F905880.3010407@gmx.de>
In-Reply-To: <4F904B5C.1060703@afternight.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0057632605771046329=="

--===============0057632605771046329==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Sorry I need this resizeable knob as I already used it before. The
layout of the mixer client gets unusable without that resize stuff.

Thanks
Uli

Am 19.04.2012 19:29, schrieb Nick Lanham:
> If you want a separated knob based on phatknob check out nknob from drmr:
>
> https://github.com/nicklan/drmr/blob/master/nknob.c
> https://github.com/nicklan/drmr/blob/master/nknob.h
>
> Not re-sizable, but might be a better starting point for you.
>
> Regards,
> -Nick
>
>
>
>
> On 04/19/2012 07:09 PM, Ulrich-Lorenz Schlüter wrote:
>> Am 19.04.2012 18:05, schrieb Emanuel Rumpf:
>>> Am 19. April 2012 14:41 schrieb Ulrich-Lorenz
>>> Schlüter<audio-mobster(a)gmx.de>:
>>>> /home/uli/workspace/jackmixdesk/trunk/mixdesk_gtk.c:2859: undefined
>>>> reference to `phat_fan_slider_set_value'
>>>>
>>> install libphat-dev package (if ubuntu)
>>>
>>> post output of
>>>
>>> ls /usr/lib/libph*
>>> ls /usr/lib/x86_64-linux-gnu/libph*
>>>
>>> cat /etc/ld.so.conf
>>> cat /etc/ld.so.conf.d/*
>>>
>> I need a resizeable phat knob for my project, jackmixdesk. I want to
>> make my this project available for all users without fumbling, so I
>> don't want a dependency on the development package of phat. Phat dev is
>> even uninstallable for gentoo right now.
>>
>> With best regards
>>
>> Uli
>>
>> _______________________________________________
>> Linux-audio-dev mailing list
>> Linux-audio-dev(a)lists.linuxaudio.org
>> http://lists.linuxaudio.org/listinfo/linux-audio-dev
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev


--===============0057632605771046329==--


From nettings@stackingdwarves.net Tue Apr 24 20:36:18 2012
From: =?utf-8?q?J=C3=B6rn?= Nettingsmeier <nettings@stackingdwarves.net>
To: linux-audio-dev@lists.linuxaudio.org
Subject: [LAD] Linux Audio Conference 2012 at CCRMA - proceedings and videos
 now available
Date: Tue, 24 Apr 2012 20:36:18 +0000
Message-ID: <4F970EBB.8090305@stackingdwarves.net>
In-Reply-To: <4F85C59C.60203@stackingdwarves.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4851293019051571543=="

--===============4851293019051571543==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On 04/11/2012 07:55 PM, Jörn Nettingsmeier wrote:
> Hi *!
>
>
> On behalf of the conference organizers, we would like to invite you to
> join the Linux Audio Conference 2012, kindly hosted by the Center for
> Computer Research in Music and Acoustics (CCRMA) at Stanford University.
>
> The conference will start tomorrow, Thursday April 12, at 10:00 PST
> (that's UTC - 0700). Please refer to the schedule at
>
> http://lac.linuxaudio.org/2012/program
>
> for detailed information.

thanks to robin gareus, who not only designed and implemented the most 
kick-ass video workflow we ever had and integrated it with the sweetest 
conference database system we ever had, but also ran his machines day 
and nite to re-encode our video dumps, you can now surf to

   http://lac.linuxaudio.org/2012/program

and enjoy the results of a very intense four days at ccrma: slides, 
papers, and videos of all talks and workshops.

best,


jörn



-- 
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487

Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT

http://stackingdwarves.net


--===============4851293019051571543==--


From robin@gareus.org Tue Apr 24 20:47:37 2012
From: Robin Gareus <robin@gareus.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] [LAU] Linux Audio Conference 2012 at CCRMA - proceedings
 and videos now available
Date: Tue, 24 Apr 2012 20:47:37 +0000
Message-ID: <4F97115F.1090605@gareus.org>
In-Reply-To: <4F970EBB.8090305@stackingdwarves.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2163923904960712225=="

--===============2163923904960712225==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On 04/24/2012 10:36 PM, Jörn Nettingsmeier wrote:
> On 04/11/2012 07:55 PM, Jörn Nettingsmeier wrote:
>> Hi *!
>>
>>
>> On behalf of the conference organizers, we would like to invite you to
>> join the Linux Audio Conference 2012, kindly hosted by the Center for
>> Computer Research in Music and Acoustics (CCRMA) at Stanford University.
>>
>> The conference will start tomorrow, Thursday April 12, at 10:00 PST
>> (that's UTC - 0700). Please refer to the schedule at
>>
>> http://lac.linuxaudio.org/2012/program
>>
>> for detailed information.
> 
> thanks to robin gareus, who not only designed and implemented the most
> kick-ass video workflow we ever had and integrated it with the sweetest
> conference database system we ever had, but also ran his machines day
> and nite 

Actually, those neat fan-less CCRMA boxes did most of the grunt work.
But i'll just call them mine now, thanks :)

> to re-encode our video dumps, you can now surf to
> 
>   http://lac.linuxaudio.org/2012/program
> 
> and enjoy the results of a very intense four days at ccrma: slides,
> papers, and videos of all talks and workshops.

NO no no. Please hold your horses. We're not quite there, yet!

Please check the site. http://lac.linuxaudio.org/2012/ says:
"The Linux Audio Conference 2012 is over but we're not quite done, yet."

and http://lac.linuxaudio.org/2012/files reads
"We are still busy to edit/upload recordings of each talk. Please stay
tuned."

We'll remove those messages when we're done and properly announce the
site. That being said, most of the videos are indeed already available.
We opted for high quality and high bandwidth this year, so some of you
may want to download the videos rather than watch online.

ciao,
robin

--===============2163923904960712225==--


From arnold@arnoldarts.de Tue Apr 24 22:04:56 2012
From: Arnold Krille <arnold@arnoldarts.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] [LAU] Linux Audio Conference 2012 at CCRMA - proceedings
	and videos now available
Date: Tue, 24 Apr 2012 22:04:56 +0000
Message-ID: <1389115.zAIVlOgqBg@yukon>
In-Reply-To: <4F97115F.1090605@gareus.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0442297761424572171=="

--===============0442297761424572171==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Tuesday 24 April 2012 22:47:27 Robin Gareus wrote:
> We'll remove those messages when we're done and properly announce the
> site. That being said, most of the videos are indeed already available.
> We opted for high quality and high bandwidth this year, so some of you
> may want to download the videos rather than watch online.

Can/will you also provide torrent-seeds for individual files and/or the whole=
=20
bundle?
Its easier for me to just let my servers torrent do the work than individuall=
y=20
clicking the files... And of course its a sign of sharing:-)

Thanks,

Arnold

--===============0442297761424572171==
Content-Type: application/pgp-signature
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="signature.asc"
MIME-Version: 1.0

LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xMSAoR05V
L0xpbnV4KQoKaUVZRUFCRUNBQVlGQWsrWEkzc0FDZ2tRdVlMTDFjRGpIeDB1VVFDZEdwcXVWYkEr
dm5WTHQ3UjRhYmRhak85bwo3MUVBbjF5YTBhVVlBQ1V4NU1DZktCRDVTL3c1U3JmTgo9aXB4Uwot
LS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0K

--===============0442297761424572171==--


From robin@gareus.org Tue Apr 24 22:55:46 2012
From: Robin Gareus <robin@gareus.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] [LAU] Linux Audio Conference 2012 at CCRMA - proceedings
 and videos now available
Date: Tue, 24 Apr 2012 22:55:46 +0000
Message-ID: <4F972F6C.7090109@gareus.org>
In-Reply-To: <1389115.zAIVlOgqBg@yukon>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6368456605633935381=="

--===============6368456605633935381==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On 04/25/2012 12:04 AM, Arnold Krille wrote:
> On Tuesday 24 April 2012 22:47:27 Robin Gareus wrote:
>> We'll remove those messages when we're done and properly announce the
>> site. That being said, most of the videos are indeed already available.
>> We opted for high quality and high bandwidth this year, so some of you
>> may want to download the videos rather than watch online.
>=20
> Can/will you also provide torrent-seeds for individual files and/or the who=
le=20
> bundle?
> Its easier for me to just let my servers torrent do the work than individua=
lly=20
> clicking the files... And of course its a sign of sharing:-)
>
> Thanks,
>=20
> Arnold
>=20

Yes, we will do that, but before we can create the torrent we'll need to
have _all_ recordings. Two videos are still missing. We won't do
individual torrents. Most torrent software does allow to limit the
download to file subsets.

Instead of clicking individual files, LADs can also get the files via
rsync://linuxaudio.org:/lac2012/

Cheers!
robin

--===============6368456605633935381==--


From dlphillips@woh.rr.com Tue Apr 24 23:59:34 2012
From: Dave Phillips <dlphillips@woh.rr.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] [LAU] Linux Audio Conference 2012 at CCRMA - proceedings
 and videos now available
Date: Tue, 24 Apr 2012 23:59:34 +0000
Message-ID: <4F973E65.6090900@woh.rr.com>
In-Reply-To: <4F972F6C.7090109@gareus.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8896356512848108233=="

--===============8896356512848108233==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/24/2012 06:55 PM, Robin Gareus wrote:
>
> Yes, we will do that, but before we can create the torrent we'll need to
> have _all_ recordings. Two videos are still missing...

One of which is my workshop. My apologies, I won't get to edit it until 
tomorrow. It should be back in Robin's hands by tomorrow evening.

Best,

dp


--===============8896356512848108233==--


From Thierry.Coduys@le-hub.org Wed Apr 25 08:02:45 2012
From: Thierry Coduys <Thierry.Coduys@le-hub.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: [LAD] LoMus 2012
Date: Wed, 25 Apr 2012 08:02:45 +0000
Message-ID: <577336B5-2117-4A49-91DD-55F8B2CDDBE5@le-hub.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1295328489101543702=="

--===============1295328489101543702==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

D=C3=A9sol=C3=A9 en cas d=E2=80=99envois multiples / sorry for possible cross=
posting

The dead line for software submission was extended to the April 29th
_______________

LoMus 2012

=C3=80 la recherche des logiciels libres pour la cr=C3=A9ation sonore et inte=
rmedia

Pour sa quatri=C3=A8me =C3=A9dition, LoMus 2012 s=E2=80=99adresse =C3=A0 tous=
 ceux qui s=E2=80=99aventurent dans le d=C3=A9veloppement de logiciels libres=
 musicaux ou de logiciels libres qui peuvent contribuer au processus de la cr=
=C3=A9ation musicale.

Un prix sera remis aux logiciels qui font preuve non seulement d=E2=80=99inno=
vation, mais notamment d=E2=80=99inventivit=C3=A9 face aux enjeux actuels de =
la cr=C3=A9ation musicale.

Calendrier
6 avril 2012 - Appel =C3=A0 soumissions
29 avril 2012 - Date limite de soumission des logiciels
5 mai 2012 - Notification d'acceptation
11 mai 2012 - Remise du prix lors des JIM 2012

Info : http://concours.afim-asso.org/
JIM2012 : http://www.jim2012.be


LoMus 2012

In search of open-source software for musical and intermedia creation

For its fourth edition, LoMus 2012 invites music and audio open-source softwa=
re creators to submit original projects that either directly or indirectly co=
ntribute to musical creation.

A prize will be awarded to open-source sofware that proves to be not only inn=
ovatory but also inventive in the present context of music and audio creation.

Calendar
April 6, 2012 - Call for submissions=20
April 29, 2012 - Submission deadline=20
May 5, 2012 - Admission notification=20
May 11, 2012 - JIM Awards Ceremony

Info: http://concours.afim-asso.org/
JIM2012 : http://www.jim2012.be
http://www.le-hub.org/




--===============1295328489101543702==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PGh0bWw+PGJvZHkgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1v
ZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPjxzcGFu
IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyAiPkTpc29s
6SBlbiBjYXMgZJJlbnZvaXMgbXVsdGlwbGVzIC8gc29ycnkgZm9yIHBvc3NpYmxlIGNyb3NzcG9z
dGluZzwvc3Bhbj48ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7ICI+PGJyPjwvZGl2PjxkaXYg
c3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgIj48Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIg
c2l6ZT0iNSI+PGI+VGhlIGRlYWQgbGluZSBmb3Igc29mdHdhcmUgc3VibWlzc2lvbiB3YXMgZXh0
ZW5kZWQgdG8gdGhlIEFwcmlsIDI5dGg8L2I+PC9mb250PjxkaXY+X19fX19fX19fX19fX19fPC9k
aXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyAiPkxvTXVz
IDIwMTI8L2I+PGJyPjxkaXY+PGRpdj48ZGl2Pjxicj48YiBzdHlsZT0iZm9udC1zaXplOiAxNHB4
OyAiPsAgbGEgcmVjaGVyY2hlIGRlcyBsb2dpY2llbHMgbGlicmVzIHBvdXIgbGEgY3LpYXRpb24g
c29ub3JlIGV0IGludGVybWVkaWE8L2I+PGJyIHN0eWxlPSJmb250LXNpemU6IDEzcHg7ICI+PGJy
PlBvdXIgc2EgcXVhdHJp6G1lIOlkaXRpb24sIExvTXVzIDIwMTIgc5JhZHJlc3NlIOAgdG91cyBj
ZXV4IHF1aSBzkmF2ZW50dXJlbnQgZGFucyBsZSBk6XZlbG9wcGVtZW50IGRlIGxvZ2ljaWVscyBs
aWJyZXMgbXVzaWNhdXggb3UgZGUgbG9naWNpZWxzIGxpYnJlcyBxdWkmbmJzcDtwZXV2ZW50IGNv
bnRyaWJ1ZXIgYXUgcHJvY2Vzc3VzIGRlIGxhIGNy6WF0aW9uIG11c2ljYWxlLjxicj48YnI+VW4g
cHJpeCBzZXJhIHJlbWlzIGF1eCBsb2dpY2llbHMgcXVpIGZvbnQgcHJldXZlIG5vbiBzZXVsZW1l
bnQgZJJpbm5vdmF0aW9uLCBtYWlzIG5vdGFtbWVudCBkkmludmVudGl2aXTpIGZhY2UgYXV4IGVu
amV1eCBhY3R1ZWxzIGRlIGxhIGNy6WF0aW9uIG11c2ljYWxlLjxicj48YnI+PGI+Q2FsZW5kcmll
cjwvYj48YnI+PGI+NiBhdnJpbCAyMDEyIC0mbmJzcDs8L2I+QXBwZWwg4CBzb3VtaXNzaW9uczxi
cj48Yj4yOSBhdnJpbCAyMDEyIC0mbmJzcDs8L2I+RGF0ZSBsaW1pdGUgZGUgc291bWlzc2lvbiBk
ZXMgbG9naWNpZWxzPC9kaXY+PGRpdj48Yj41IG1haSAyMDEyIC0mbmJzcDs8L2I+Tm90aWZpY2F0
aW9uIGQnYWNjZXB0YXRpb248L2Rpdj48ZGl2PjxiPjExIG1haSAyMDEyIC0mbmJzcDs8L2I+UmVt
aXNlIGR1IHByaXggbG9ycyBkZXMgSklNIDIwMTI8L2Rpdj48ZGl2Pjxicj48Yj5JbmZvPC9iPiZu
YnNwOzombmJzcDs8YSBocmVmPSJodHRwOi8vY29uY291cnMuYWZpbS1hc3NvLm9yZy8iPmh0dHA6
Ly9jb25jb3Vycy5hZmltLWFzc28ub3JnLzwvYT48L2Rpdj48ZGl2PjxzcGFuIGNsYXNzPSJBcHBs
ZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmE7IGZvbnQtc2l6ZTogMTBw
eDsgIj48Yj5KSU0yMDEyIDo8L2I+PC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFu
IiBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmE7IGZvbnQtc2l6ZTogMTBweDsgIj4mbmJzcDs8
L3NwYW4+PGEgaHJlZj0iaHR0cDovL3d3dy5qaW0yMDEyLmJlLyI+aHR0cDovL3d3dy5qaW0yMDEy
LmJlPC9hPjxicj48YnI+PC9kaXY+PGRpdj48YiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyAiPjxi
cj48L2I+PC9kaXY+PGRpdj48YiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyAiPkxvTXVzIDIwMTI8
L2I+PC9kaXY+PGRpdj48YiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyAiPjxicj48L2I+PC9kaXY+
PGRpdj48YiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyAiPkluIHNlYXJjaCBvZiBvcGVuLXNvdXJj
ZSBzb2Z0d2FyZSBmb3IgbXVzaWNhbCBhbmQgaW50ZXJtZWRpYSBjcmVhdGlvbjwvYj48YnIgc3R5
bGU9ImZvbnQtc2l6ZTogMTNweDsgIj48YnI+Rm9yIGl0cyBmb3VydGggZWRpdGlvbiwgTG9NdXMg
MjAxMiBpbnZpdGVzIG11c2ljIGFuZCBhdWRpbyBvcGVuLXNvdXJjZSBzb2Z0d2FyZSBjcmVhdG9y
cyB0byBzdWJtaXQgb3JpZ2luYWwgcHJvamVjdHMgdGhhdCBlaXRoZXIgZGlyZWN0bHkgb3IgaW5k
aXJlY3RseSZuYnNwO2NvbnRyaWJ1dGUgdG8gbXVzaWNhbCBjcmVhdGlvbi48YnI+PGJyPkEgcHJp
emUgd2lsbCBiZSBhd2FyZGVkIHRvIG9wZW4tc291cmNlIHNvZndhcmUgdGhhdCBwcm92ZXMgdG8g
YmUgbm90IG9ubHkgaW5ub3ZhdG9yeSBidXQgYWxzbyBpbnZlbnRpdmUgaW4gdGhlIHByZXNlbnQg
Y29udGV4dCBvZiBtdXNpYyBhbmQgYXVkaW8gY3JlYXRpb24uPGJyPjxicj48YiBzdHlsZT0iZm9u
dC1zaXplOiAxM3B4OyAiPkNhbGVuZGFyPC9iPjwvZGl2PjxkaXY+PGI+QXByaWwgNiwgMjAxMjwv
Yj4mbmJzcDstIENhbGwgZm9yIHN1Ym1pc3Npb25zJm5ic3A7PC9kaXY+PGRpdj48Yj5BcHJpbCAy
OSwgMjAxMjwvYj4mbmJzcDstIFN1Ym1pc3Npb24gZGVhZGxpbmUmbmJzcDs8L2Rpdj48ZGl2Pjxi
Pk1heSA1LCAyMDEyPC9iPiZuYnNwOy0gQWRtaXNzaW9uIG5vdGlmaWNhdGlvbiZuYnNwOzwvZGl2
PjxkaXY+PGI+TWF5IDExLCAyMDEyPC9iPiZuYnNwOy0mbmJzcDtKSU0mbmJzcDtBd2FyZHMgQ2Vy
ZW1vbnk8L2Rpdj48ZGl2Pjxicj48Yj5JbmZvPC9iPjombmJzcDs8YSBocmVmPSJodHRwOi8vY29u
Y291cnMuYWZpbS1hc3NvLm9yZy8iPmh0dHA6Ly9jb25jb3Vycy5hZmltLWFzc28ub3JnLzwvYT48
L2Rpdj48ZGl2PjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1mYW1p
bHk6IFZlcmRhbmE7IGZvbnQtc2l6ZTogMTBweDsgIj48Yj5KSU0yMDEyIDo8L2I+PC9zcGFuPjxz
cGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmE7
IGZvbnQtc2l6ZTogMTBweDsgIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3d3dy5qaW0y
MDEyLmJlLyI+aHR0cDovL3d3dy5qaW0yMDEyLmJlPC9hPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2
PjxkaXY+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJib3JkZXItY29sbGFw
c2U6IHNlcGFyYXRlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogJ0x1Y2lkYSBH
cmFuZGUnOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50
OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxp
bmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh
bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2lu
ZzogMHB4OyAtd2Via2l0LWJvcmRlci1ob3Jpem9udGFsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC1i
b3JkZXItdmVydGljYWwtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtZGVjb3JhdGlvbnMtaW4t
ZWZmZWN0OiBub25lOyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4
dC1zdHJva2Utd2lkdGg6IDBweDsgIj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5
bGU9ImJvcmRlci1jb2xsYXBzZTogc2VwYXJhdGU7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt
ZmFtaWx5OiAnTHVjaWRhIEdyYW5kZSc7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y
bWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw
YWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1pbmRl
bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93
czogMjsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtYm9yZGVyLWhvcml6b250YWwtc3BhY2lu
ZzogMHB4OyAtd2Via2l0LWJvcmRlci12ZXJ0aWNhbC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4
dC1kZWNvcmF0aW9ucy1pbi1lZmZlY3Q6IG5vbmU7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDog
YXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyAiPjxkaXYgc3R5bGU9IndvcmQt
d3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUt
YnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPjxkaXY+PGEgaHJlZj0iaHR0cDovL3d3dy5sZS1o
dWIub3JnLyI+aHR0cDovL3d3dy5sZS1odWIub3JnLzwvYT48L2Rpdj48ZGl2Pjxicj48L2Rpdj48
L2Rpdj48L3NwYW4+PC9zcGFuPjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+

--===============1295328489101543702==--


From xbran@web.de Sun Apr 29 08:28:15 2012
From: Emanuel Rumpf <xbran@web.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: [LAD]  changes in gcc
Date: Sun, 29 Apr 2012 08:28:15 +0000
Message-ID:
 <CAGQuJFLpzC4HerX1zVVNWik=Wnd91gCMrTp-qex4brnNHXvhKA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1579557742573118484=="

--===============1579557742573118484==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Now ... isn't this a bit frustrating, if scripts stop to work after
only 5 years ??

I tried to compile ladspa-sdk, which failed.
As I found out, it is due to (nowadays) invalid argument order:

failed:
$(CC) $(CFLAGS)  $(LIBRARIES)   -o ../bin/listplugins   listplugins.o

works:
$(CC) $(CFLAGS)     -o ../bin/listplugins   listplugins.o     $(LIBRARIES)

gcc 4.6.3

--===============1579557742573118484==--


From paul@linuxaudiosystems.com Sun Apr 29 10:46:33 2012
From: Paul Davis <paul@linuxaudiosystems.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] changes in gcc
Date: Sun, 29 Apr 2012 10:46:33 +0000
Message-ID:
 <CAFa_cK=rCRZ3UofSob7yvBpghU3ntAOxm6QEMY_ScQRAMbGiPg@mail.gmail.com>
In-Reply-To:
 <CAGQuJFLpzC4HerX1zVVNWik=Wnd91gCMrTp-qex4brnNHXvhKA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6675425447113252796=="

--===============6675425447113252796==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

technically the first order (the one that fails) was always wrong.

its unfortunate that at least a generation or two of developers got
used to the fact that it was permitted.

On 4/29/12, Emanuel Rumpf <xbran(a)web.de> wrote:
> Now ... isn't this a bit frustrating, if scripts stop to work after
> only 5 years ??
>
> I tried to compile ladspa-sdk, which failed.
> As I found out, it is due to (nowadays) invalid argument order:
>
> failed:
> $(CC) $(CFLAGS)  $(LIBRARIES)   -o ../bin/listplugins   listplugins.o
>
> works:
> $(CC) $(CFLAGS)     -o ../bin/listplugins   listplugins.o     $(LIBRARIES)
>
> gcc 4.6.3
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>

--===============6675425447113252796==--


From radiovirusgenerator@gmail.com Sun Apr 29 11:12:40 2012
From: radiovirusgenerator <radiovirusgenerator@gmail.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] [LAU] Linux Audio Conference 2012 at CCRMA - proceedings
 and videos now available
Date: Sun, 29 Apr 2012 11:12:40 +0000
Message-ID: <4F9D2223.9030902@gmail.com>
In-Reply-To: <4F973E65.6090900@woh.rr.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6643350934682046781=="

--===============6643350934682046781==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On 04/25/2012 01:59 AM, Dave Phillips wrote:
> On 04/24/2012 06:55 PM, Robin Gareus wrote:
>>
>> Yes, we will do that, but before we can create the torrent we'll need to
>> have _all_ recordings. Two videos are still missing...
>
> One of which is my workshop. My apologies, I won't get to edit it=20
> until tomorrow. It should be back in Robin's hands by tomorrow evening.
>
> Best,
>
> dp

Hi all,

I am watching now the videos of the conference, thanks for sharing the=20
video!

Besides, I would like to report that the video:

http://lac.linuxaudio.org/2012/recordings/day2_1000_Studio_report_Linux_audio=
_for_multi-speaker_natural_speech_technology.ogv

it is not completed, it ends when the speaker begins to speak.

Best,
  Fabio.



>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev


--===============6643350934682046781==--


From brummer-@web.de Sun Apr 29 14:41:12 2012
From: hermann <brummer-@web.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: [LAD] Possible gpl validation
Date: Sun, 29 Apr 2012 14:41:12 +0000
Message-ID: <1335710469.2200.24.camel@box>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4042845451437048462=="

--===============4042845451437048462==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi all

For some time now there is a website witch offer a USB stick, a
slackware based Audio bundle full with GPL'd software. 
I have some discussions with the provider, because he wouldn't make the
source available to his (possible) users, and he wouldn't make them
aware that they have the right to receive the source.
 
I have contacted  license-violation(a)gpl-violations.org and get a fast
response first. On my question if they see a GPL validation they wrote
after visit the site :

> Looks like it. On the website he/she claims that everything is under 
> GPL. I would suggest contacting the person in question, gently
> pointing 
> out to his/her obligations.
> 
> If you have already done so, let us know and we'll try again.


Well, I let them know that I've try it without success. Unfortunately I
didn't hear any more from them for more the 2 weaks. 
Is anyone here on the list knowing what is to do now, what could we do
to make the provider aware that he must offer the source in the same way
then the binary's, and that he must make clear that users have the right
to receive the source. 
I guess most of the Copyright-holders from the used applications are
members of this list. 

At least, I still believe that no one how buy this stick, ever have a
interest in the source, so it is just a mater of respect for the GPL,
but, it's a shame for me to see the GPL validate in such a way and get
on top of that a response from the provider in a "Fuck off" attitude.

To bad that I need to provide the link to this crap here, so that you
could have a look at it:

http://www.getstudio1337.com/

here is the discussion about the issue:

http://www.linuxmusicians.com/viewtopic.php?f=4&t=7928


any Ideas what to do ?
Or I'm completely wrong in my understand of the GPL?

greets
hermann 



--===============4042845451437048462==--


From paul@linuxaudiosystems.com Sun Apr 29 15:07:30 2012
From: Paul Davis <paul@linuxaudiosystems.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] Possible gpl validation
Date: Sun, 29 Apr 2012 15:07:30 +0000
Message-ID:
 <CAFa_cKmj-hk6DpHnPWp4GLRJ-KrvQSb5LA2-Ch19bZ4eUqMthg@mail.gmail.com>
In-Reply-To: <1335710469.2200.24.camel@box>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8928076376437260619=="

--===============8928076376437260619==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Sun, Apr 29, 2012 at 10:41 AM, hermann <brummer-(a)web.de> wrote:

> Is anyone here on the list knowing what is to do now, what could we do
> to make the provider aware that he must offer the source in the same way
> then the binary's,

this part is not quite true. its generally accepted that as long as
the source is freel available from an identifiable online location,
then notifying people who received the binaries of their rights and
the location from which the source can be obtained is sufficient *if
there are no modifications*

--===============8928076376437260619==--


From robin@gareus.org Sun Apr 29 15:07:45 2012
From: Robin Gareus <robin@gareus.org>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] [LAU] Linux Audio Conference 2012 at CCRMA - proceedings
 and videos now available
Date: Sun, 29 Apr 2012 15:07:45 +0000
Message-ID: <4F9D593A.7090404@gareus.org>
In-Reply-To: <4F9D2223.9030902@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5534000486443286845=="

--===============5534000486443286845==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On 04/29/2012 01:12 PM, radiovirusgenerator wrote:
> On 04/25/2012 01:59 AM, Dave Phillips wrote:
>> On 04/24/2012 06:55 PM, Robin Gareus wrote:
>>>
>>> Yes, we will do that, but before we can create the torrent we'll need to
>>> have _all_ recordings. Two videos are still missing...
>>
>> One of which is my workshop. My apologies, I won't get to edit it
>> until tomorrow. It should be back in Robin's hands by tomorrow evening.
>>
>> Best,
>>
>> dp
>=20
> Hi all,
>=20
> I am watching now the videos of the conference, thanks for sharing the
> video!
>=20
> Besides, I would like to report that the video:
>=20
> http://lac.linuxaudio.org/2012/recordings/day2_1000_Studio_report_Linux_aud=
io_for_multi-speaker_natural_speech_technology.ogv
>=20
>=20
> it is not completed, it ends when the speaker begins to speak.
>
> Best,
>  Fabio.

Hi Fabio,

Thanks for the heads up. Fixed.
The URL/file-name has not changed - but the file has been updated.

# md5sum
day2_1000_Studio_report_Linux_audio_for_multi-speaker_natural_speech_technolo=
gy.ogv
81d44827075ee2370976890da1257b7f

We're still waiting for the last video and verifying the others.
Wrapping up LAC'12 should complete in a or two days.

Cheers!
robin

--===============5534000486443286845==--


From ralf.mardorf@alice-dsl.net Sun Apr 29 15:11:23 2012
From: Ralf Mardorf <ralf.mardorf@alice-dsl.net>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] Possible gpl validation
Date: Sun, 29 Apr 2012 15:11:23 +0000
Message-ID: <1335712262.3383.20.camel@precise>
In-Reply-To: <1335710469.2200.24.camel@box>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2170807985774240316=="

--===============2170807985774240316==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Sun, 2012-04-29 at 16:41 +0200, hermann wrote:
> At least, I still believe that no one how buy this stick, ever have a
> interest in the source

I disagree. IMO it's ok if a small distro doesn't provide the source, if
they instead make clear, that the distro is open source and if they also
don't take money. IIRC Mepis some years ago had issues, because the
sources were not provided, but IMO it was ok. This USB stick product IMO
is a rip off, if they don't make clear that everybody has the right to
get the source codes.

2 Cents,
Ralf

PS: "REAPER"?


--===============2170807985774240316==--


From brummer-@web.de Sun Apr 29 15:19:12 2012
From: hermann <brummer-@web.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] Possible gpl validation
Date: Sun, 29 Apr 2012 15:19:12 +0000
Message-ID: <1335712749.2200.32.camel@box>
In-Reply-To:
 <CAFa_cKmj-hk6DpHnPWp4GLRJ-KrvQSb5LA2-Ch19bZ4eUqMthg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3197669026393065140=="

--===============3197669026393065140==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Am Sonntag, den 29.04.2012, 11:07 -0400 schrieb Paul Davis:
> On Sun, Apr 29, 2012 at 10:41 AM, hermann <brummer-(a)web.de> wrote:
> 
> > Is anyone here on the list knowing what is to do now, what could we do
> > to make the provider aware that he must offer the source in the same way
> > then the binary's,
> 
> this part is not quite true. its generally accepted that as long as
> the source is freel available from an identifiable online location,
> then notifying people who received the binaries of their rights and
> the location from which the source can be obtained is sufficient *if
> there are no modifications*

But he fail already by notify people of there rights.

How could one say if there are modifications ?

Anyhow, for sure there is GPL'd software included, witch is modified,
and isn't available at a online location. 
He claim it as a modified slackware "OS" build.



--===============3197669026393065140==--


From A.Kuckartz@ping.de Sun Apr 29 15:51:51 2012
From: Andreas Kuckartz <A.Kuckartz@ping.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] Possible gpl validation
Date: Sun, 29 Apr 2012 15:51:51 +0000
Message-ID: <4F9D6393.1080901@ping.de>
In-Reply-To: <1335710469.2200.24.camel@box>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5427293994981429640=="

--===============5427293994981429640==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 29.04.2012 16:41, hermann wrote:
> For some time now there is a website witch offer a USB stick, a
> slackware based Audio bundle full with GPL'd software.
> I have some discussions with the provider, because he wouldn't make the
> source available to his (possible) users, and he wouldn't make them
> aware that they have the right to receive the source.

I am irritated by the "(possible)".

Did you or someone else get the binaries from him and then tried to get
the source code or did you try to get the source code first?

Cheers,
Andreas


--===============5427293994981429640==--


From brummer-@web.de Sun Apr 29 15:53:14 2012
From: hermann <brummer-@web.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] Possible gpl validation
Date: Sun, 29 Apr 2012 15:53:14 +0000
Message-ID: <1335714792.2200.38.camel@box>
In-Reply-To: <1335712262.3383.20.camel@precise>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7266874816598618005=="

--===============7266874816598618005==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Am Sonntag, den 29.04.2012, 17:11 +0200 schrieb Ralf Mardorf:
> On Sun, 2012-04-29 at 16:41 +0200, hermann wrote:
> > At least, I still believe that no one how buy this stick, ever have a
> > interest in the source
> 
> I disagree. IMO it's ok if a small distro doesn't provide the source, if
> they instead make clear, that the distro is open source and if they also
> don't take money. IIRC Mepis some years ago had issues, because the
> sources were not provided, but IMO it was ok. This USB stick product IMO
> is a rip off, if they don't make clear that everybody has the right to
> get the source codes.
> 
> 2 Cents,
> Ralf
> 
> PS: "REAPER"?
> 
I guess you misunderstood me, I mean, that, if "you" buy this stick,
then "you" will properly never ask for the source, then you will be a
plain musician without any interest in "software source". Otherwise, you
will direct go to the source ad build your own stick, following the
instructions  from this links:

http://slackermedia.info/html/
http://www.studioware.org/



--===============7266874816598618005==--


From brummer-@web.de Sun Apr 29 16:00:35 2012
From: hermann <brummer-@web.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] Possible gpl validation
Date: Sun, 29 Apr 2012 16:00:35 +0000
Message-ID: <1335715233.2200.45.camel@box>
In-Reply-To: <4F9D6393.1080901@ping.de>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5295279342987175363=="

--===============5295279342987175363==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Am Sonntag, den 29.04.2012, 17:51 +0200 schrieb Andreas Kuckartz:
> On 29.04.2012 16:41, hermann wrote:
> > For some time now there is a website witch offer a USB stick, a
> > slackware based Audio bundle full with GPL'd software.
> > I have some discussions with the provider, because he wouldn't make the
> > source available to his (possible) users, and he wouldn't make them
> > aware that they have the right to receive the source.
> 
> I am irritated by the "(possible)".
> 
> Did you or someone else get the binaries from him and then tried to get
> the source code or did you try to get the source code first?
> 
> Cheers,
> Andreas
> 
I'm not a lawyer, nor an expert of GPL. I have a understand of GPL,
witch I see validated here, but I cant say for sure that it is the fact.

No, I wouldn't buy those crap, and I didn't know anyone how buy it. But
in a discussion with the provider, he said that he wouldn't provide the
source, also not for regular users if they request it.

This is the second time this guy distribute sticks wich binary s and he
claim that he didn't need to provide the source. That is, what he
understand under the GPL. 

greets
hermann 



--===============5295279342987175363==--


From xbran@web.de Sun Apr 29 16:33:08 2012
From: Emanuel Rumpf <xbran@web.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] Possible gpl validation
Date: Sun, 29 Apr 2012 16:33:08 +0000
Message-ID:
 <CAGQuJFLe+8Ar8avC=fnTS7goMpChVCxk5Xk=w-Seko24ajgq2A@mail.gmail.com>
In-Reply-To: <1335715233.2200.45.camel@box>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0726221538769796843=="

--===============0726221538769796843==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

2012/4/29 hermann <brummer-(a)web.de>:
>
> This is the second time this guy distribute sticks wich binary s and he
> claim that he didn't need to provide the source. That is, what he
> understand under the GPL.
>

As I understood the GPL, he/she doesn't have to offer the source code
to non-customers.
( GPL can be used commercially. )

But in the FAQ they say :
"
If you commercially distribute binaries not accompanied with source
code, the GPL says you must _ provide a written offer _ to distribute
the source code later. When users non-commercially redistribute the
binaries they received from you, they must pass along a copy of this
written offer.

This means that people who did not get the binaries directly from you
can still receive copies of the source code, along with the written
offer.
"

http://www.gnu.org/licenses/gpl-faq.html

-- 
E.R.

--===============0726221538769796843==--


From brummer-@web.de Sun Apr 29 18:58:04 2012
From: hermann <brummer-@web.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] Possible gpl validation
Date: Sun, 29 Apr 2012 18:58:04 +0000
Message-ID: <1335725882.2200.63.camel@box>
In-Reply-To:
 <CAGQuJFLe+8Ar8avC=fnTS7goMpChVCxk5Xk=w-Seko24ajgq2A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3878539026439827527=="

--===============3878539026439827527==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Am Sonntag, den 29.04.2012, 18:33 +0200 schrieb Emanuel Rumpf:
> 2012/4/29 hermann <brummer-(a)web.de>:
> >
> > This is the second time this guy distribute sticks wich binary s and he
> > claim that he didn't need to provide the source. That is, what he
> > understand under the GPL.
> >
> 
> As I understood the GPL, he/she doesn't have to offer the source code
> to non-customers.
> ( GPL can be used commercially. )
> 
> But in the FAQ they say :
> "
> If you commercially distribute binaries not accompanied with source
> code, the GPL says you must _ provide a written offer _ to distribute
> the source code later. When users non-commercially redistribute the
> binaries they received from you, they must pass along a copy of this
> written offer.
> 
> This means that people who did not get the binaries directly from you
> can still receive copies of the source code, along with the written
> offer.
> "
> 
> http://www.gnu.org/licenses/gpl-faq.html
> 

yes, that is how I understand it also, but he explizit say that he
wouldn't do that. He only distribute binarys, no source available, for
no-one ever. No " _ provide a written offer _ " ever :-(|)

Not for the included Applications, nor for the "OS" itself. 


--===============3878539026439827527==--


From jeremy@autostatic.com Sun Apr 29 19:12:49 2012
From: Jeremy Jongepier <jeremy@autostatic.com>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] Possible gpl validation
Date: Sun, 29 Apr 2012 19:12:49 +0000
Message-ID: <4F9D92AE.4020407@autostatic.com>
In-Reply-To: <1335710469.2200.24.camel@box>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1135284714846697849=="

--===============1135284714846697849==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 04/29/2012 04:41 PM, hermann wrote:
> any Ideas what to do ?

Hello Hermann,

Just ignore this whole Studio 1337 thing, trying to conversate normally 
with the guy behind it will only stress you out.

Best,

Jeremy

--===============1135284714846697849==--


From eviltwin69@cableone.net Sun Apr 29 20:44:10 2012
From: Jan Depner <eviltwin69@cableone.net>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] Possible gpl validation
Date: Sun, 29 Apr 2012 20:44:10 +0000
Message-ID: <1335732244.12332.7.camel@eviltwin>
In-Reply-To:
 <CAFa_cKmj-hk6DpHnPWp4GLRJ-KrvQSb5LA2-Ch19bZ4eUqMthg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6523199415307113479=="

--===============6523199415307113479==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Sun, 2012-04-29 at 11:07 -0400, Paul Davis wrote:
> On Sun, Apr 29, 2012 at 10:41 AM, hermann <brummer-(a)web.de> wrote:
> 
> > Is anyone here on the list knowing what is to do now, what could we do
> > to make the provider aware that he must offer the source in the same way
> > then the binary's,
> 
> this part is not quite true. its generally accepted that as long as
> the source is freel available from an identifiable online location,
> then notifying people who received the binaries of their rights and
> the location from which the source can be obtained is sufficient *if
> there are no modifications*

I agree with Paul.  He's got all of the included package's web site
links on his web site.  If you want to duplicate what he's done you can
just jump to all of those links, get all the source code, and build it
yourself.  Thirty bucks doesn't sound like too high a price to avoid the
headaches though (assuming it works ;-)

Jan



--===============6523199415307113479==--


From brummer-@web.de Mon Apr 30 04:20:13 2012
From: hermann <brummer-@web.de>
To: linux-audio-dev@lists.linuxaudio.org
Subject: Re: [LAD] Possible gpl validation
Date: Mon, 30 Apr 2012 04:20:13 +0000
Message-ID: <1335759607.2169.8.camel@box>
In-Reply-To: <1335732244.12332.7.camel@eviltwin>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0486931466013567603=="

--===============0486931466013567603==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Am Sonntag, den 29.04.2012, 15:44 -0500 schrieb Jan Depner:
> On Sun, 2012-04-29 at 11:07 -0400, Paul Davis wrote:
> > On Sun, Apr 29, 2012 at 10:41 AM, hermann <brummer-(a)web.de> wrote:
> > 
> > > Is anyone here on the list knowing what is to do now, what could we do
> > > to make the provider aware that he must offer the source in the same way
> > > then the binary's,
> > 
> > this part is not quite true. its generally accepted that as long as
> > the source is freel available from an identifiable online location,
> > then notifying people who received the binaries of their rights and
> > the location from which the source can be obtained is sufficient *if
> > there are no modifications*
> 
> I agree with Paul.  He's got all of the included package's web site
> links on his web site.  If you want to duplicate what he's done you can
> just jump to all of those links, get all the source code, and build it
> yourself.  Thirty bucks doesn't sound like too high a price to avoid the
> headaches though (assuming it works ;-)
> 
> Jan
> 

The link list is far away from "all". 
eg.: libs, kernel, etc. 
The price is not in question. But I think, if one use GPL'd software
commercial, the distributor must make sure that the source is available
to the users, I mean the complete source here.
This stick is a bit more then a bundle of applications were a link to
some project site will suite the requirements of the GPL. 

hermann   


--===============0486931466013567603==--