jack_session

What other apps and distros do you use to round out your studio?

Moderators: MattKingUSA, khz

studio32

jack_session

Post by studio32 »

Hi,

I played a bit with jack1 svn on debian (./configure --prefix=/usr) and jack_session, qjackctl svn and jack-rack from git.

http://trac.jackaudio.org/wiki/WalkThro ... ck_session

all though in early development, it works :) I tried pyjacksm and qjackctl, not finished, some bugs, but looking good! :)
User avatar
spm_gl
Established Member
Posts: 358
Joined: Wed Apr 22, 2009 7:58 am
Location: Spreewald, Germany
Contact:

Re: jack_session

Post by spm_gl »

Lash, Ladish and now jack_session. Looks like a battle of the session managers is about to happen.
Can you give us a comparision?
--- Spreemusik ---
Jan Fuchsmann, Audio Engineer
Check our blog at http://www.spreemusik.com/blog
jaycapela
Established Member
Posts: 20
Joined: Thu Aug 19, 2010 8:19 am

Re: jack_session

Post by jaycapela »

Does jack_session support other apps outside of the short list they have on their wiki, or is it necessary for apps to be patched to work with jack_session? One thing I really love about Ladish is that it supports everything but the kitchen sink.
mauser
Established Member
Posts: 145
Joined: Wed Oct 08, 2008 3:58 pm
Has thanked: 1 time
Been thanked: 7 times

Re: jack_session

Post by mauser »

spm_gl wrote:Lash, Ladish and now jack_session. Looks like a battle of the session managers is about to happen.
Can you give us a comparision?
That would be great! Even for us developers it is hard to "follow" all of these trends, especially if one doesn't use any of them :) As i understood it in the early jack_session discussions, it is more an API then a complete session management "solution".
It was for us no problem to include ladish support in hydrogen (the level which saves the state when a signal arrives, don't remember how that was called exactly..), but it will be hard to maintain three different architechtures over the time. What about lash nowadays? Is anybody here using it often?
jaycapela
Established Member
Posts: 20
Joined: Thu Aug 19, 2010 8:19 am

Re: jack_session

Post by jaycapela »

mauser wrote:
spm_gl wrote:Lash, Ladish and now jack_session. Looks like a battle of the session managers is about to happen.
Can you give us a comparision?
That would be great! Even for us developers it is hard to "follow" all of these trends, especially if one doesn't use any of them :) As i understood it in the early jack_session discussions, it is more an API then a complete session management "solution".
It was for us no problem to include ladish support in hydrogen (the level which saves the state when a signal arrives, don't remember how that was called exactly..), but it will be hard to maintain three different architechtures over the time. What about lash nowadays? Is anybody here using it often?
I really wanted lash to work for me when I first started messing around with Linux audio, but I never really understood how to start and save sessions, and I couldn't find documentation anywhere. I wonder if lash is just broken on my Arch Linux install, because lash_simple_client just hangs and doesn't appear at all in lash_control. So I use ladish from the AUR repo because it_just_works.

Having three different architectures does seem pretty messy. Why can't they just merge? They're all pretty much aiming for the same goal.
brummer

Re: jack_session

Post by brummer »

Isn't lash pretty dead and already merged in ladish ?
So we come to 2 different solutions, ladish and jack_session. Ladish use Dbus, it is real simple for a developer to include support for ladish, but not all ppl are happy with the Dbus involvement and it wouldn't work with jack1.
jack_session needs a bit more work to include prop in a application, it leaves the "work task" to the app, but it could be used without Dbus, I guess that's what ppl (at least me :) ) attract to use it. For now it only work with jack1, but it "could" once work with jack2 also.
studio32

Re: jack_session

Post by studio32 »

There are two major and active players atm. LASH didn't became a success (developments seems to stopped, all though it's not officially pronounced dead afaik), so one co-writer of LASH started his own version to work out his vision how it could be better (LADISH). Others also saw that LASH didn't satisfy, but they didn't agree with the LADISH approach (which uses jackdbus, which is only in JACK2, so a JACK discussion has some relation with this too).

Anyhow the main JACK1 dev(s) started his own project, jack_session. Jack_session API is integrated into JACK1 and JACK2 (soon). The advantage of jack_session is that apps with build in jack_session support, are automatically build with the jack_session support when build against JACK (Linux distro packaging teams don't have to do anything to build the app WITH session support). Also a GUI for jack_session is integrated into qjackctl (svn) (it also has it's own gui (see first post)). It's expected that versions of JACK 1 and 2, with jack_session support will be released soon.

For both session managers, apps needs some extra code to support it (clear examples are on the wikis, and both teams are very willing to help you with the code***).

The advantage of LADISH is that it also supports apps without session support. See http://ladish.org/wiki/levels (L0). In LADISH svn there is L1 atm and will be released at the end of the year probably. Apps like Rosegarden (svn), Yoshimi, Jack-mixer, Hydrogen (svn), Bristol already have L1 support for example and it looks like LADISH is added into Debian soon. In the future Ladish L2 supports also apps with LASH and jack_session support. No jackdbus in JACK1, so no LADISH for JACK1.

In my view, jack_session seems to have a more minimal approach. It supports only apps with jack_session support. If you want a minimal and clean system, jack_session suites better maybe. LADISH approach is more sophisticated, in the sense that it seems to get more features in the future, like rooms, position of the apps on the Desktop are saved etc. But it's pretty hard to tell the differences and to say at what point which system is better (future will tell). Also the plans of LADISH are more public and clear (to me) then the plans for jack_session.

***
http://ladish.org/ (explanation and example code | patches are on the wiki)
http://trac.jackaudio.org/wiki/WalkThro ... ck_session
http://trac.jackaudio.org/wiki/WalkThro ... ackSession
(explanation and example code | patches are on the wiki)
nils
Established Member
Posts: 537
Joined: Wed Oct 22, 2008 9:05 pm
Has thanked: 35 times
Been thanked: 94 times
Contact:

Re: jack_session

Post by nils »

LASH is dead, thats the one thing for sure. If your app still supports it you can safely remove it.

So it really is ladish vs jack_session. In my view jack_session will be the winner in this race. And thats why:

Its important to understand the distinction between the protocoll and a session mananger. Jack_Session is a protocol, the session mananger is called pyjacksm. Ladish is not that transparent and mixes terms, but it speaks in "level" which could be considered a protocol.

L0 is no protocol, so that has nothing to do with ladish or jack_sesssion but it merely a tool to save command line with its parameters. You have to enter them by hand before starting.

L1 are POSIX messages. This is the current protocoll for ladish and this is the state you have to compare to jack_session.

L2 and L3 are future talk and nowhere to even experimental state so we can just forget them. Since the talk about ladish is mostly "what could be possible with L2 and L3" all this becomes just talk.

Now, why I think jack_session is better:

1) Its in JACK, both versions. Contrary to common believe Jack2 is not the "better and future" jack but just a C++ version. Jack1 and Jack2 currently exists beneath each other and only the name hints that there is something new and old. In my eyes Jack1 is still the better implementation and I expect Jack2 to vanish in the future.

2) Maybe some apps already support Ladish, but some support jack_session, too. Its only a handful and both protocols are very easy to implement, so it absolutly has no meaning how many apps are currently support experimental session protocols. Maybe an important fact is that Ardour will not support Ladish, not yet and not in the future. Patches have been already rejected because of the fundamental design flaws in ladish.

3)Now it becomes technical: Ladish misuses POSIX messages which is a thing that cannot be tolerated (as I mentioned before: Any talk about L2 and L3 and dbus is just dreaming right now). First if the client already uses those messages ladish will not work anymore. For example JACK itself already uses the same posix messages, a conflict at such low level! Then its absolutly not portable. Ladish just ignores anything except linux, which is not that bad in reality, but its bad style. You never know what will happen in the future, with Haiku or ReactOS. Even now Ladish is not able to work in Windows while Jack Session is.

4)Ladish is not able to add already running apps to a session, jack_session is.

There are more, but I think you get the point.
Currently its ladish with no protocol or a wrong one against a clean one which will be distributed with JACK automatically and is portable. Its like TCP/IP, the minimal design is better because you can do more in the end.
studio32

Re: jack_session

Post by studio32 »

NilsGey wrote:LASH is dead, thats the one thing for sure. If your app still supports it you can safely remove it.
I wouldn't do that, because of the fact that Ladish aims to support it in the future.
L0 is no protocol, so that has nothing to do with ladish or jack_sesssion but it merely a tool to save command line with its parameters. You have to enter them by hand before starting.
advantage = it makes working with Linux audio already pretty much more easy. And it saves time.

anyway, you have a clear position and strong opinion against LADISH. Which is no problem to me. But you leave also not many room for discussion or different opinions or different ways to do things in my opinion. Maybe because you are an expert in this area and are pretty sure you're right. But also then, you could be wrong. Maybe you should add a bit more space for that ;)

Many people are also saying that the Windows approach is wrong, but many users are happily using Windows and/ or enjoying the easiness of it. Sometimes it's black and white, sometimes not... Linux audio devs tend to think they are always right and they forget sometimes to listen to the user. They are right many times, not always. JACK1 is not perfect, so it's not strange that people try to improve things or have a different vision towards how the perfect implementation should look like... Also the technical best solution is also not always the best solution for the user, for workflow and / or inspiration of the artist. Perfect or not, the L0 of Ladish made things easier for a lot of people already.

You might be right and I might favor jack_session above Ladish too (if it's necessary to take a position. BTW I think it's not a bad thing to have Ladish AND jack_session), but I doubt whether this is as black and white as you try to believe us. Future will tell. :)
Last edited by studio32 on Sun Aug 22, 2010 4:12 pm, edited 1 time in total.
User avatar
autostatic
Established Member
Posts: 1994
Joined: Wed Dec 09, 2009 5:26 pm
Location: Beverwijk, The Netherlands
Has thanked: 32 times
Been thanked: 104 times
Contact:

Re: jack_session

Post by autostatic »

I prefer the third session manager: scripts.
All apps support it.
And when reading this thread I will be using it for a long time to come I reckon.
jaycapela
Established Member
Posts: 20
Joined: Thu Aug 19, 2010 8:19 am

Re: jack_session

Post by jaycapela »

AutoStatic, what do you use to save your jackd connections? Do you use the patchbay in qjackctl, manually enter jack_connect commands in your script file, or use something like jack_snapshot?
User avatar
autostatic
Established Member
Posts: 1994
Joined: Wed Dec 09, 2009 5:26 pm
Location: Beverwijk, The Netherlands
Has thanked: 32 times
Been thanked: 104 times
Contact:

Re: jack_session

Post by autostatic »

Hello jaycapela, Qtractor is my main DAW and it saves all connections from and to it in the session file. The rest I add to the script with jack_connect and aconnect.
Pablo
Established Member
Posts: 1274
Joined: Thu Apr 17, 2008 9:57 pm
Been thanked: 3 times

Re: jack_session

Post by Pablo »

Hi,

I made a quick test with jackd 0.119.0, jack_simple_session_client and pyjacksm... I am not able to compile qjackctl from svn right now, but anyway, as a proof of concept it is OK to begin understanding what jack session manager is.

If I understand correctly, unlike ladish where you have to launch the apps with commands from the main user interface (gladish), in jacksm you only need to save / load sessions via the jacksm tray. If patchage supported jack_session it would be similar to gladish, but cleaner, imho. I am sure I am missing something though.

Scripting is OK if you know how to do it and you have, more or less, decided your workflow. Deciding your workflow is the hard part. If only you could save your studio with a click... that would be awesome.

ladish level >=1 and/or jack_session, for every jackified app... I wish the dream came true. Anyway, a lot of devs are doing a great work.. GPL!. Thanks and Hooray for them!

Cheers! Pablo
User avatar
kaimerra
Established Member
Posts: 91
Joined: Sun Jan 04, 2009 9:41 am
Location: Minnesota, USA

Re: jack_session

Post by kaimerra »

NilsGey, you mention that Jack2 is just a Cpp rewrite of Jack1 with dbus. I assumed Jack1 was going away when I read something about Jack2 getting renamed to Jack 1.9.5(not exact here).

Anyways, i am just confused on which jack to use now. Is there a good list of pros/cons of each somewhere? Obviously, from this thread, I can see that jack_session works with jack1 and ladish with jack2.
brummer

Re: jack_session

Post by brummer »

The main difference is that jack2 is written in C++, were jack1 is written in plain C.
The main reason to use jack2 is a better support for Multi Core CPU's.
Post Reply