All:
Based on some of the recent discussions on LAD and LAU, I
thought it prudent to forward this message from the
Jack-Devel list.
If you wish to continue the discussion on the the Jack
session management API, please do it on the Jack-Devel list.
Scroll down to the very bottom for a URL to the list.
-gabriel
---------- Forwarded message ----------
Date: Thu, 4 Mar 2010 18:16:39 -0500
From: Paul Davis <paul(a)linuxaudiosystems.com>
To: jack-devel(a)lists.jackaudio.org
Subject: Re: [Jack-Devel] session management API proposal, take 3
[ ... chatter chatter chatter ... ]
i'm on the verge of approving the API proposed by Torben for inclusion
as part of the JACK API. I believe that it accomplishes the goal of
leveraging an existing IPC channel (via libjack), combined with a
minimalistic set of changes to the server and easy-to-implement
support in clients, to provide the basis for session management at
different levels of sophistication, depending on a user's needs.
Torben's example showed the generation of a shell script that will
restart the session, and this is probably the "bottom line" in terms
of simple session management.
There are still some details (below) but more importantly, I would
like to hear from people who have concrete objections, particularly of
the following form:
* the proposal does not address some functionality that it should address
* the proposal will make later, more extensive session management
harder, more complex or impossible
* the proposal is nonsensical because ...
As for details...
I agree with the suggestion that the initial set of session events
should include "quit".
Nedko has also raised some objections to the use of a UUID, and has
proposed a scheme based on PIDs. I personally do not understand how
this can possibly work if JACK is to retain the ability to support
multiple clients per process. Any scheme designed to use PIDs but
still allow this seems to me to have to turn the PID into a UUID by
combining it with some other information (eg. a client name). This
doesn't seem to be semantically different from starting with a
declaration that we use UUIDs to identify clients - how the UUIDs are
constructed is an implementation detail.
Finally, the semantics of the return codes from a session event need
to be pinned down better, since there are circumstances where a client
could *not* save its state without that being an error (e.g. ardour
running with a session on read-only media). For this, I currently
propose:
success == client believes that it will be able to restore its
state to the current state upon a reload
fail = client believes that it will not (or may not) be able to
restore its state to the current state upon a reload
similar semantics will be needed for each other defined session event.
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Hi,
As I heard from the Debian jackd maintainer:
In Debian testing/ squeeze and very likely in Ubuntu lucid, it's not
neccesary anymore to manual edit /etc/security/limits.conf! It's been
automatically done by jackd in /etc/security/limits.d/audio.conf and it
will conflict with /etc/security/limits.conf.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507248
Such things are good to know if you're member of the LAU community, and
I feel communication is lacking often with these kind of things...
\r
Hi,
Is there an audio app which supports Jack Transport bpm changes in
realtime? I know some midi apps like hydrogen and non-sequencer, but not
audio apps which can play and/or record audio.
Regards,
\r
Ah cool, is it already in the current jack release? Too lazy to look.
Gerald
On Fri, 2010-03-05 at 12:06 +0100, torbenh wrote:
> On Fri, Mar 05, 2010 at 11:48:11AM +0100, Gerald Mwangi wrote:
> > Hi, this is a part of a previous mail,but with catchier Subject
> >
> > I think LASH should be integrated into Jack, to make it mandatory for
> > linux audio apps. The missing LASH support is one of the main issues
> > disturbing me, when working with linux audio. Now I've said it, ha.
> > I'm thinking of having Jack require a Load/Save callback, prior to
> > activating the client. How feasible is that?
> > What do you think?
> > Gerald
>
> i think this:
> http://hochstrom.endofinternet.org/cgit/jack.git/tree/jack/session.h?h=jack…
>
>
>> But actually you guys lost me a bit, what is so important about the plugin paradigma?
if you have quite a lot plugins with good presets, you actually don't
have to learn anything. just try this and try that, and you've done.
--
sex, bike, open source!
Hi, this is a part of a previous mail,but with catchier Subject
I think LASH should be integrated into Jack, to make it mandatory for
linux audio apps. The missing LASH support is one of the main issues
disturbing me, when working with linux audio. Now I've said it, ha.
I'm thinking of having Jack require a Load/Save callback, prior to
activating the client. How feasible is that?
What do you think?
Gerald
Hello, from users' perspective, what are currently the options for
minimum session handling? I'd just like for a starter to have multiple
sets of connections and be able to save and load them.
Is there any documentation on at least one way of doing this? Couldn't
find any
Is patchage capable of doing this? What exactly does the "save
positions" menu entry do?
In second order, what may we expect from the near future in terms of
more advanced session handling (lash, ladi)? Are they
(lash/ladi) currently usable and used? (Certainly they lack
documentation)
Renato
Hello!
sorry for crossposting, but I didn't know, where to best reach the
LS-wizards.
I wondered about convolution in LinuxSampler. The GS3 format certainly
supports in-sampler convolving (having their own files for that). I seem to
rememb3er, that working out the format was not the real issue, but the
implementation itself. But there I think Fons offered his convolution classes
- as used in jconv - to easily implement it.
As I now have more and more nice sounds, including even more handsome IRs
(either rooms or body IRs) I was wondering, if the convolution issue is still
persued. I certainly would very much appreciate it!
So could someone please give me an update of the way LS is going?
Warm regards
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de
Wouldn't a simple LED/photodetector pair attached to a simple bracket
that would straddle the crank gear teeth generate a very useful, and
high-resolution, train of pulses? I constructed a wooden ramp with
sides containing two such pair to conduct basic acceleration experiments
in a high-school physics lab. It was easy to write programs to perform
the detection and timing counts.
In fact, those pulses alone would drive a speaker/headphones in an
interesting sounding manner much like that aforementioned trading card
in the spokes arrangement. You could power the LED by battery or the
bike's generator, and options for a circuit to process the pulse stream
could be both simple and richly functional.
Frank
Hello,
(pre-prost-scriptum: improtant informations are quite below!!!)
I think I didn't any announcement here before, but the label I created
some years ago, and work in by now, released two albums fully realized
with free softwares (on a Debian GNU/Linux distribution) in 2008:
Sebkha-Chott - Nigla[h] / Tapisseries Fines en XXX Strips et LXX/X Trompettes
Sebkha-Chott - De la Persistance de la Mythologie Chottienne en ??? Vélos
Both those albums are distributed internationally by the label Muséa
Records, and you may find them, freely downloadable and/or to purchase
here:
www.ammd.net/productions/productions.php
and at a lot of other places on the web. You also might find numerous
review of those albums, in Google, and so on.
OK, that's it for the presentation.
Actually, it took us a lot of time, but we finally sent the whole tracks
of the 14 multitracks session (in ardour) and the session them selves on
archive.org, so that you can use them freely.
it's quite big big big sessions, as Sebkha-Chott used to be 8 people at
that time and invited something like 25-30 guests to play with. So you
might find something like 100-150 (even 180 on one of them, if I
remember well) tracks by song.
For Nigla[h], there are two options: we did tarball of each ardour
sessions directory and we also bounced every tracks in one file, so that
you can manage to use them in another multitrack editor.
We then thought about it, and had the conclusion that it was a really
hard work for us to do all these bounces and exports, and finally it
essentially was destined to people using proprietary softwares.
So, for De la Persistance, you will only find the tarballs, as we think
we have to "encourage" people using ardour, or, if they prefer ecasound
or whatever, they probably will be skilled enough to convert the xml
file into something suitable for another soft, or a bit worse, they
always might do all that export stuff and so on.
The archive.org links are listed on
www.ammd.net/productions/productions.php
Hope you will enjoy it. All our further productions will follow the very
same line (there will be one recording session in November for a
pop-prog-rock band), and we also aim to release some very huge
instruments sample base, as we have the luck to possess a very good
studio, and also very good instrument, including, for example, a true
Harpsichord, as one of us do build Harpsichords!
See you.
Aurélien - AMMD www.ammd.net
PS: For off-list further informations, please write to orlATammmmmmmd.net,
which is my pro mail, which I don't want to subscribe on this list (and
ammd does spell with two 'm' only! ;)
--
Aurélien