30 Jun
2011
30 Jun
'11
11:03 a.m.
Linux Audio Developer,
May I make a feature request here for your Linuxaudio application(s)?
Could you please add JackSession support? It makes working with JACK
standalone applications a lot more user friendly. There are some apps
who support it already and they work fine, like Yoshimi, Qtractor,
Pianoteq, Ghostess, Guitarix, Jack-Rack, Ardour3, Bristol, Seq24, Jalv,
Ingen, Connie, Specimen and probably more.
It is possible to use applications without JackSession-support in a
session (via so called infra clients), it starts the applications, make
the connections, but doesn't save the state. So obviously it would be
far more useful if those applications would get JackSession-support also.
Qjackctl is able to work as Session Manager, so is Pyjacksm (and likely
Patchage in the future).
According to comments on IRC by Paul Davis, it's very easy to add
JackSession support to your application.
"Its really easy, just handle 1 more callback from the server. Torben's
walkthrough shows what is necessary."
Torben's walktrough:
http://trac.jackaudio.org/wiki/WalkThrough/Dev/JackSession
Thanks in advance,
\r
30 Jun
30 Jun
11:32 a.m.
On Thu, 30 Jun 2011 11:03:05 +0200
rosea grammostola <rosea.grammostola(a)gmail.com> wrote:
Linux Audio Developer,
May I make a feature request here for your Linuxaudio application(s)?
Could you please add JackSession support? It makes working with JACK
standalone applications a lot more user friendly. There are some apps
who support it already and they work fine, like Yoshimi, Qtractor,
Pianoteq, Ghostess, Guitarix, Jack-Rack, Ardour3, Bristol, Seq24,
Jalv, Ingen, Connie, Specimen and probably more.
It is possible to use applications without JackSession-support in a
session (via so called infra clients), it starts the applications,
make the connections, but doesn't save the state. So obviously it
would be far more useful if those applications would get
JackSession-support also.
Qjackctl is able to work as Session Manager, so is Pyjacksm (and
likely Patchage in the future).
According to comments on IRC by Paul Davis, it's very easy to add
JackSession support to your application.
"Its really easy, just handle 1 more callback from the server.
Torben's walkthrough shows what is necessary."
Torben's walktrough:
http://trac.jackaudio.org/wiki/WalkThrough/Dev/JackSession
Thanks in advance,
\r
I second this, I tried using jacksession a few days ago and it seems
to me it works very well; it does what it should and nothing more, it is
not intrusive
cheers
renato
11:43 a.m.
On 06/30/2011 11:31 AM, Renato wrote:
On Thu, 30 Jun 2011 11:03:05 +0200
rosea grammostola<rosea.grammostola(a)gmail.com> wrote:
Maybe good to note also is that almost all recent distros (also
multimedia distros like AVLinux, Tango Studio etc.) have the latest
Jackd version these days (JACK1 and/ or JACK2, both support
JackSession). So apps with JackSession support are compiled with
JackSession automatically on those distros (no need to add a patch or a
special build parameter or anything like that). :)
Regards,
\r
Linux Audio Developer,
May I make a feature request here for your Linuxaudio application(s)?
Could you please add JackSession support? It makes working with JACK
standalone applications a lot more user friendly. There are some apps
who support it already and they work fine, like Yoshimi, Qtractor,
Pianoteq, Ghostess, Guitarix, Jack-Rack, Ardour3, Bristol, Seq24,
Jalv, Ingen, Connie, Specimen and probably more.
It is possible to use applications without JackSession-support in a
session (via so called infra clients), it starts the applications,
make the connections, but doesn't save the state. So obviously it
would be far more useful if those applications would get
JackSession-support also.
Qjackctl is able to work as Session Manager, so is Pyjacksm (and
likely Patchage in the future).
According to comments on IRC by Paul Davis, it's very easy to add
JackSession support to your application.
"Its really easy, just handle 1 more callback from the server.
Torben's walkthrough shows what is necessary."
Torben's walktrough:
http://trac.jackaudio.org/wiki/WalkThrough/Dev/JackSession
Thanks in advance,
\r
I second this, I tried using jacksession a few days ago and it seems
to me it works very well; it does what it should and nothing more, it is
not intrusive 
12:01 p.m.
Am Thu, 30 Jun 2011 11:43:50 +0200
schrieb rosea grammostola <rosea.grammostola(a)gmail.com>om>:
On 06/30/2011 11:31 AM, Renato wrote:
hey ho,
i am very interested to implement jack session into hydrogen. but i am a bit confused
about how it is to use as a user.
i understand how to implement it into an application. thx to
http://trac.jackaudio.org/wiki/WalkThrough/Dev/JackSession.
but i miss a simple howto use jacksession in your local audio envirement.
whatever exist such a document for dummies like me?
lg wolke
On Thu, 30 Jun 2011 11:03:05 +0200
rosea grammostola<rosea.grammostola(a)gmail.com> wrote:
Maybe good to note also is that almost all recent distros (also
multimedia distros like AVLinux, Tango Studio etc.) have the latest
Jackd version these days (JACK1 and/ or JACK2, both support
JackSession). So apps with JackSession support are compiled with
JackSession automatically on those distros (no need to add a patch or a
special build parameter or anything like that). :)
Regards,
\r Linux Audio Developer,
May I make a feature request here for your Linuxaudio application(s)?
Could you please add JackSession support? It makes working with JACK
standalone applications a lot more user friendly. There are some apps
who support it already and they work fine, like Yoshimi, Qtractor,
Pianoteq, Ghostess, Guitarix, Jack-Rack, Ardour3, Bristol, Seq24,
Jalv, Ingen, Connie, Specimen and probably more.
It is possible to use applications without JackSession-support in a
session (via so called infra clients), it starts the applications,
make the connections, but doesn't save the state. So obviously it
would be far more useful if those applications would get
JackSession-support also.
Qjackctl is able to work as Session Manager, so is Pyjacksm (and
likely Patchage in the future).
According to comments on IRC by Paul Davis, it's very easy to add
JackSession support to your application.
"Its really easy, just handle 1 more callback from the server.
Torben's walkthrough shows what is necessary."
Torben's walktrough:
http://trac.jackaudio.org/wiki/WalkThrough/Dev/JackSession
Thanks in advance,
\r
I second this, I tried using jacksession a few days ago and it seems
to me it works very well; it does what it should and nothing more, it is
not intrusive _______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
12:11 p.m.
On 06/30/2011 12:00 PM, m.wolkstein(a)gmx.de wrote:
Am Thu, 30 Jun 2011 11:43:50 +0200
schrieb rosea grammostola<rosea.grammostola(a)gmail.com>om>:
Wolke,
Understanding the dev side and not the user side, that is the world
up-side-down for me ;)
http://trac.jackaudio.org/wiki/WalkThrough/User/jack_session
You need Jackd > = 0.120 or 1.9.7 and qjackctl 0.3.7
Start qjackctl, start JACK
Start an app with JS support (yoshimi)
Make the desired connections
In qjackctl 0.3.7, you have a session window, open it.
Save session
Make a *new* folder (be careful not to overwrite an other folder (should
become more safe in the next Qjackctl version))
Select that new folder to save the session to.
You can quit the session by just quitting the applications, or choose
save (save and quit)
You can load the session via the load button in the Session window of
Qjackctl, choose the right session folder.
HTH
\r
On 06/30/2011 11:31 AM, Renato wrote:
hey ho,
i am very interested to implement jack session into hydrogen. but i am a bit confused
about how it is to use as a user.
i understand how to implement it into an application. thx to
http://trac.jackaudio.org/wiki/WalkThrough/Dev/JackSession.
but i miss a simple howto use jacksession in your local audio envirement.
whatever exist such a document for dummies like me? On Thu, 30 Jun 2011 11:03:05 +0200
rosea grammostola<rosea.grammostola(a)gmail.com> wrote:
Maybe good to note also is that almost all recent distros (also
multimedia distros like AVLinux, Tango Studio etc.) have the latest
Jackd version these days (JACK1 and/ or JACK2, both support
JackSession). So apps with JackSession support are compiled with
JackSession automatically on those distros (no need to add a patch or a
special build parameter or anything like that). :)
Regards,
\r Linux Audio Developer,
May I make a feature request here for your Linuxaudio application(s)?
Could you please add JackSession support? It makes working with JACK
standalone applications a lot more user friendly. There are some apps
who support it already and they work fine, like Yoshimi, Qtractor,
Pianoteq, Ghostess, Guitarix, Jack-Rack, Ardour3, Bristol, Seq24,
Jalv, Ingen, Connie, Specimen and probably more.
It is possible to use applications without JackSession-support in a
session (via so called infra clients), it starts the applications,
make the connections, but doesn't save the state. So obviously it
would be far more useful if those applications would get
JackSession-support also.
Qjackctl is able to work as Session Manager, so is Pyjacksm (and
likely Patchage in the future).
According to comments on IRC by Paul Davis, it's very easy to add
JackSession support to your application.
"Its really easy, just handle 1 more callback from the server.
Torben's walkthrough shows what is necessary."
Torben's walktrough:
http://trac.jackaudio.org/wiki/WalkThrough/Dev/JackSession
Thanks in advance,
\r
I second this, I tried using jacksession a few days ago and it seems
to me it works very well; it does what it should and nothing more, it is
not intrusive
12:22 p.m.
On 06/30/2011 12:11 PM, rosea grammostola wrote:
On 06/30/2011 12:00 PM, m.wolkstein(a)gmx.de wrote:
You have to browse one subfolder
backwards to be able to select your new
session folder likely.
Am Thu, 30 Jun 2011 11:43:50 +0200
schrieb rosea grammostola<rosea.grammostola(a)gmail.com>om>:
Wolke,
Understanding the dev side and not the user side, that is the world
up-side-down for me ;)
http://trac.jackaudio.org/wiki/WalkThrough/User/jack_session
You need Jackd > = 0.120 or 1.9.7 and qjackctl 0.3.7
Start qjackctl, start JACK
Start an app with JS support (yoshimi)
Make the desired connections
In qjackctl 0.3.7, you have a session window, open it.
Save session
Make a *new* folder (be careful not to overwrite an other folder
(should become more safe in the next Qjackctl version))
Select that new folder to save the session to. On 06/30/2011 11:31 AM, Renato wrote:
hey ho,
i am very interested to implement jack session into hydrogen. but i
am a bit confused about how it is to use as a user.
i understand how to implement it into an application. thx to
http://trac.jackaudio.org/wiki/WalkThrough/Dev/JackSession.
but i miss a simple howto use jacksession in your local audio
envirement.
whatever exist such a document for dummies like me? On Thu, 30 Jun 2011 11:03:05 +0200
rosea grammostola<rosea.grammostola(a)gmail.com> wrote:
> Linux Audio Developer,
>
>
> May I make a feature request here for your Linuxaudio application(s)?
>
> Could you please add JackSession support? It makes working with JACK
> standalone applications a lot more user friendly. There are some apps
> who support it already and they work fine, like Yoshimi, Qtractor,
> Pianoteq, Ghostess, Guitarix, Jack-Rack, Ardour3, Bristol, Seq24,
> Jalv, Ingen, Connie, Specimen and probably more.
>
> It is possible to use applications without JackSession-support in a
> session (via so called infra clients), it starts the applications,
> make the connections, but doesn't save the state. So obviously it
> would be far more useful if those applications would get
> JackSession-support also.
>
> Qjackctl is able to work as Session Manager, so is Pyjacksm (and
> likely Patchage in the future).
>
> According to comments on IRC by Paul Davis, it's very easy to add
> JackSession support to your application.
>
> "Its really easy, just handle 1 more callback from the server.
> Torben's walkthrough shows what is necessary."
>
> Torben's walktrough:
> http://trac.jackaudio.org/wiki/WalkThrough/Dev/JackSession
>
>
> Thanks in advance,
>
> \r
>
I second this, I tried using jacksession a few days ago and it seems
to me it works very well; it does what it should and nothing more,
it is
not intrusive
Maybe good to note also is that almost all recent distros (also
multimedia distros like AVLinux, Tango Studio etc.) have the latest
Jackd version these days (JACK1 and/ or JACK2, both support
JackSession). So apps with JackSession support are compiled with
JackSession automatically on those distros (no need to add a patch or a
special build parameter or anything like that). :)
Regards,
\r You can quit the session by just quitting the
applications, or choose
save (save and quit)
It is possible to overwrite an existing Jacksession folder
(again, be
careful to overwrite the right one!!!)
Atm there is no way to stop a session via a button without saving the
session ...
You can load the session via the load button in the
Session window of
Qjackctl, choose the right session folder.
That's the new folder you made to
save the session obviously.
HTH
\r
1:13 p.m.
Am Thu, 30 Jun 2011 12:22:01 +0200
schrieb rosea grammostola <rosea.grammostola(a)gmail.com>om>:
On 06/30/2011 12:11 PM, rosea grammostola wrote:
thx, for your quick response. in fact that will help me.
i just noticed the new session button in qjackctl. super, so far this will looks like an
easy to use session handler.
and yes, i am a lazy bugger:). mostly i use my spare time for other things, than to find
out how computers applications will work.
lg wolke
On 06/30/2011 12:00 PM, m.wolkstein(a)gmx.de
wrote:
You have to browse one subfolder
backwards to be able to select your new
session folder likely.
Am Thu, 30 Jun 2011 11:43:50 +0200
schrieb rosea grammostola<rosea.grammostola(a)gmail.com>om>:
Wolke,
Understanding the dev side and not the user side, that is the world
up-side-down for me ;)
http://trac.jackaudio.org/wiki/WalkThrough/User/jack_session
You need Jackd > = 0.120 or 1.9.7 and qjackctl 0.3.7
Start qjackctl, start JACK
Start an app with JS support (yoshimi)
Make the desired connections
In qjackctl 0.3.7, you have a session window, open it.
Save session
Make a *new* folder (be careful not to overwrite an other folder
(should become more safe in the next Qjackctl version))
Select that new folder to save the session to. On 06/30/2011 11:31 AM, Renato wrote:
> On Thu, 30 Jun 2011 11:03:05 +0200
> rosea grammostola<rosea.grammostola(a)gmail.com> wrote:
>
>> Linux Audio Developer,
>>
>>
>> May I make a feature request here for your Linuxaudio application(s)?
>>
>> Could you please add JackSession support? It makes working with JACK
>> standalone applications a lot more user friendly. There are some apps
>> who support it already and they work fine, like Yoshimi, Qtractor,
>> Pianoteq, Ghostess, Guitarix, Jack-Rack, Ardour3, Bristol, Seq24,
>> Jalv, Ingen, Connie, Specimen and probably more.
>>
>> It is possible to use applications without JackSession-support in a
>> session (via so called infra clients), it starts the applications,
>> make the connections, but doesn't save the state. So obviously it
>> would be far more useful if those applications would get
>> JackSession-support also.
>>
>> Qjackctl is able to work as Session Manager, so is Pyjacksm (and
>> likely Patchage in the future).
>>
>> According to comments on IRC by Paul Davis, it's very easy to add
>> JackSession support to your application.
>>
>> "Its really easy, just handle 1 more callback from the server.
>> Torben's walkthrough shows what is necessary."
>>
>> Torben's walktrough:
>> http://trac.jackaudio.org/wiki/WalkThrough/Dev/JackSession
>>
>>
>> Thanks in advance,
>>
>> \r
>>
> I second this, I tried using jacksession a few days ago and it seems
> to me it works very well; it does what it should and nothing more,
> it is
> not intrusive
Maybe good to note also is that almost all recent distros (also
multimedia distros like AVLinux, Tango Studio etc.) have the latest
Jackd version these days (JACK1 and/ or JACK2, both support
JackSession). So apps with JackSession support are compiled with
JackSession automatically on those distros (no need to add a patch or a
special build parameter or anything like that). :)
Regards,
\r
hey ho,
i am very interested to implement jack session into hydrogen. but i
am a bit confused about how it is to use as a user.
i understand how to implement it into an application. thx to
http://trac.jackaudio.org/wiki/WalkThrough/Dev/JackSession.
but i miss a simple howto use jacksession in your local audio
envirement.
whatever exist such a document for dummies like me? You can quit the session by just quitting the
applications, or choose
save (save and quit)
It is possible to overwrite an existing Jacksession folder
(again, be
careful to overwrite the right one!!!)
Atm there is no way to stop a session via a button without saving the
session ...
You can load the session via the load button in
the Session window of
Qjackctl, choose the right session folder.
That's the new folder you made to
save the session obviously.
HTH
\r
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
1:21 p.m.
On 06/30/2011 01:13 PM, m.wolkstein(a)gmx.de wrote:
Am Thu, 30 Jun 2011 12:22:01 +0200
schrieb rosea grammostola<rosea.grammostola(a)gmail.com>om>:
Glad to help here.
Hydrogen is a typical application where JackSession is very useful imo.
Same is true for PHASEX, Rakarrack, Lv2rack (and other LV2 hosts), VMPK,
Patchage, Composite and all other similar JACK standalone applications. ;)
Best regards,
\r
On 06/30/2011 12:11 PM, rosea grammostola wrote:
thx, for your quick response. in fact that will help me.
i just noticed the new session button in qjackctl. super, so far this will looks like an
easy to use session handler.
and yes, i am a lazy bugger:). mostly i use my spare time for other things, than to find
out how computers applications will work. On 06/30/2011 12:00 PM, m.wolkstein(a)gmx.de
wrote:
You have to browse one subfolder
backwards to be able to select your new
session folder likely.
Am Thu, 30 Jun 2011 11:43:50 +0200
schrieb rosea grammostola<rosea.grammostola(a)gmail.com>om>:
> On 06/30/2011 11:31 AM, Renato wrote:
>> On Thu, 30 Jun 2011 11:03:05 +0200
>> rosea grammostola<rosea.grammostola(a)gmail.com> wrote:
>>
>>> Linux Audio Developer,
>>>
>>>
>>> May I make a feature request here for your Linuxaudio application(s)?
>>>
>>> Could you please add JackSession support? It makes working with JACK
>>> standalone applications a lot more user friendly. There are some apps
>>> who support it already and they work fine, like Yoshimi, Qtractor,
>>> Pianoteq, Ghostess, Guitarix, Jack-Rack, Ardour3, Bristol, Seq24,
>>> Jalv, Ingen, Connie, Specimen and probably more.
>>>
>>> It is possible to use applications without JackSession-support in a
>>> session (via so called infra clients), it starts the applications,
>>> make the connections, but doesn't save the state. So obviously it
>>> would be far more useful if those applications would get
>>> JackSession-support also.
>>>
>>> Qjackctl is able to work as Session Manager, so is Pyjacksm (and
>>> likely Patchage in the future).
>>>
>>> According to comments on IRC by Paul Davis, it's very easy to add
>>> JackSession support to your application.
>>>
>>> "Its really easy, just handle 1 more callback from the server.
>>> Torben's walkthrough shows what is necessary."
>>>
>>> Torben's walktrough:
>>> http://trac.jackaudio.org/wiki/WalkThrough/Dev/JackSession
>>>
>>>
>>> Thanks in advance,
>>>
>>> \r
>>>
>> I second this, I tried using jacksession a few days ago and it seems
>> to me it works very well; it does what it should and nothing more,
>> it is
>> not intrusive
> Maybe good to note also is that almost all recent distros (also
> multimedia distros like AVLinux, Tango Studio etc.) have the latest
> Jackd version these days (JACK1 and/ or JACK2, both support
> JackSession). So apps with JackSession support are compiled with
> JackSession automatically on those distros (no need to add a patch or a
> special build parameter or anything like that). :)
>
> Regards,
> \r
hey ho,
i am very interested to implement jack session into hydrogen. but i
am a bit confused about how it is to use as a user.
i understand how to implement it into an application. thx to
http://trac.jackaudio.org/wiki/WalkThrough/Dev/JackSession.
but i miss a simple howto use jacksession in your local audio
envirement.
whatever exist such a document for dummies like me?
Wolke,
Understanding the dev side and not the user side, that is the world
up-side-down for me ;)
http://trac.jackaudio.org/wiki/WalkThrough/User/jack_session
You need Jackd> = 0.120 or 1.9.7 and qjackctl 0.3.7
Start qjackctl, start JACK
Start an app with JS support (yoshimi)
Make the desired connections
In qjackctl 0.3.7, you have a session window, open it.
Save session
Make a *new* folder (be careful not to overwrite an other folder
(should become more safe in the next Qjackctl version))
Select that new folder to save the session to. You can quit the session by just quitting the
applications, or choose
save (save and quit)
It is possible to overwrite an existing Jacksession folder
(again, be
careful to overwrite the right one!!!)
Atm there is no way to stop a session via a button without saving the
session ...
You can load the session via the load button in
the Session window of
Qjackctl, choose the right session folder.
That's the new folder you made to
save the session obviously.
> HTH
> \r
>
>
> 
1:13 p.m.
Understanding the dev side and not the user side, that
is the world
up-side-down for me ;)
That is quite possible -- the API that a "host" (session handler) uses
to communicate with "clients" / "plugins" / whatever says nothing
about how that "host" calls those API functions, how it structures
disk storage, etc.
Note that for developers there is also API documentation, which
explains some things better:
http://jackaudio.org/files/docs/html/group__SessionClientFunctions.html
This one looks unfortunately very thin at the moment...
-- Dan
6:20 p.m.
On Thu, 2011-06-30 at 11:03 +0200, rosea grammostola wrote:
[...]
Qjackctl is able to work as Session Manager, so is
Pyjacksm (and likely
Patchage in the future).
There is very preliminary support in Patchage in SVN, but the format in
which it currently saves sessions is a bit sketchy. The next release
will hopefully be ready soon and have proper Jack session manager
support (as well as massive memory consumption improvements).
-dr
7:22 p.m.
On 06/30/2011 06:20 PM, David Robillard wrote:
On Thu, 2011-06-30 at 11:03 +0200, rosea grammostola
wrote:
[...]
Wow, how great is
that! Thanks.
\r
Qjackctl is able to work as Session Manager, so
is Pyjacksm (and likely
Patchage in the future).
There is very preliminary support in Patchage in SVN, but
the format in
which it currently saves sessions is a bit sketchy. The next release
will hopefully be ready soon and have proper Jack session manager
support (as well as massive memory consumption improvements).
2 Jul
2 Jul
10:40 p.m.
Am Thu, 30 Jun 2011 11:03:05 +0200
schrieb rosea grammostola <rosea.grammostola(a)gmail.com>om>:
huhu,
i currently finished a simple hydrogen implementation.
callback with:
save session(save the current song file)
save and exit(save and quit hydrogen)
so far so good.
but i didn't agree to save the application data into the jack-session folder!
imo, this is dangerous because you can lost all data very quick. mainly if you overwrite
a session. also people like me, which plays often improvised music-sessions, will
create tons of sessions folders with duplicated data.
that's why i prefer the h2 implementation with absolute filenames. so currently h2
don't
use the ${SESSION_DIR} prefix to store the song files.
checkout hydrogen trunk to get it.
if jack/session.h is available on your system, hydrogen compile by default with jack
session support.
lg wolke
Linux Audio Developer,
May I make a feature request here for your Linuxaudio application(s)?
Could you please add JackSession support? It makes working with JACK
standalone applications a lot more user friendly. There are some apps
who support it already and they work fine, like Yoshimi, Qtractor,
Pianoteq, Ghostess, Guitarix, Jack-Rack, Ardour3, Bristol, Seq24, Jalv,
Ingen, Connie, Specimen and probably more.
It is possible to use applications without JackSession-support in a
session (via so called infra clients), it starts the applications, make
the connections, but doesn't save the state. So obviously it would be
far more useful if those applications would get JackSession-support also.
Qjackctl is able to work as Session Manager, so is Pyjacksm (and likely
Patchage in the future).
According to comments on IRC by Paul Davis, it's very easy to add
JackSession support to your application.
"Its really easy, just handle 1 more callback from the server. Torben's
walkthrough shows what is necessary."
Torben's walktrough:
http://trac.jackaudio.org/wiki/WalkThrough/Dev/JackSession
Thanks in advance,
\r
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
11:02 p.m.
On 07/02/2011 10:40 PM, m.wolkstein(a)gmx.de wrote:
Am Thu, 30 Jun 2011 11:03:05 +0200
schrieb rosea grammostola<rosea.grammostola(a)gmail.com>om>:
huhu,
i currently finished a simple hydrogen implementation.
callback with:
save session(save the current song file)
save and exit(save and quit hydrogen)
so far so good.
Thanks a lot! I am surprised how fast devs are picking this up.
Phasex,
Hydrogen, Rakarrack ... great work already :)
Next thing what would be good to have imo is a good software mixer with
JackSession support. Unfortunately non-mixer is not a good candidate
afaik, cause it changes port names. I don't know if Fons is still busy
with his mixer and if he has explored and made up his mind about the
actual implementation of the JackSession API already. Otherwise Jack
Audio Mixer might be a good candidate maybe: http://home.gna.org/jackmixer/
but i didn't agree to save the application data
into the jack-session folder!
imo, this is dangerous because you can lost all data very quick. mainly if you overwrite
a session. also people like me, which plays often improvised music-sessions, will
create tons of sessions folders with duplicated data.
that's why i prefer the h2 implementation with absolute filenames. so currently h2
don't
use the ${SESSION_DIR} prefix to store the song files.
Qjackctl 0.3.8 has the
possibility to use 'versioning', it makes backups
of the old folder when you overwrite it.
I wonder how much space those folders take in general and if that space
is really a problem normally.
Would be good if Torben (and/ or Rui) could comment on this.
checkout hydrogen trunk to get it.
if jack/session.h is available on your system, hydrogen compile by default with jack
session support.
Regards,
\r
lg wolke
Linux Audio Developer,
May I make a feature request here for your Linuxaudio application(s)?
Could you please add JackSession support? It makes working with JACK
standalone applications a lot more user friendly. There are some apps
who support it already and they work fine, like Yoshimi, Qtractor,
Pianoteq, Ghostess, Guitarix, Jack-Rack, Ardour3, Bristol, Seq24, Jalv,
Ingen, Connie, Specimen and probably more.
It is possible to use applications without JackSession-support in a
session (via so called infra clients), it starts the applications, make
the connections, but doesn't save the state. So obviously it would be
far more useful if those applications would get JackSession-support also.
Qjackctl is able to work as Session Manager, so is Pyjacksm (and likely
Patchage in the future).
According to comments on IRC by Paul Davis, it's very easy to add
JackSession support to your application.
"Its really easy, just handle 1 more callback from the server. Torben's
walkthrough shows what is necessary."
Torben's walktrough:
http://trac.jackaudio.org/wiki/WalkThrough/Dev/JackSession
Thanks in advance,
\r
_______________________________________________
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 
3 Jul
3 Jul
12:27 a.m.
On Sat, Jul 02, 2011 at 11:02:27PM +0200, rosea grammostola wrote:
Next thing what would be good to have imo is a good
software mixer with
JackSession support. Unfortunately non-mixer is not a good candidate
afaik, cause it changes port names. I don't know if Fons is still busy
with his mixer and if he has explored and made up his mind about the
actual implementation of the JackSession API already.
Fons has been quite busy moving home the last weeks (not far,
south of Parma to north of Parma, but it's the same exercise
independent of distance anyway).
As to the mixer, yes I'm still working on it. A lot of thinking
has gone into the design, and some aspects of it may turn out
to be surprising as they break with Linux Audio traditions.
One of them is external connections. The mixer will be able to
use Jack of course, but does not require it. When using Jack, it
will have a configurable number of inputs and outputs which have
fixed names, just input-%d or output-%d. Any one of these can be
patched internally to any channel, group, insert, send, or whatever
that makes sense. The idea behind this is that Jack connections
are fixed, and any session dependent wiring is done internally.
A second one is the plugin system wich will be specific to this
application. I will not even support LADSPA. If anyone wants to
use his/her favourite plugin with this mixer, just convince me
to port it - the criterion will be the quality of the plugin -
or do it yourself.
As to Jack Session support, I won't even consider it as long
as it doesn't support quit-without-save. The rationale for not
supporting this is IMNSHO completely bogus. I just can't imagine
any app that a) can't do this, and b) can't be modified easily
to do it. 'Easily' here means requiring a fraction of the effort
to support Jack Session at all. I've got some other gripes with
Jack Session as well, but these have been discussed (or at least
presented) before.
Ciao,
--
FA
11:53 a.m.
On 07/03/2011 12:27 AM, Fons Adriaensen wrote:
On Sat, Jul 02, 2011 at 11:02:27PM +0200, rosea
grammostola wrote:
Good luck with that.
Next thing what would be good to have imo is a
good software mixer with
JackSession support. Unfortunately non-mixer is not a good candidate
afaik, cause it changes port names. I don't know if Fons is still busy
with his mixer and if he has explored and made up his mind about the
actual implementation of the JackSession API already.
Fons has been quite busy
moving home the last weeks (not far,
south of Parma to north of Parma, but it's the same exercise
independent of distance anyway). As to the mixer, yes I'm still working on it. A
lot of thinking
has gone into the design, and some aspects of it may turn out
to be surprising as they break with Linux Audio traditions.
One of them is external connections. The mixer will be able to
use Jack of course, but does not require it. When using Jack, it
will have a configurable number of inputs and outputs which have
fixed names, just input-%d or output-%d. Any one of these can be
patched internally to any channel, group, insert, send, or whatever
that makes sense. The idea behind this is that Jack connections
are fixed, and any session dependent wiring is done internally.
A second one is the plugin system wich will be specific to this
application. I will not even support LADSPA. If anyone wants to
use his/her favourite plugin with this mixer, just convince me
to port it - the criterion will be the quality of the plugin -
or do it yourself.
Interesting for sure...
One feature request already then. Could you please port the plugins of
Mr Adriaensen? They are pretty good normally. ;)
As to Jack Session support, I won't even consider
it as long
as it doesn't support quit-without-save. The rationale for not
supporting this is IMNSHO completely bogus. I just can't imagine
any app that a) can't do this, and b) can't be modified easily
to do it. 'Easily' here means requiring a fraction of the effort
to support Jack Session at all. I've got some other gripes with
Jack Session as well, but these have been discussed (or at least
presented) before.
I did some quick testing with some apps with JS support, and it
seems to
work quite well. Alas.. to make a Session Manager a success you might
need some compromises and collaboration. But I do agree with you about
the quit-without-save option. I have reported this already (so did
Adrian Knoth). Torben thought that such a option might cause unwanted
loosing data, but a message by the Session Manager with something like
'are you sure you want to quit without saving' should be sufficient I
think. As far as I understood it wasn't impossible or a lot of work to
implement this in the Session Manager.
Regards,
\r
1:43 p.m.
On Sun, Jul 03, 2011 at 11:53:29AM +0200, rosea grammostola wrote:
Thanks ! I'm at my new place, basic life support is installed,
and I'm unpacking things as I need them. And using a hijacked
wireless acces point since it will be a week or two before I
have ADSL...
Fons has been
quite busy moving home the last weeks (not far,
south of Parma to north of Parma, but it's the same exercise
independent of distance anyway).
Good luck with that. One feature request already then. Could you please
port the plugins of
Mr Adriaensen? They are pretty good normally. ;)
In the LADSPAs there's not much that could be part of a mixer.
If you mean the zita-*** apps, these have been written to be
used as test cases for the plugin API. Only a few have been
released (at1 and rev1), but there are many more and all will
be included. But not all may be GPL licensed.
Alas.. to make a Session Manager a success you might
need some compromises and collaboration.
If 'compromises' means starting from ad-hoc solutions
chosen 'to make things as easy as possible for devs'
instead of doing a serious analysis, and consequently
adding required functionality results in a mess, then
I prefer not to make compromises. There are lots of
examples of this. JSM is one of them, it's a mess
even in its initial form.
Ciao,
--
FA
2:10 p.m.
On Sun, Jul 3, 2011 at 7:43 AM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
JSM is one of them, it's a mess
even in its initial form.
its important to point out that this is a criticism that could be
levelled at JACK too.
your analysis was thoughtful and sensible. as it turned out, neither
torben nor I agreed with it. as it stands, the JACK Session API is a
minimal, barely intrusive addition that gets done 90%+ of what the
users of JACK wanted/needed. the design goals behind JACK have always
included a strong aversion to going after the 100% solution because I
and others have strong feelings about the infeasibility of it in
general, mostly because of a profound awareness of the total SNAFUs
that seem to happen everytime somebody tries this in software. so no,
it doesn't do everything possible, or everything desirable, or
everything perfectly, but it does do most of what people actually
need, without having much impact on developers' own internal
architecture.
the lack of quit-without-save is a decision that i was opposed to, but
accepted precisely because it has the potential to interfere with
developer's internal architecture. most applications these days ask if
you attempt to quit without saving (some will even treat the window
manager close button as a trigger for this). quit-without-save
(potentially) requires a new code path that circumvents whatever
internal logic the program has to decide whether to ask the user. its
not a huge change, but it is a change that isn't merely additive (as
is the case for the rest of the API). in the interest of seeing
something adopted that performs a useful role for users, it seemed
better not to require supporting JACK Session to also require "your
program must be able to quit without any user interaction".
2:51 p.m.
On 07/03/2011 02:10 PM, Paul Davis wrote:
On Sun, Jul 3, 2011 at 7:43 AM, Fons Adriaensen
<fons(a)linuxaudio.org> wrote:
Every program (on un*x) can be "quit w/o save" without requiring changes
to the program: just send it a `kill -9` :-))
It's not nice but should fit easily into the 90%+ pragmatic solution
package.
Alas, jackd may or may not bark (xrun) if a program is killed without
properly closing its jack connection; but that's acceptable in that case
(closing the session anyway).
just saying,
robin
JSM is one of them, it's a mess
even in its initial form.
its important to point out that this is a criticism that could be
levelled at JACK too.
your analysis was thoughtful and sensible. as it turned out, neither
torben nor I agreed with it. as it stands, the JACK Session API is a
minimal, barely intrusive addition that gets done 90%+ of what the
users of JACK wanted/needed. the design goals behind JACK have always
included a strong aversion to going after the 100% solution because I
and others have strong feelings about the infeasibility of it in
general, mostly because of a profound awareness of the total SNAFUs
that seem to happen everytime somebody tries this in software. so no,
it doesn't do everything possible, or everything desirable, or
everything perfectly, but it does do most of what people actually
need, without having much impact on developers' own internal
architecture.
the lack of quit-without-save is a decision that i was opposed to, but
accepted precisely because it has the potential to interfere with
developer's internal architecture. most applications these days ask if
you attempt to quit without saving (some will even treat the window
manager close button as a trigger for this). quit-without-save
(potentially) requires a new code path that circumvents whatever
internal logic the program has to decide whether to ask the user. its
not a huge change, but it is a change that isn't merely additive (as
is the case for the rest of the API). in the interest of seeing
something adopted that performs a useful role for users, it seemed
better not to require supporting JACK Session to also require "your
program must be able to quit without any user interaction".
3:01 p.m.
On Sun, Jul 3, 2011 at 8:51 AM, Robin Gareus <robin(a)linuxaudio.org> wrote:
Every program (on un*x) can be "quit w/o
save" without requiring changes
to the program: just send it a `kill -9` :-))
if (request.type == QuitWithoutSave) {
kill (getpid(), SIGKILL);
}
oops, you didn't reply to the session manager, which wants to know how
to restart you.
ok, so we leave it to the SM to kill you ... but using SIGKILL for
this is about as bad as LADISH using SIGUSR1 for its own purposes.
which is to say - it works, but its Not Unix :)
Alas, jackd may or may not bark (xrun) if a program is
killed without
properly closing its jack connection; but that's acceptable in that case
(closing the session anyway).
I think that the SM should tell JACK to stop calling process(), somehow.
3:19 p.m.
On 07/03/2011 03:01 PM, Paul Davis wrote:
Well, sometimes one does not to see the wood for the trees..
Is "quit w/o save" really needed? IMHO a smarter way would be to
"auto-save" the session every e.g. 5 mins and add keep those as
revisions in a repository.
JACK does not require additional code, all functionality would be done
by the session-management tool. A "quit w/o save" would just "quit with
save" and then roll-back to the last saved session state or snapshot (if
any).
2c,
robin
On Sun, Jul 3, 2011 at 8:51 AM, Robin Gareus
<robin(a)linuxaudio.org> wrote:
I should have known that you already considered this option.
Every program (on un*x) can be "quit w/o
save" without requiring changes
to the program: just send it a `kill -9` :-))
if (request.type == QuitWithoutSave) {
kill (getpid(), SIGKILL);
}
oops, you didn't reply to the session manager, which wants to know how
to restart you.
ok, so we leave it to the SM to kill you ... but using SIGKILL for
this is about as bad as LADISH using SIGUSR1 for its own purposes.
which is to say - it works, but its Not Unix :) Alas, jackd
may or may not bark (xrun) if a program is killed without
properly closing its jack connection; but that's acceptable in that case
(closing the session anyway).
I think that the SM should tell JACK to stop calling process(), somehow.
3:24 p.m.
On Sun, Jul 3, 2011 at 9:19 AM, Robin Gareus <robin(a)linuxaudio.org> wrote:
Is "quit w/o save" really needed? IMHO a
smarter way would be to
"auto-save" the session every e.g. 5 mins and add keep those as
revisions in a repository.
if you think about it, this is also quite intrusive on application
architecture. quit-with-save has all kinds of reasonably safe
assumptions that can be made, even though some of them are not
actually documented. the entire JACK graph is shutting down, the
clients' job is to save data. contrast with an auto-save, where normal
processing must continue even as it happens.
6:04 p.m.
On Sun, Jul 03, 2011 at 08:10:09AM -0400, Paul Davis wrote:
the lack of quit-without-save is a decision that i was
opposed to, but
accepted precisely because it has the potential to interfere with
developer's internal architecture. most applications these days ask if
you attempt to quit without saving (some will even treat the window
manager close button as a trigger for this). quit-without-save
(potentially) requires a new code path that circumvents whatever
internal logic the program has to decide whether to ask the user.
It requires nothing new, just calling the existing code that is linked
to the 'Just Quit' button (using Ardour as an example).
Ciao,
--
FA
6:32 p.m.
On Sun, Jul 3, 2011 at 12:04 PM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Sun, Jul 03, 2011 at 08:10:09AM -0400, Paul Davis
wrote:
sure, which right now is not a separate function at all, but merely a
branch of the "finish" function. not exactly a huge amount of work to
split it out, but indicative of the complete (and understandable)
design assumption "there's no way to get here except via the GUI".
otoh, you're right, in the sense that quit-WITH-save is even more
complex, and faces all the same issues with threading etc, only more
so because it actually has data to save etc. etc.
the lack of quit-without-save is a decision that
i was opposed to, but
accepted precisely because it has the potential to interfere with
developer's internal architecture. most applications these days ask if
you attempt to quit without saving (some will even treat the window
manager close button as a trigger for this). quit-without-save
(potentially) requires a new code path that circumvents whatever
internal logic the program has to decide whether to ask the user.
It requires nothing new, just calling the existing code that is linked
to the 'Just Quit' button (using Ardour as an example). 
7:09 p.m.
SaveAndQuit (without Quit only) is not so bad, as it appears
initially. Actually I seem to like the idea of this simplification.
Although one has to get used to it.
What I'm really missing is SaveAndClose (without application Quit !).
Restarting all applications for changing a session doesn't appear
practical.
--
E.R.
7:32 p.m.
On Sun, Jul 3, 2011 at 1:09 PM, Emanuel Rumpf <xbran(a)web.de> wrote:
SaveAndQuit (without Quit only) is not so bad, as it
appears
initially. Actually I seem to like the idea of this simplification.
Although one has to get used to it.
What I'm really missing is SaveAndClose (without application Quit !).
Restarting all applications for changing a session doesn't appear
practical.
i feel that if you spend too long reasoning about this, you will
conclude, as I have, that JACK was actually a mistake (at least in
terms of the basic framework in which to glue together different
things processing data streams). the absence of a plugin API that was
likely to be adopted by all/most developers back in 2000 is what gave
rise to this situation. there's a limit to how far you can push the
usability of a "DAW" built out of N independent processes, each one
running code developed by different developers with no awareness of
the others. the limit is, thankfully, not too primitive, but its also
not far enough out to be able to pretend that JACK + N>1 clients is
actually functionally equivalent to a single host + plugins, at least
not in terms of state management.
--p
8:27 p.m.
2011/7/3 Paul Davis <paul(a)linuxaudiosystems.com>om>:
i feel that if you spend too long reasoning about this, you will
conclude, as I have, that JACK was actually a mistake (at least in
terms of the basic framework in which to glue together different
things processing data streams). the absence of a plugin API that was
likely to be adopted by all/most developers back in 2000 is what gave
rise to this situation. there's a limit to how far you can push the
usability of a "DAW" built out of N independent processes, each one
running code developed by different developers with no awareness of
the others. the limit is, thankfully, not too primitive, but its also
not far enough out to be able to pretend that JACK + N>1 clients is
actually functionally equivalent to a single host + plugins, at least
not in terms of state management.
--p
I see, that treading many different apps as one large entity (with
state management etc.)
is a difficult task. (That's why other systems decided for plugins, I think.)
Unix (as operating system) doesn't particular help there. (Neither do others.)
New technologies are coming (dbus, cloud-apps, etc.)
but it's not clear to me, which is the best approach for such demands.
I'm not dispraising JACK.
It has been a very important innovation,
that has pushed audio application development for linux tremendously,
by creating a reliable base, with a not too difficult api.
Since you are one of the main actors there,
I really have to thank you for making this progression possible !
--
E.R.
9:59 p.m.
On Sun, Jul 3, 2011 at 10:32 AM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
i feel that if you spend too long reasoning about
this, you will
conclude, as I have, that JACK was actually a mistake (at least in
terms of the basic framework in which to glue together different
things processing data streams). the absence of a plugin API that was
likely to be adopted by all/most developers back in 2000 is what gave
rise to this situation. there's a limit to how far you can push the
usability of a "DAW" built out of N independent processes, each one
running code developed by different developers with no awareness of
the others. the limit is, thankfully, not too primitive, but its also
not far enough out to be able to pretend that JACK + N>1 clients is
actually functionally equivalent to a single host + plugins, at least
not in terms of state management.
I'm curious about what you might have done differently if you knew
then what you know now.
--
Devin Anderson
devin (at) charityfinders (dot) com
CharityFinders - http://www.charityfinders.com/
synthclone - http://synthclone.googlecode.com/
10:07 p.m.
On Sun, Jul 3, 2011 at 3:59 PM, Devin Anderson <devin(a)charityfinders.com> wrote:
I'm curious about what you might have done
differently if you knew
then what you know now.
what *should* have happened was a plugin API that as many developers
as now use JACK would have agreed to adopt.
what could have happened was something like JACK.
politics is the art of the possible.
10:14 p.m.
On Sun, 3 Jul 2011 16:07:53 -0400
Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Sun, Jul 3, 2011 at 3:59 PM, Devin Anderson
<devin(a)charityfinders.com> wrote:
So (excusing my ignorance) are we approaching a brick wall or is there a way
out?
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
I'm curious about what you might have done
differently if you knew
then what you know now.
what *should* have happened was a plugin API that as many developers
as now use JACK would have agreed to adopt.
what could have happened was something like JACK.
politics is the art of the possible.
3 Jul
3 Jul
11:32 p.m.
On Sun, Jul 3, 2011 at 1:07 PM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Sun, Jul 3, 2011 at 3:59 PM, Devin Anderson
<devin(a)charityfinders.com> wrote:
I guess the easy thing to say here is that LV2 *could* be that API,
but I don't see the same amount of interest in LV2 that there is in
JACK. Maybe I'm wrong.
I'm curious about what you might have done
differently if you knew
then what you know now.
what *should* have happened was a plugin API that as many developers
as now use JACK would have agreed to adopt. what could have happened was something like JACK.
JACK has a lot of useful, non-trivial functionality that isn't going
to be found in a plugin API (hardware interfacing, moving audio/MIDI
around safely and efficiently, etc.). Perhaps a host API would be
just as helpful.
politics is the art of the possible.
Indeed.
--
Devin Anderson
devin (at) charityfinders (dot) com
CharityFinders - http://www.charityfinders.com/
synthclone - http://synthclone.googlecode.com/
11:41 p.m.
On Sun, Jul 3, 2011 at 5:32 PM, Devin Anderson <devin(a)charityfinders.com> wrote:
On Sun, Jul 3, 2011 at 1:07 PM, Paul Davis
<paul(a)linuxaudiosystems.com> wrote:
it was true then, and and its true now. we're developers. biting off
on JACK doesn't constrain you very much, and the extent to which it
does generally seems to be welcome. you're still writing "a program"
and you can still pretty much do whatever you want.
biting off on a given plugin API and conceding what you're writing is
"just" a plugin, along with all the potential hassles about control of
the plugin parameters via a GUI, MIDI, OSC, potentially losing access
to timeline and tempo information, etc, etc ... this is enough to
deter most people and encourage them to write JACK clients. in
addition, JACK gives you the instant "2 for 1" hit - plays nice with
others, but also plays nice alone (or least with just the server).
these are compelling reasons for a developer. they are mostly
irrelevant for most users. not completely irrelevant, and not for all
users.
On Sun, Jul 3, 2011 at 3:59 PM, Devin Anderson
<devin(a)charityfinders.com> wrote:
I guess the easy thing to say here is that LV2 *could* be that API,
but I don't see the same amount of interest in LV2 that there is in
JACK. Maybe I'm wrong. I'm curious about what you might have done
differently if you knew
then what you know now.
what *should* have happened was a plugin API that as many developers
as now use JACK would have agreed to adopt.
4 Jul
4 Jul
12:38 a.m.
On Sun, Jul 3, 2011 at 2:41 PM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Sun, Jul 3, 2011 at 5:32 PM, Devin Anderson
<devin(a)charityfinders.com> wrote:
That makes me think about VST, and the amount of VST plugins that are
available. The VST API *feels* cheap, and yet there are many VST
hosts out there, and applications like `synthedit` make VST plugin
creation accessible to non-developers and tinkerers as well as
developers.
I'm not sure if I fully understand the issues surrounding control of
plugin parameters in plugins vs. JACK applications. AFAICT, any
plugin or JACK application that wants to handle changes from more than
one source will still have to deal with the complexity of merging
changes from multiple sources. Is there something I'm missing?
AFAIK, there isn't an LV2 extension yet that solves the timeline/tempo
map problem. I definitely find that a major deterrent in using LV2
plugins, let alone writing them.
--
Devin Anderson
devin (at) charityfinders (dot) com
CharityFinders - http://www.charityfinders.com/
synthclone - http://synthclone.googlecode.com/
On Sun, Jul 3, 2011 at 1:07 PM, Paul Davis
<paul(a)linuxaudiosystems.com> wrote:
biting off on a given plugin API and conceding what you're writing is
"just" a plugin, along with all the potential hassles about control of
the plugin parameters via a GUI, MIDI, OSC, potentially losing access
to timeline and tempo information, etc, etc ... this is enough to
deter most people and encourage them to write JACK clients. On Sun, Jul 3, 2011 at 3:59 PM, Devin Anderson
<devin(a)charityfinders.com> wrote:
I guess the easy thing to say here is that LV2 *could* be that API,
but I don't see the same amount of interest in LV2 that there is in
JACK. Maybe I'm wrong. I'm curious about what you might have done
differently if you knew
then what you know now.
what *should* have happened was a plugin API that as many developers
as now use JACK would have agreed to adopt. 
12:48 a.m.
On 07/03/2011 07:32 PM, Paul Davis wrote:
i feel that if you spend too long reasoning about
this, you will
conclude, as I have, that JACK was actually a mistake (at least in
terms of the basic framework in which to glue together different
things processing data streams). the absence of a plugin API that was
likely to be adopted by all/most developers back in 2000 is what gave
rise to this situation. there's a limit to how far you can push the
usability of a "DAW" built out of N independent processes, each one
running code developed by different developers with no awareness of
the others.
true if you are arguing from the "streamlined workflow" pov only.
but the unix way is "make simple things easy" (= use one daw and
everything else is a plugin) _and_ "make hard things possible". jack
doesn't hurt the former and excels at the latter. none of the audio
stuff i routinely do everyday would be possible without jack.
it's great to be able to combine stuff in ways the developers did not
(need to) anticipate. that usually means combining separate processes.
jack is really unixy, and it certainly deserves the highest praise i
could think of: it's totally |y.
3:23 a.m.
2011/7/3 Dave Phillips <dlphillips(a)woh.rr.com>om>:
Jörn Nettingsmeier wrote:
I disagree with both of you. I think what you really mean is "none of
this would be possible without some system for interconnecting
processing elements together in flexible, creative,possibly
unanticipated ways that also leaves the developers of those elements
free to do things in their own way".
that much i'd agree with. but this is not a description that requires
that the solution be at the process level.
... none of the audio stuff i routinely do
everyday would be possible
without jack.
Amen to that. 
5:10 a.m.
On Mon, Jul 4, 2011 at 10:23 AM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
2011/7/3 Dave Phillips <dlphillips(a)woh.rr.com>om>:
While technically I'm sure you're correct, I'd add a further caveat
that puts me on the side of Dave and Jörn. The specific and existing
applications and inter-application communication that JACK has
permitted is not easily replicable with any other given existing
modular system, and there are plenty of modular systems available from
PD to Max/MSP to audiomulch to bidule to Reason to ... you get the
point. Given that the solution that I enjoy using the most is JACK on
Linux with all of the process level folly that it entails, even though
it needn't have to be that way given the plethora of non-process level
alternatives, surely this must say something good about the system as
a whole (or admittedly, bad about me)?
-Michael
Jörn Nettingsmeier wrote:
I disagree with both of you. I think what you really mean is "none of
this would be possible without some system for interconnecting
processing elements together in flexible, creative,possibly
unanticipated ways that also leaves the developers of those elements
free to do things in their own way".
that much i'd agree with. but this is not a description that requires
that the solution be at the process level. ... none of the audio stuff i routinely do
everyday would be possible
without jack.
Amen to that.
5 Jul
5 Jul
8:35 a.m.
On 07/04/2011 03:23 AM, Paul Davis wrote:
2011/7/3 Dave Phillips<dlphillips(a)woh.rr.com>om>:
well, like ladspa, jack has its time and place, and it has triggered an
amazing surge of activity. to me, it's the best infrastructure in the
market.
when it was conceived, there was no way to do what it does except at the
process level. and now that we know how to combine multiple gui toolkits
in a single process, it still looks very good.
and as long as jack keeps scaling over multiple cpu cores, we have
cycles in abundance - so where's the harm in some inter-process
communication overhead?
rather than lumping all audio into a single process, i'd say jack should
even strengthen the boundaries between processes, such that it doesn't
die as easily when a node in the graph goes bad, to make it even better
suited for live use than it already is.
Jörn Nettingsmeier wrote:
I disagree with both of you. I think what you really mean is "none of
this would be possible without some system for interconnecting
processing elements together in flexible, creative,possibly
unanticipated ways that also leaves the developers of those elements
free to do things in their own way".
that much i'd agree with. but this is not a description that requires
that the solution be at the process level. ... none of the audio stuff i routinely do
everyday would be possible
without jack.
Amen to that.
12:40 p.m.
2011/7/4 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>
On 07/04/2011 03:23 AM, Paul Davis wrote:
With JackSession quite some drawbacks of JACK will be countered. It is / was
very user unfriendly to all the plumbing yourself again and again.
Anyway, we're getting a bit offtopic here. You might want to start a new
thread about the past and future of JACK and a plugin API (LV2)
Regards,
\r
2011/7/3 Dave
Phillips<dlphillips(a)woh.rr.com**>**>:
well, like ladspa, jack has its time and place, and it has triggered an
amazing surge of activity. to me, it's the best infrastructure in the
market.
when it was conceived, there was no way to do what it does except at the
process level. and now that we know how to combine multiple gui toolkits in
a single process, it still looks very good.
and as long as jack keeps scaling over multiple cpu cores, we have cycles
in abundance - so where's the harm in some inter-process communication
overhead?
rather than lumping all audio into a single process, i'd say jack should
even strengthen the boundaries between processes, such that it doesn't die
as easily when a node in the graph goes bad, to make it even better suited
for live use than it already is.
Jörn Nettingsmeier wrote:
... none of the audio stuff i routinely do everyday would be possible
I disagree with both of you. I think what you really mean is "none of
this would be possible without some system for interconnecting
processing elements together in flexible, creative,possibly
unanticipated ways that also leaves the developers of those elements
free to do things in their own way".
that much i'd agree with. but this is not a description that requires
that the solution be at the process level.
without jack.
Amen to that.
4 Jul
4 Jul
4:18 p.m.
On Sun, Jul 03, 2011 at 01:32:09PM -0400, Paul Davis wrote:
On Sun, Jul 3, 2011 at 1:09 PM, Emanuel Rumpf
<xbran(a)web.de> wrote:
I don't think it was a mistake to provide flexible audio connectivity
between processes. Even if the ideal situation is to integrate things
to a level that typical users expect, 1) there are exceptions to this,
and 2) there is much more room for integration between processes
than has been exploited up to now.
As an example of (1), take the monitoring system here at the LABEL.
It can switch between
- 8 discrete channels,
- various AMB modes,
- stereo via two discrete speakers,
- stereo via virtual AMB speakers,
- 5.1
- ...
and for all of these the source signals can come from
- the local (linux) machine
- the MAC
- the hardware mixer.
Future versions may also include room correction processing.
I wouldn't want this setup to be part of a session in a single integrated
production app, or even part of Jack Session It has nothing to do with
any project and should not be copied if a project is moved to another
environment. It's just part of the studio infrastructure, at least as far
as a typical user is concerned.
If there is one fundamental change I'd make to any Jack-like system if I
would design it now, it would be to make ports persistent - they exist
even if the app they are associated with does not run. Similar to the
fact that the analog (to a patchbay) and digital (to an ADAT/MADI matrix)
connections of the hardware mixer here exists even if it is switched off.
This in turn encourages fixed or at least semi-permanent port wiring,
with most of the flexibility being provided by the applications, which
would be able to use any port for any function, as is the case for the
mixer app that I'm developing.
Having a semi-permanent set of endpoints and connections greatly
facilitates setting up and managing sessions. And it does not make some
desirable forms of integration impossible. For example there is nothing
that would stop e.g. my mixer app to read an Ardour session file and set
up itself according to the track list, including setting the channel
labels on the mixer.
(BTW it would be great if Ardour would provide raw track ouputs)
Ciao,
--
FA
SaveAndQuit (without Quit only) is not so bad, as
it appears
initially. Actually I seem to like the idea of this simplification.
Although one has to get used to it.
What I'm really missing is SaveAndClose (without application Quit !).
Restarting all applications for changing a session doesn't appear
practical.
i feel that if you spend too long reasoning about this, you will
conclude, as I have, that JACK was actually a mistake (at least in
terms of the basic framework in which to glue together different
things processing data streams). the absence of a plugin API that was
likely to be adopted by all/most developers back in 2000 is what gave
rise to this situation. there's a limit to how far you can push the
usability of a "DAW" built out of N independent processes, each one
running code developed by different developers with no awareness of
the others. the limit is, thankfully, not too primitive, but its also
not far enough out to be able to pretend that JACK + N>1 clients is
actually functionally equivalent to a single host + plugins, at least
not in terms of state management.
8:59 p.m.
On Mon, Jul 04, 2011 at 12:33:18PM -0400, Paul Davis wrote:
On Mon, Jul 4, 2011 at 10:18 AM, Fons Adriaensen
<fons(a)linuxaudio.org> wrote:
OK, let me rephrase that: it would be great is Ardour could be run
without the mixer, just providing the raw track outputs. :-)
--
FA
(BTW it would be great if Ardour would provide
raw track ouputs)
why not just use a prefader send. set up a track template and then
create all your new tracks with it?
3 Jul
3 Jul
10:14 p.m.
On Sun, Jul 03, 2011 at 12:32:53PM -0400, Paul Davis wrote:
sure, which right now is not a separate function at
all, but merely a
branch of the "finish" function. not exactly a huge amount of work to
split it out, but indicative of the complete (and understandable)
design assumption "there's no way to get here except via the GUI".
otoh, you're right, in the sense that quit-WITH-save is even more
complex, and faces all the same issues with threading etc, only more
so because it actually has data to save etc. etc.
'Save' is also available from the Session menu, so I assume
it is a separate function. Then all you need for 'Quit-
without-save' is to skip it, which means one if().
Quite unrelated to all of this, I do have a question
about Ardour's 'Save' semantics.
There are:
(1) 'Save'
(2) 'Save as'
(3) 'Snapshot'
and
(4) 'Periodic safety backups' (option)
and
(5) the 'save' as performed by 'Quit' or closing the main
window, in case "Save and quit" is selected from the dialog.
How do they all interact ? I could possibly find out with
some hours of experimentation, but I assume this has been
defined (and maybe documented) somehow.
In particular:
- Is there any difference between (2) and (3) except that
the one suggests a name and the other doesn't ? For both
the dialog says 'Name of New Snapshot'.
- After (2) or (3) what does (1) do ? Overwrite the last
snapshot, or use the original session name ?
- After (2) or (3) what does (4) do ?
- After (2) or (3) what does (5) do ?
This matters a lot if starting from a the same session you
make different versions of it, e.g. a stereo mix, a surround
mix, and 'tapes' for a live performance (in particular this
one tends to be very differerent).
Or put otherwise, is a snapshot made by (2) or (3) guaranteed
not to modified later by (1), (4), (5), or not ?
Thanks in advance for clarifying this !
--
FA
10:20 p.m.
On Sun, Jul 3, 2011 at 4:14 PM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
Quite unrelated to all of this, I do have a question
about Ardour's 'Save' semantics.
wrong context, but OK ...
There are:
(1) 'Save'
(2) 'Save as'
(3) 'Snapshot'
and
(4) 'Periodic safety backups' (option)
and
(5) the 'save' as performed by 'Quit' or closing the main
window, in case "Save and quit" is selected from the dialog.
How do they all interact ? I could possibly find out with
some hours of experimentation, but I assume this has been
defined (and maybe documented) somehow.
In particular:
- Is there any difference between (2) and (3) except that
the one suggests a name and the other doesn't ? For both
the dialog says 'Name of New Snapshot'.
They both store session state in a file with a different basename than
the main session file. "Save as" additionally switches the current
"name" of the session to the newly chosen name, so that all future (1)
saves will be the new files. "Snapshot" does not do this, so that all
future (1) saves will continue to be to the normal, default session
file.
(4) saves the current session name (as possibly modified by "Save as")
.ardour.bak. This file exists purely for the use of the skilled user.
Ardour does not load it, check for its existence, etc, etc.
(5) is the same as (1).
Or put otherwise, is a snapshot made by (2) or (3)
guaranteed
not to modified later by (1), (4), (5), or not ?
a snapshot made by (3) will not be modified by 1, 2, 4 or 5. a
"snapshot" made by (2) will be modified by subsequent 1 or 5.
there is another potential saved state too, but you don't need to know
about that :)
--p
11:06 p.m.
On Sun, Jul 03, 2011 at 04:20:34PM -0400, Paul Davis wrote:
a snapshot made by (3) will not be modified by 1, 2, 4
or 5. a
"snapshot" made by (2) will be modified by subsequent 1 or 5.
Many thanks, this was what I suspected and hoped for :-)
Maybe the text in the dialogs for (2) and (3) should be
modified to reflect this (rather essential) difference,
currently they are the same.
there is another potential saved state too, but you
don't need to know
about that :)
I want to know all there is to know !
Ciao,
--
FA
10:20 p.m.
On 3 July 2011 21:14, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Sun, Jul 03, 2011 at 12:32:53PM -0400, Paul Davis
wrote:
Asking the questions the rest of us assumed not knowing the answers to
was a result of lesser intelligence!
sure, which right now is not a separate function
at all, but merely a
branch of the "finish" function. not exactly a huge amount of work to
split it out, but indicative of the complete (and understandable)
design assumption "there's no way to get here except via the GUI".
otoh, you're right, in the sense that quit-WITH-save is even more
complex, and faces all the same issues with threading etc, only more
so because it actually has data to save etc. etc.
'Save' is also available from the Session menu, so I assume
it is a separate function. Then all you need for 'Quit-
without-save' is to skip it, which means one if().
Quite unrelated to all of this, I do have a question
about Ardour's 'Save' semantics.
There are:
(1) 'Save'
(2) 'Save as'
(3) 'Snapshot'
and
(4) 'Periodic safety backups' (option)
and
(5) the 'save' as performed by 'Quit' or closing the main
window, in case "Save and quit" is selected from the dialog.
How do they all interact ? I could possibly find out with
some hours of experimentation, but I assume this has been
defined (and maybe documented) somehow.
In particular:
- Is there any difference between (2) and (3) except that
the one suggests a name and the other doesn't ? For both
the dialog says 'Name of New Snapshot'.
- After (2) or (3) what does (1) do ? Overwrite the last
snapshot, or use the original session name ?
- After (2) or (3) what does (4) do ?
- After (2) or (3) what does (5) do ?
This matters a lot if starting from a the same session you
make different versions of it, e.g. a stereo mix, a surround
mix, and 'tapes' for a live performance (in particular this
one tends to be very differerent).
Or put otherwise, is a snapshot made by (2) or (3) guaranteed
not to modified later by (1), (4), (5), or not ?
Thanks in advance for clarifying this !
10 Jul
10 Jul
5:08 p.m.
On 07/03/2011 12:27 AM, Fons Adriaensen wrote:
On Sat, Jul 02, 2011 at 11:02:27PM +0200, rosea
grammostola wrote:
After spending a week using JackSession, I don't think a
quit-without-save option should be a 'showstopper' here Fons. Especially
because JackSession makes working with JACK so much easier. Better to
have JackSession without a quit-without-save option, then no JackSession
at all.
My 2 cents
\r
Next thing what would be good to have imo is a
good software mixer with
JackSession support. Unfortunately non-mixer is not a good candidate
afaik, cause it changes port names. I don't know if Fons is still busy
with his mixer and if he has explored and made up his mind about the
actual implementation of the JackSession API already.
As to Jack Session support,
I won't even consider it as long
as it doesn't support quit-without-save. The rationale for not
supporting this is IMNSHO completely bogus. I just can't imagine
any app that a) can't do this, and b) can't be modified easily
to do it. 'Easily' here means requiring a fraction of the effort
to support Jack Session at all. I've got some other gripes with
Jack Session as well, but these have been discussed (or at least
presented) before. 
6:21 p.m.
On 07/10/2011 10:08 AM, rosea grammostola wrote:
After spending a week using JackSession, I don't
think a
quit-without-save option should be a 'showstopper' here Fons. Especially
because JackSession makes working with JACK so much easier. Better to
have JackSession without a quit-without-save option, then no JackSession
at all.
Actually, I've had the opposite impression... quit-without-save is a
total PITA and actually causes data corruption for me. :-/ ("Oops... I
forgot to save as a bogus session before hitting `Quit`.")
-gabriel
6:33 p.m.
2011/7/10 rosea grammostola <rosea.grammostola(a)gmail.com>om>:
On 07/03/2011 12:27 AM, Fons Adriaensen wrote:
>
>
> As to Jack Session support, I won't even consider it as long
> as it doesn't support quit-without-save.
> The rationale for not supporting this is IMNSHO completely bogus.
After playing around with it, I'm with you here. It should have
quit-without-save and a few more improvements.
> I've got some other gripes with
> Jack Session as well, but these have been discussed (or at least
> presented) before.
>
Looks like I missed that discussion.
I think Torben Hohn did very well, introducing jack-session,
it's the way to go, but I think too, it's not mature.
I've prepared a proposal that tries to improve some parts of jack-session,
without making it much more complicated.
Everyone is welcome, to add his ideas and opinion.
http://wiki.linuxaudio.org/wiki/user/emrum/jack_session_2_draft
Better to have JackSession without a
quit-without-save option, then no JackSession at all.
Agreed.
--
E.R.
7:43 p.m.
On 07/10/2011 06:33 PM, Emanuel Rumpf wrote:
2011/7/10 rosea
grammostola<rosea.grammostola(a)gmail.com>om>:
Good job. I added
some comments.
Regards,
\r
On 07/03/2011 12:27 AM, Fons Adriaensen wrote:
>
> As to Jack Session support, I won't even consider it as long
> as it doesn't support quit-without-save.
> The rationale for not supporting this is IMNSHO completely bogus.
After
playing around with it, I'm with you here. It should have
quit-without-save and a few more improvements.
> I've got some other gripes with
> Jack Session as well, but these have been discussed (or at least
> presented) before.
>
Looks like I missed that discussion.
I think Torben Hohn did very well, introducing jack-session,
it's the way to go, but I think too, it's not mature.
I've prepared a proposal that tries to improve some parts of jack-session,
without making it much more complicated.
Everyone is welcome, to add his ideas and opinion.
http://wiki.linuxaudio.org/wiki/user/emrum/jack_session_2_draft
11 Jul
11 Jul
12:21 a.m.
On Sun, 10 Jul 2011 19:43:53 +0200
rosea grammostola <rosea.grammostola(a)gmail.com> wrote:
On 07/10/2011 06:33 PM, Emanuel Rumpf wrote:
just wanted to notify that one of the "additional ideas" is asking
support for multiple sessions, while one of Emanuel's
"conclusions" (first bulleted list, third item) says that this is now
possible but should actually not be, as it could be an error-source.
cheers
renato
2011/7/10 rosea
grammostola<rosea.grammostola(a)gmail.com>om>:
Good job. I added
some comments.
On 07/03/2011 12:27 AM, Fons Adriaensen wrote:
>
> As to Jack Session support, I won't even consider it as long
> as it doesn't support quit-without-save.
> The rationale for not supporting this is IMNSHO completely bogus.
After
playing around with it, I'm with you here. It should have
quit-without-save and a few more improvements.
> I've got some other gripes with
> Jack Session as well, but these have been discussed (or at least
> presented) before.
>
Looks like I missed that discussion.
I think Torben Hohn did very well, introducing jack-session,
it's the way to go, but I think too, it's not mature.
I've prepared a proposal that tries to improve some parts of
jack-session, without making it much more complicated.
Everyone is welcome, to add his ideas and opinion.
http://wiki.linuxaudio.org/wiki/user/emrum/jack_session_2_draft
10 Jul
10 Jul
7:52 p.m.
Am Sun, 10 Jul 2011 17:08:32 +0200
schrieb rosea grammostola <rosea.grammostola(a)gmail.com>om>:
On 07/03/2011 12:27 AM, Fons Adriaensen wrote:
agree. i use jack-session since two weeks. and now i know for sure,
that i never again will miss it!!!
whatever, i think it makes more sense to support jack-session with a positive
feedback, as endless more or less destructive discussions about some details
to challenge the whole thing.
IMO, if more jack applications will implement it, and more users will work with it,
features requests or improvement requests will make clear in which direction
the session management will run. and than, maybe there a answer which save
or even not save function makes sense or not.
greetings
wolke
On Sat, Jul 02, 2011 at 11:02:27PM +0200, rosea
grammostola wrote:
After spending a week using JackSession, I don't think a
quit-without-save option should be a 'showstopper' here Fons. Especially
because JackSession makes working with JACK so much easier. Better to
have JackSession without a quit-without-save option, then no JackSession
at all. Next thing what would be good to have imo is a
good software mixer with
JackSession support. Unfortunately non-mixer is not a good candidate
afaik, cause it changes port names. I don't know if Fons is still busy
with his mixer and if he has explored and made up his mind about the
actual implementation of the JackSession API already.
As to Jack Session support,
I won't even consider it as long
as it doesn't support quit-without-save. The rationale for not
supporting this is IMNSHO completely bogus. I just can't imagine
any app that a) can't do this, and b) can't be modified easily
to do it. 'Easily' here means requiring a fraction of the effort
to support Jack Session at all. I've got some other gripes with
Jack Session as well, but these have been discussed (or at least
presented) before.
My 2 cents
\r
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
11 Jul
11 Jul
12:16 a.m.
On Sun, Jul 10, 2011 at 05:08:32PM +0200, rosea grammostola wrote:
After spending a week using JackSession, I don't
think a
quit-without-save option should be a 'showstopper' here Fons. Especially
because JackSession makes working with JACK so much easier. Better to
have JackSession without a quit-without-save option, then no JackSession
at all.
In other circumstances I'd call that a pragmatic tradeoff.
But since you're not offered the choice it's not even that.
There is no good reason to omit quit-without-save. I regard
any app that doesn't offer it as fundamentally broken, and
the same applies to whatever higher level system controlling
apps.
Ciao,
--
FA
10:49 a.m.
On 07/11/2011 12:16 AM, Fons Adriaensen wrote:
On Sun, Jul 10, 2011 at 05:08:32PM +0200, rosea
grammostola wrote:
I use fluxbox, and this shortcut closes all windows for me (having
qjackctl in the system tray) ;)
Mod4 Shift a :CloseAllWindows
Sorry, but I can't dive in the technical discussion. The only thing I
can say as a user is that I think Torben did a good job so far.
JackSession kills a lot of disadvantages when it comes to working with
JACK, especially when creating music. I do understand that people might
have good reasons for not working on / supporting something they think
is wrong. The question is whether this missing quit-without-save
function makes JackSession wrong enough to not support it, also
considering the obvious benefits Linuxaudio users have when applications
support JackSession.
It might be good if Torben joins the discussion about the good and the
bad and the missing things of JackSession at the moment (see also
message by Emanuel).
Kind regards,
\r
After spending a week using JackSession, I
don't think a
quit-without-save option should be a 'showstopper' here Fons. Especially
because JackSession makes working with JACK so much easier. Better to
have JackSession without a quit-without-save option, then no JackSession
at all.
In other circumstances I'd call that a pragmatic tradeoff.
But since you're not offered the choice it's not even that.
There is no good reason to omit quit-without-save. I regard
any app that doesn't offer it as fundamentally broken, and
the same applies to whatever higher level system controlling
apps.
3 Jul
3 Jul
2:19 a.m.
Am Sat, 02 Jul 2011 23:02:27 +0200
schrieb rosea grammostola <rosea.grammostola(a)gmail.com>om>:
On 07/02/2011 10:40 PM, m.wolkstein(a)gmx.de wrote:
yes the
mixer is the heart of all. and jackmixer is one of the best i ever use
beside the buildin ardour mixer. cant wait for jack session support on it.
a global jack session support sound's like a dream. jack session support is IMO the
KEY
or the next step to make music under linux much more attractive, productive and at least
more creative. one of the main problems is the long time you need to start your lovely
linux audio-system, make connections and try to remember how you can restore the set from
your last cool session and so on. at least i often give up to create music, because the
idea is gone after all this more or less unlikely administrative work.
beside this, sometimes if everything worked as expected and you currently make really
cool music, you become mournful while you are playing. why? because you now it is mostly
not possible to reconstruct the current session to continue this creative process and his
product(nice music). the super-GAU is when you make dozens of connections and your mixer
stop working, and you directly return to your starting point.
ok, this is all off-topic and for sure discussed hundreds of times. but i am often
frustrated to use linux-audio applications because the eat my time without a creative
output. since ~10 years, i only don't give up try working creative with linux-audio
applications, because my big pighead and my unbreakable hope.
g wolke
Am Thu, 30 Jun 2011 11:03:05 +0200
schrieb rosea grammostola<rosea.grammostola(a)gmail.com>om>:
huhu,
i currently finished a simple hydrogen implementation.
callback with:
save session(save the current song file)
save and exit(save and quit hydrogen)
so far so good.
Thanks a lot! I am surprised how fast devs are picking this up.
Phasex,
Hydrogen, Rakarrack ... great work already :)
Next thing what would be good to have imo is a good software mixer with
JackSession support. Unfortunately non-mixer is not a good candidate
afaik, cause it changes port names. I don't know if Fons is still busy
with his mixer and if he has explored and made up his mind about the
actual implementation of the JackSession API already. Otherwise Jack
Audio Mixer might be a good candidate maybe: http://home.gna.org/jackmixer/ but i
didn't agree to save the application data into the jack-session folder!
imo, this is dangerous because you can lost all data very quick. mainly if you
overwrite a session. also people like me, which plays often improvised
music-sessions, will create tons of sessions folders with duplicated data.
that's why i prefer the h2 implementation with absolute filenames. so currently h2
don't use the ${SESSION_DIR} prefix to store the song files.
Qjackctl 0.3.8
has the possibility to use 'versioning', it makes backups
of the old folder when you overwrite it.
I wonder how much space those folders take in general and if that space
is really a problem normally.
Would be good if Torben (and/ or Rui) could comment on this.
checkout hydrogen trunk to get it.
if jack/session.h is available on your system, hydrogen compile by default with jack
session support.
Regards,
\r
lg wolke
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev Linux Audio Developer,
May I make a feature request here for your Linuxaudio application(s)?
Could you please add JackSession support? It makes working with JACK
standalone applications a lot more user friendly. There are some apps
who support it already and they work fine, like Yoshimi, Qtractor,
Pianoteq, Ghostess, Guitarix, Jack-Rack, Ardour3, Bristol, Seq24, Jalv,
Ingen, Connie, Specimen and probably more.
It is possible to use applications without JackSession-support in a
session (via so called infra clients), it starts the applications, make
the connections, but doesn't save the state. So obviously it would be
far more useful if those applications would get JackSession-support also.
Qjackctl is able to work as Session Manager, so is Pyjacksm (and likely
Patchage in the future).
According to comments on IRC by Paul Davis, it's very easy to add
JackSession support to your application.
"Its really easy, just handle 1 more callback from the server. Torben's
walkthrough shows what is necessary."
Torben's walktrough:
http://trac.jackaudio.org/wiki/WalkThrough/Dev/JackSession
Thanks in advance,
\r
_______________________________________________
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
11:58 a.m.
On 07/03/2011 02:19 AM, m.wolkstein(a)gmx.de wrote:
Next to a software mixer, LinuxSampler should work with JackSession
support. I am not sure if it's possible to patch LinuxSampler or we have
to use it as a client without a state (infra client).
Next thing what would be good to have imo is a
good software mixer with
JackSession support. Unfortunately non-mixer is not a good candidate
afaik, cause it changes port names. I don't know if Fons is still busy
with his mixer and if he has explored and made up his mind about the
actual implementation of the JackSession API already. Otherwise Jack
Audio Mixer might be a good candidate maybe: http://home.gna.org/jackmixer/
yes
the mixer is the heart of all. and jackmixer is one of the best i ever use
beside the buildin ardour mixer. cant wait for jack session support on it. a global jack session support sound's like a
dream. jack session support is IMO the KEY
or the next step to make music under linux much more attractive, productive and at least
more creative. one of the main problems is the long time you need to start your lovely
linux audio-system, make connections and try to remember how you can restore the set
from
your last cool session and so on. at least i often give up to create music, because the
idea is gone after all this more or less unlikely administrative work.
beside this, sometimes if everything worked as expected and you currently make really
cool music, you become mournful while you are playing. why? because you now it is mostly
not possible to reconstruct the current session to continue this creative process and
his
product(nice music). the super-GAU is when you make dozens of connections and your mixer
stop working, and you directly return to your starting point.
ok, this is all off-topic and for sure discussed hundreds of times. but i am often
frustrated to use linux-audio applications because the eat my time without a creative
output. since ~10 years, i only don't give up try working creative with linux-audio
applications, because my big pighead and my unbreakable hope.
Yes, would be really
great if JackSession will adopted in the world of
Linuxaudio in a good and broad way. So far so good! :)
Regards,
\r
12:50 p.m.
On 07/03/2011 11:58 AM, rosea grammostola wrote:
On 07/03/2011 02:19 AM, m.wolkstein(a)gmx.de wrote:
It's not likely to happen soon. The maintainer of jack_mixer
(Jack Audio
Mixer) has not much free time left. If someone else could provide the
patch, that would be awesome.
Regards,
\r
Next thing what would be good to have imo is a
good software mixer with
JackSession support. Unfortunately non-mixer is not a good candidate
afaik, cause it changes port names. I don't know if Fons is still busy
with his mixer and if he has explored and made up his mind about the
actual implementation of the JackSession API already. Otherwise Jack
Audio Mixer might be a good candidate maybe:
http://home.gna.org/jackmixer/
yes the mixer is the heart of all. and jackmixer is
one of the best i
ever use
beside the buildin ardour mixer. cant wait for jack session support
on it.
9:44 a.m.
2011/7/2 m.wolkstein(a)gmx.de <m.wolkstein(a)gmx.de>de>:
but i didn't agree to save the application data into the jack-session folder!
You really should make that a user option !
One of the main points of a session is, to keep data *together*.
So everything belonging to one session goes to one single folder.
If you need a backup, make the application save to a different folder
*additionally*,
but don't skip saving and restoring from the session folder.
... also people like me, which plays often improvised
music-sessions, will
create tons of sessions folders with duplicated data.
Turn off the 'versioned' option in qjackctl.
Delete old sessions regularly.
--
E.R.
11:10 a.m.
On 07/03/2011 09:44 AM, Emanuel Rumpf wrote:
2011/7/2
m.wolkstein@gmx.de<m.wolkstein@gmx.de>:
Yep, I do agree with this. It starts to get complex again if all apps
will have there own ways of saving. No problem if there is a additional
way provided.
but i didn't agree to save the application data into the jack-session folder!
You really should make that a user option ! One of the main points of a session is, to keep data
*together*.
So everything belonging to one session goes to one single folder.
If you need a backup, make the application save to a different folder
*additionally*,
but don't skip saving and restoring from the session folder.
... also people like me, which plays often
improvised music-sessions, will
create tons of sessions folders with duplicated data.
Turn off the 'versioned' option in qjackctl.
Delete old sessions regularly.
2:10 p.m.
Am Sun, 03 Jul 2011 11:10:08 +0200
schrieb rosea grammostola <rosea.grammostola(a)gmail.com>om>:
On 07/03/2011 09:44 AM, Emanuel Rumpf wrote:
Yes sounds good, if i had time i will include a corresponding config option.
g wolke
2011/7/2
m.wolkstein@gmx.de<m.wolkstein@gmx.de>:
Yep, I do agree with this. It starts to get complex again if all apps
will have there own ways of saving. No problem if there is a additional
way provided.
but i didn't agree to save the application data into the jack-session folder!
You really should make that a user option ! One of the main points of a session is, to keep
data *together*.
So everything belonging to one session goes to one single folder.
If you need a backup, make the application save to a different folder
*additionally*,
but don't skip saving and restoring from the session folder.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev ... also people like me, which plays often
improvised music-sessions, will
create tons of sessions folders with duplicated data.
Turn off the 'versioned' option in qjackctl.
Delete old sessions regularly.
5 Jul
5 Jul
12:15 a.m.
Am Sun, 3 Jul 2011 14:10:49 +0200
schrieb "m.wolkstein(a)gmx.de" <m.wolkstein(a)gmx.de>de>:
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Am Sun, 03 Jul 2011 11:10:08 +0200
schrieb rosea grammostola <rosea.grammostola(a)gmail.com>om>:
Done, checkout hydrogen trunk >=rev2248.
To save data into jack-session directory enable the checkbox
"tools->preferences->general-tab->save song file in jack session
directory".
two things left.
1. i do all my tests against jack0.120.1. not against jack1.9.7.
2. h2 communicate via event-queue from core to gui. so it is not really possible
to wait, while a jsm callback call, for an Hydrogen QFileDialog.
this happens only if hydrogen is running with an empty/new file.
than hydrogen need to open a QFileDilog to get some informations(songname) from user.
whatever in this case after closing the QFileDialog h2 will open an QMessageBox
which inform the user to repeat the save procedure par jack session manager.
not the so beautifully but currently i have no good idea how i can solve this without
dirty hacks.
g wolke
On 07/03/2011 09:44 AM, Emanuel Rumpf wrote:
Yes sounds good, if i had time i will include a corresponding config option.
g wolke 2011/7/2
m.wolkstein@gmx.de<m.wolkstein@gmx.de>:
Yep, I do agree with this. It starts to get complex again if all apps
will have there own ways of saving. No problem if there is a additional
way provided.
but i didn't agree to save the application data into the jack-session folder!
You really should make that a user option ! One of the main points of a session is, to keep
data *together*.
So everything belonging to one session goes to one single folder.
If you need a backup, make the application save to a different folder
*additionally*,
but don't skip saving and restoring from the session folder.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev ... also people like me, which plays often
improvised music-sessions, will
create tons of sessions folders with duplicated data.
Turn off the 'versioned' option in qjackctl.
Delete old sessions regularly.
12:37 p.m.
On Tue, Jul 5, 2011 at 12:14 AM, m.wolkstein(a)gmx.de <m.wolkstein(a)gmx.de>wrote;wrote:
Am Sun, 3 Jul 2011 14:10:49 +0200
Saving the data in the jack session directory as default and saving outside
that folder as user option, seems to be more logical and better to me. Users
of JackSession will expect it to be saved in the JackSession folder, just
like all the other apps do.
\r
Yes sounds good, if i had time i will include a
corresponding config
option.
g wolke
Done, checkout hydrogen trunk >=rev2248.
To save data into jack-session directory enable the checkbox
"tools->preferences->general-tab->save song file in jack session
directory".
two things left.
1. i do all my tests against jack0.120.1. not against jack1.9.7.
2. h2 communicate via event-queue from core to gui. so it is not really
possible
to wait, while a jsm callback call, for an Hydrogen QFileDialog.
this happens only if hydrogen is running with an empty/new file.
than hydrogen need to open a QFileDilog to get some
informations(songname) from user.
whatever in this case after closing the QFileDialog h2 will open an
QMessageBox
which inform the user to repeat the save procedure par jack session
manager.
not the so beautifully but currently i have no good idea how i can solve
this without
dirty hacks.
g wolke
_______________________________________________
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
>
> > One of the main points of a session is, to keep data *together*.
> > So everything belonging to one session goes to one single folder.
> > If you need a backup, make the application save to a different folder
> > *additionally*,
> > but don't skip saving and restoring from the session folder.
> >
> >> ... also people like me, which plays often improvised
music-sessions, will
> create tons of sessions folders with duplicated
data.
>
Turn off the 'versioned' option in qjackctl.
Delete old sessions regularly.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
4673
days inactive
4684
days old
linux-audio-dev@lists.linuxaudio.org
61 comments
16 participants
participants (16)
-
Dan Muresan -
Dave Phillips -
David Robillard -
Devin Anderson -
Emanuel Rumpf -
Folderol -
Fons Adriaensen -
Gabriel Beddingfield -
James Morris -
Jörn Nettingsmeier -
m.wolkstein＠gmx.de -
michael noble -
Paul Davis -
Renato -
Robin Gareus -
rosea grammostola