[Jack-Devel] stepping down

classic Classic list List threaded Threaded
61 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Kjetil Matheussen-2


On Sun, Jan 31, 2016 at 11:10 PM, Paul Davis <[hidden email]> wrote:


On Sun, Jan 31, 2016 at 4:50 PM, Kjetil Matheussen <[hidden email]> wrote:


I meant server options. Driver name, realtime on/off, driver options, timeout, etc.

why does a client want these? it would not contain code to start JACK that required any of this .... unless you're suggesting a different GUI to configure the server in every client, which you're not ...
 

You want to see which options jack has been started with. You want this information
visible in an obvious way. It is both undocumented and flaky to have to
"run ps -Af|grep jackd" or something like that to get this information.


 


I don't anything perfect about jack_lsp popping up a GUI dialog to configure a server. I don't see anything good about a careful constructed GUI application having to deal with the reality of a new dialog being created. this isn't even close to perfect.


But it's better than having different GUIs in every client for configuring jack.

I am fairly confident that what is better for most users is having a well known point of control (e.g. cadence, qjackctl) to start and control JACK,
 
And that's what I'm suggesting. One well known point of control, provided by libjack, which every
client can use, if they want.



 as well as the capability to start the server from scripts etc.

Sure, there's nothing wrong creating a dummy-client that only runs the server, if you need that.

 
 

 
what problem are you actually concerned with fixing? what users does it affect? when?

I think I have listed the problems. The far worst problem is that there
is no proper error response when a driver doesn't start. Especially on Windows,
where qjackctl is quite buggy and portaudio often refuses to start.

Qjackctl arranges to catch all output from the server, which is by far the simplest way to present information to the user, especially in a context where the reasons for failure can be incredibly complex. It might not work as well on Windows as it does on *nix platforms, but I hardly think that this would justify some new mechanism to pass failure information between processes. 


This is so flaky and uncertain. Layers upon layers of software, which all may fail.
The end result is that there is a higher chance for the user to not get the information
he needs, plus the added complexity and frustration. libjack should take care of all this.





_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

[Jack-Devel] libjack vs server [ was Re: stepping down

Patrick Shirkey

On Mon, February 1, 2016 7:39 pm, Kjetil Matheussen wrote:

>
>>
>> I am fairly confident that what is better for most users is having a
>> well
>> known point of control (e.g. cadence, qjackctl) to start and control
>> JACK,
>>
>
> And that's what I'm suggesting. One well known point of control, provided
> by libjack, which every
> client can use, if they want.
>

It's an interesting line of thought.

What happens if the original app that was used to start the jack process
is taken out either by force or error?

The rest of the group needs to have a mechanism for keeping running.

A server solves this problem by keeping jack as a seperate process that is
not dependant on any other process to keep it alive.

Can you expand on how you would solve this with library instead of a server?



--
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: libjack vs server [ was Re: stepping down

Kjetil Matheussen-2


On Mon, Feb 1, 2016 at 10:19 AM, Patrick Shirkey <[hidden email]> wrote:

On Mon, February 1, 2016 7:39 pm, Kjetil Matheussen wrote:
>
>>
>> I am fairly confident that what is better for most users is having a
>> well
>> known point of control (e.g. cadence, qjackctl) to start and control
>> JACK,
>>
>
> And that's what I'm suggesting. One well known point of control, provided
> by libjack, which every
> client can use, if they want.
>

It's an interesting line of thought.

What happens if the original app that was used to start the jack process
is taken out either by force or error?

The rest of the group needs to have a mechanism for keeping running.

A server solves this problem by keeping jack as a seperate process that is
not dependant on any other process to keep it alive.

Can you expand on how you would solve this with library instead of a server?

 
Yes, that's an interesting programming challenge. It's probably very hard
to make this work decently, but the thing is that if you want to run several
clients at the same time, you will still have the option of starting a "main client"
first, same way as you run jackd now. What I was replying to in this thread,
was if you want run a DAW, you very often only want to run one client, and
then you don't need to start jackd and qjackctl.




_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: libjack vs server [ was Re: stepping down

Ralf Mardorf
On Mon, 1 Feb 2016 10:26:07 +0100, Kjetil Matheussen wrote:
>What I was replying to in this thread, was if you want run a DAW, you
>very often only want to run one client, and then you don't need to
>start jackd and qjackctl.  

Assumed the DAW requires jackd, as e.g. Qtractor does, then there's the
need to run jackd. However, it's not important for the user, since
Qtractor automatically will start jackd, if it isn't already running.
Indeed, we don't have to launch jackd, but the DAW needs to launch it.
Following audio related Linux mailing lists I doubt that "very often" is
correct. My impression is, that more often people use a DAW not only
with plugins, but with additional software that requires audio and MIDI
sync.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: libjack vs server [ was Re: stepping down

Kjetil Matheussen-2


On Mon, Feb 1, 2016 at 10:38 AM, Ralf Mardorf <[hidden email]> wrote:
On Mon, 1 Feb 2016 10:26:07 +0100, Kjetil Matheussen wrote:
>What I was replying to in this thread, was if you want run a DAW, you
>very often only want to run one client, and then you don't need to
>start jackd and qjackctl.

Assumed the DAW requires jackd, as e.g. Qtractor does, then there's the
need to run jackd. However, it's not important for the user, since
Qtractor automatically will start jackd, if it isn't already running.
Indeed, we don't have to launch jackd, but the DAW needs to launch it.
Following audio related Linux mailing lists I doubt that "very often" is
correct. My impression is, that more often people use a DAW not only
with plugins, but with additional software that requires audio and MIDI
sync.


But if the DAW crashes, would it be any point continuing to run the other clients?
(And by "continue to run" I only mean continue to run the jack callback, the
other clients don't have to crash.)



_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: libjack vs server [ was Re: stepping down

Stéphane Letz
In reply to this post by Kjetil Matheussen-2
>
> A server solves this problem by keeping jack as a seperate process that is
> not dependant on any other process to keep it alive.
>
> Can you expand on how you would solve this with library instead of a server?
>
>  
> Yes, that's an interesting programming challenge. It's probably very hard
> to make this work decently, but the thing is that if you want to run several
> clients at the same time, you will still have the option of starting a "main client"
> first, same way as you run jackd now. What I was replying to in this thread,
> was if you want run a DAW, you very often only want to run one client, and
> then you don't need to start jackd and qjackctl.
>


Before this discussion becomes too crazy… (like :  "let's redesign JACK yet again… but without anyone to ever implement this new/better/fabulous new stuff….)  Kjetil I  would suggest you read this old paper (2009) on JACK2 design, that answers some of your questions :

http://lac.linuxaudio.org/2009/cdm/Thursday/01_Letz/01.pdf

Then I guess the discussion could move on what can be done on a more general level : how to keep JACK1 code base alive ? should we redirect the few developer resource to at least maintain JACK2 code base on Linux, OSX, Windows?  This kind of questions.

Stéphane
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Patrick Shirkey
In reply to this post by Paul Davis

On Sun, January 31, 2016 3:13 am, Paul Davis wrote:

> Sometime in the next two weeks, I will find the time to deal with a
> variety
> of pull requests for JACK 1, update some articles on jackaudio.org
> (notably
> FAQ stuff), and do a new release of JACK 1.
>
> This will be my last work on JACK. The time has come for me to step down
> from my role as "benign dictator (and jack1 maintainer)". There several
> reasons for this:
>
>   * most linux distributions use JACK2 as their default, so JACK1's
> relevance has diminished. I
>     still believe JACK1 to be a superior choice from some technical
> perspectives, but there is
>     no doubt that JACK2's integration with dbus and thus its
> interoperability with PulseAudio
>     has made this the safe and simpler choice for Linux.
>
>  * I really don't have the time to even think about things related to JACK
> these days. It does
>    any future development a disservice to have me as the bottleneck, which
> I effectively am
>    at the moment.
>
>  * Because 110% of my time is spent on Ardour, the fact that Ardour now
> has
> non-JACK
>    audio/MIDI I/O options has diminished the significance of JACK for my
> own work.
>
>  * as the years have gone on, although I am still delighted by the
> technical quality and
>    the conception of JACK, I no longer think that it is a particularly
> good
> idea for most users. There
>    are times when it is useful
>
> I will continue to pay for the hosting of jackaudio.org (even though JACK2
> continues to be distributed, managed and communicated about via other
> channels), although if someone wanted to migrate this to some other more
> communitarian platform, we could look into that.
>
> I would be happy if someone volunteered to step up as maintainer of JACK1.
> It would obviously be even better if someone was willing to take the big
> leap to JACK3, a version that combines all the best parts of JACK1 and
> JACK2, but I think it is more realistic to accept at this point that this
> is not going to happen.
>
> If nobody does step up, then there is a good chance that JACK1 will become
> officially unmaintained. This isn't of much consequence, because once the
> latest pull requests are merged, there won't be any known bugs in the
> code,
> and also because not many people use it anymore. This also means, of
> course, that "maintainer" is not much of a task, should someone feel
> hesitant about taking it on.
>

The end of an era!

A big congratulations to Paul and the Ardour team for getting to the point
where Paul is too busy to work on JACK anymore. That is a great
accomplishment and is due in large part to the original development of
JACK to create a solid foundation for Ardour.

JACK1 is still a very useful part of our toolkit. We routinely use it for
distributed audio processing on a range of machines with many different
versions of Linux. In that environment it seems to be more stable than
JACK2.

It seems that the differences between JACK1 and JACK2 relate to the
intended target use case. JACK2 does a decent job of trying to enable many
consumer friendly tasks and take out some of the pain of doing inter
application audio production. JACK1 handles some heavy lifting scenarios
more effectively than JACK2.

Maybe that is a good direction to continue for the different codebases?

JACK1 - Heavy lift mechanism for high performance Linux platforms
JACK2 - Flexible user friendly solution with cross platform support

I don't see any problem with continuing the split development process in
that regard. Maybe we don't need a single tool to do everything anyway?

I hope that Paul will continue to provide his insight and expertise as
part of the JACK development community.

If he is interested, I nominate Harry Van Haaren as the new official
maintainer for JACK1 codebase. He has proven his skills and commitment and
is a fair and impartial communicator.

Anyone else want to put their hat in?




--
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: libjack vs server [ was Re: stepping down

Ralf Mardorf
In reply to this post by Kjetil Matheussen-2
On Mon, 1 Feb 2016 10:44:29 +0100, Kjetil Matheussen wrote:
>But if the DAW crashes, would it be any point continuing to run the
>other clients?
>(And by "continue to run" I only mean continue to run the jack
>callback, the other clients don't have to crash.)

Assumed in a live situation Ardour sometimes is used as a sequencer to
play Phasex and plugins, but by a keyboard the keyboarder always
manually is playing Yoshimi, then it's important that the keyboarder
could continue playing Yoshimi, assumed Ardour should crash. IOW the
orchestra should continue the opera, even if a string of just one
violin breaks.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: libjack vs server [ was Re: stepping down

Kjetil Matheussen-2


On Mon, Feb 1, 2016 at 10:58 AM, Ralf Mardorf <[hidden email]> wrote:
On Mon, 1 Feb 2016 10:44:29 +0100, Kjetil Matheussen wrote:
>But if the DAW crashes, would it be any point continuing to run the
>other clients?
>(And by "continue to run" I only mean continue to run the jack
>callback, the other clients don't have to crash.)

Assumed in a live situation Ardour sometimes is used as a sequencer to
play Phasex and plugins, but by a keyboard the keyboarder always
manually is playing Yoshimi, then it's important that the keyboarder
could continue playing Yoshimi, assumed Ardour should crash. IOW the
orchestra should continue the opera, even if a string of just one
violin breaks.


Well, in that situation, it would probably make sense to start a main client first.


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: libjack vs server [ was Re: stepping down

Kjetil Matheussen-2
In reply to this post by Stéphane Letz


On Mon, Feb 1, 2016 at 10:46 AM, Stéphane Letz <[hidden email]> wrote:
>
> A server solves this problem by keeping jack as a seperate process that is
> not dependant on any other process to keep it alive.
>
> Can you expand on how you would solve this with library instead of a server?
>
>
> Yes, that's an interesting programming challenge. It's probably very hard
> to make this work decently, but the thing is that if you want to run several
> clients at the same time, you will still have the option of starting a "main client"
> first, same way as you run jackd now. What I was replying to in this thread,
> was if you want run a DAW, you very often only want to run one client, and
> then you don't need to start jackd and qjackctl.
>


Before this discussion becomes too crazy… (like :  "let's redesign JACK yet again… but without anyone to ever implement this new/better/fabulous new stuff….)  Kjetil I  would suggest you read this old paper (2009) on JACK2 design, that answers some of your questions :

http://lac.linuxaudio.org/2009/cdm/Thursday/01_Letz/01.pdf


Both you and Paul have done amazing work which I'm very grateful for.
But I'm not suggesting a redesign here, just a fairly minor change.
Would it be that much work to put jackd into libjack?
That's the first step. I also suggest creating a formally defined api for
error messages so that the clients can show what's going wrong if
a driver fails. I also suggest to rewrite some parts of qjackctl and add it to
the jack packages as external executables that can be launched by libjack.
This modified version of qjackctl will now not be linked to libjack, but instead
communicate with libjack through sockets, just plainly doing GUI operation
for whoever client that needs it. This might be a larger job though, but
probably doable over a couple of weekends or so.


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

John Rigg-16
In reply to this post by Patrick Shirkey
On Mon, Feb 01, 2016 at 08:53:05PM +1100, Patrick Shirkey wrote:

> It seems that the differences between JACK1 and JACK2 relate to the
> intended target use case. JACK2 does a decent job of trying to enable many
> consumer friendly tasks and take out some of the pain of doing inter
> application audio production. JACK1 handles some heavy lifting scenarios
> more effectively than JACK2.
>
> Maybe that is a good direction to continue for the different codebases?
>
> JACK1 - Heavy lift mechanism for high performance Linux platforms
> JACK2 - Flexible user friendly solution with cross platform support

I think that distinction is somewhat arbitrary. Some of us use JACK2 as a
multi-core replacement for JACK1. My own use case typically involves multiple
jack clients, sometimes large numbers of them, and JACK2 usually gives me
better performance on SMP systems. D-bus is actually irrelevant to me.

John
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

John Rigg-16
In reply to this post by Paul Davis
On Sat, Jan 30, 2016 at 11:13:06AM -0500, Paul Davis wrote:
> Sometime in the next two weeks, I will find the time to deal with a variety
> of pull requests for JACK 1, update some articles on jackaudio.org (notably
> FAQ stuff), and do a new release of JACK 1.
>
> This will be my last work on JACK. The time has come for me to step down
> from my role as "benign dictator (and jack1 maintainer)".

Thank you Paul for the great piece of software that is JACK. It played a major
part in enabling me to switch from analogue tape to computer based recording
over a decade ago. Best of luck in your other projects.

John
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Ralf Mardorf
In reply to this post by John Rigg-16
On Mon, 1 Feb 2016 11:07:25 +0000, John Rigg wrote:

>On Mon, Feb 01, 2016 at 08:53:05PM +1100, Patrick Shirkey wrote:
>> It seems that the differences between JACK1 and JACK2 relate to the
>> intended target use case. JACK2 does a decent job of trying to
>> enable many consumer friendly tasks and take out some of the pain of
>> doing inter application audio production. JACK1 handles some heavy
>> lifting scenarios more effectively than JACK2.
>>
>> Maybe that is a good direction to continue for the different
>> codebases?
>>
>> JACK1 - Heavy lift mechanism for high performance Linux platforms
>> JACK2 - Flexible user friendly solution with cross platform support  
>
>I think that distinction is somewhat arbitrary. Some of us use JACK2
>as a multi-core replacement for JACK1. My own use case typically
>involves multiple jack clients, sometimes large numbers of them, and
>JACK2 usually gives me better performance on SMP systems. D-bus is
>actually irrelevant to me.

D-bus is unimportant for me too. I don't know if JACK1 nowadays provide
-Xalsarawmidi or if I still need it this day, but JACK2's -Xalsarawmidi
at least reduced MIDI jitter on my Linux machine, when I needed it,
that's why I used it to get "high performance". For my usage JACK2
isn't more user-friendly than JACK1 is. The reason to prefer JACK2 over
JACK1 could be to get better performance, JACK1 not necessarily is
the better choice for "high performance" and JACK2 not necessarily is
more user-friendly.

Regards,
Ralf
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Patrick Shirkey
In reply to this post by John Rigg-16

On Mon, February 1, 2016 10:07 pm, John Rigg wrote:

> On Mon, Feb 01, 2016 at 08:53:05PM +1100, Patrick Shirkey wrote:
>> It seems that the differences between JACK1 and JACK2 relate to the
>> intended target use case. JACK2 does a decent job of trying to enable
>> many
>> consumer friendly tasks and take out some of the pain of doing inter
>> application audio production. JACK1 handles some heavy lifting scenarios
>> more effectively than JACK2.
>>
>> Maybe that is a good direction to continue for the different codebases?
>>
>> JACK1 - Heavy lift mechanism for high performance Linux platforms
>> JACK2 - Flexible user friendly solution with cross platform support
>
> I think that distinction is somewhat arbitrary. Some of us use JACK2 as a
> multi-core replacement for JACK1. My own use case typically involves
> multiple
> jack clients, sometimes large numbers of them, and JACK2 usually gives me
> better performance on SMP systems. D-bus is actually irrelevant to me.
>

Maybe it is the difference in the way we are using JACK over here.
Particularly with netjack but also with a variety of older systems.  In
some cases we don't have pulseaudio or D-bus running. in total we have
more consistent results with JACK1 for our use case.

I'm not saying that JACK2 cannot be made to perform as well as JACK1 in
the same circumstances and it could also be that proper A/B testing
reveals a user bias instead of real world performance differences.

However we generally do not have the time or inclination to do such tests
as it usually takes a considerable amount of effort to get a fully working
system and trying to replicate the results with JACK2 is not our main
motivation.

The point is that JACK1 is still very useful so unless we are going to
spend a lot of time/effort to track down the differences between JACK1 and
JACK2 it is useful to keep JACK1 alive for specific use cases.

Assuming that we have a few people who are willing to keep contributing to
the JACK1 codebase then it shouldn't be a problem for JACK1 to track JACK2
or vice versa.

However if no one wants to continue maintaining JACK1 then we need to
spend some time to find and isolate any differences in performance between
the two.




--
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Paul Davis
In reply to this post by Ralf Mardorf


On Mon, Feb 1, 2016 at 7:31 AM, Ralf Mardorf <[hidden email]> wrote:

D-bus is unimportant for me too. I don't know if JACK1 nowadays provide
-Xalsarawmidi or if I still need it this day, but JACK2's -Xalsarawmidi
at least reduced MIDI jitter on my Linux machine, when I needed it,
that's why I used it to get "high performance".

jack1 has a similar implementation but for the ALSA sequencer API, which means that (1) a2jmidid is no longer necessary (2) it can be used used to communicate with other (ALSA MIDI using) applications, not just hardware.
 

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Paul Davis
In reply to this post by Patrick Shirkey


On Mon, Feb 1, 2016 at 4:53 AM, Patrick Shirkey <[hidden email]> wrote:

It seems that the differences between JACK1 and JACK2 relate to the
intended target use case. JACK2 does a decent job of trying to enable many
consumer friendly tasks and take out some of the pain of doing inter
application audio production. JACK1 handles some heavy lifting scenarios
more effectively than JACK2.

On Linux, JACK1 provides extremely easy ways to use multiple devices at once, full integration with the ALSA sequencer system for MIDI and the metadata system to allow for "pretty names" among other things.

JACK2 offers dbus integration which means that it can interact with pulseaudio to "share" a device.

I don't think that your characterization is entirely accurate.
 
If he is interested, I nominate Harry Van Haaren as the new official
maintainer for JACK1 codebase. He has proven his skills and commitment and
is a fair and impartial communicator.

Filipe (falktx) has already volunteered for the position.
 


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

[Jack-Devel] Thank you! | The history of (JACK) session management

Bugzilla from micuintus@gmx.de
In reply to this post by Paul Davis
Hi Paul,
hi others,

Having been somewhat absent for a long time, I still passively always
watched the progress the FOSS audio world made. It is my plan to be more
active in the Linux pro audio world (when it comes to development) in
the future.

But that is another story. At this point, I'd rather simply like to say
"Thank you!" to you, Paul, for starting the JACK and Ardour universe.
Thanks for all your enduring dedication.

But also thanks to Stéphane, to falkTX, to Rui,... to all of you, who
put so much effort into the wonderful world of Linux Audio!


Paul Davis <[hidden email]> [30.01.2016 13:04]:
<[hidden email]>
> JACK was developed in part because of the absence of a viable plugin
> API on Linux. It allowed people to "glue together" whole applications
> rather than load plugins into a host. This is pretty cool, no
> question. But the session management aspects of it are not that cool,

Your analysis of the current situation is really interesting for me.

Actually, I was thinking a lot about the topic of session management the
last days, and I'd like to ask some questions about it:

Curiously, I had a hard time to find out something about the history of
session management on the internet. For example: What where the reasons
that, once LASH silently vanished, LASH was followed by (at least ---
not counting "non" here) successors: JACK session and LADISH?
Is there a fundamental difference between the two?


But that is not my main question.

It comes here:

Suppose,


    A) a JACK session manager used chunks instead of the "save your
       state %here" approach,
       (
         My guess this approached was chosen instead of chunks:      
         1) It requires less changes for a client to implement session  
         management support

         2) Cross-process chunks might have been considered a challange
       )

    B) This sesssion management is integrated into a DAW,
       et's say e.g. Ardour.

Hence, I could start some JACK clients, set up my connections, do some
config in my clients, hit save in Ardour, and save the whole stuff to
*one* file. When I reload it, everything is there as I left it.

Even if one of the clients was, let's say LMMS or Qtractor, it would be
still up to the user to decide whether they want to use Ardour, Qtractor
or LMMS as a JACK session client or as the session master. So this
wouldn't mean a privilege for any DAW setlled by the developers.

---> Would you consider the JACK approach then to be more valuable for
     the end user?

---> Do you think this is something to strive for?


Your opinions on these thoughts are highly appreciated :).


Kind regards,
micu

--
OpenPGP / GnuPG: 0xE4CB4E80
Fingerprint: 1A15 A480 1F8B 07F6 9D12 3426 CEFE 7455 E4CB 4E80

<<</>>

http://www.micuintus.de
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

Harry van Haaren
In reply to this post by Paul Davis
Patrick Shirkey wrote:
> If he is interested, I nominate Harry Van Haaren as the new official
> maintainer for JACK1 codebase

He's a little busy, and happily developing LV2 plugins for OpenAV in the time that's spare...

Paul Davis wrote:
> Filipe (falktx) has already volunteered for the position.

And is IMO the right guy for the job. Thanks falkTX for volunteering,
I'm a happy JACK1 user, and hope to keep it that way :)


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

thijz

Thanks for making pro audio possible on linux Paul !
And good luck with Ardour !

Grtz
Thijs

Op 1-feb.-2016 20:18 schreef "Harry van Haaren" <[hidden email]>:
Patrick Shirkey wrote:
> If he is interested, I nominate Harry Van Haaren as the new official
> maintainer for JACK1 codebase

He's a little busy, and happily developing LV2 plugins for OpenAV in the time that's spare...

Paul Davis wrote:
> Filipe (falktx) has already volunteered for the position.

And is IMO the right guy for the job. Thanks falkTX for volunteering,
I'm a happy JACK1 user, and hope to keep it that way :)


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: stepping down

John Rigg-16
In reply to this post by Patrick Shirkey
On Tue, Feb 02, 2016 at 12:17:08AM +1100, Patrick Shirkey wrote:

> Maybe it is the difference in the way we are using JACK over here.
> Particularly with netjack but also with a variety of older systems.  In
> some cases we don't have pulseaudio or D-bus running. in total we have
> more consistent results with JACK1 for our use case.
>
> I'm not saying that JACK2 cannot be made to perform as well as JACK1 in
> the same circumstances and it could also be that proper A/B testing
> reveals a user bias instead of real world performance differences.
>
> However we generally do not have the time or inclination to do such tests
> as it usually takes a considerable amount of effort to get a fully working
> system and trying to replicate the results with JACK2 is not our main
> motivation.
>
> The point is that JACK1 is still very useful so unless we are going to
> spend a lot of time/effort to track down the differences between JACK1 and
> JACK2 it is useful to keep JACK1 alive for specific use cases.
>
> Assuming that we have a few people who are willing to keep contributing to
> the JACK1 codebase then it shouldn't be a problem for JACK1 to track JACK2
> or vice versa.
>
> However if no one wants to continue maintaining JACK1 then we need to
> spend some time to find and isolate any differences in performance between
> the two.

I agree that JACK1 is still very useful. I'm mainly using JACK2 at the moment
because I need to run multiple clients with the load spread over several CPU
cores. I used JACK1 for many years before my present use case, and I'd use it
again on a simpler setup.

As a user it's a bit frustrating that there are other differences between
JACK1 and 2 apart from UP/SMP and dbus capability. There's often some
other trade off to consider when deciding which one to use.

John
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
1234