linuxaudio.org

On 01/08/12 "rosea.grammostola"  wrote:

quoted text
>On 08/01/2012 03:30 AM, James Morris wrote:

>> On 30/07/12 "rosea.grammostola"  wrote:

>>> On 07/30/2012 03:12 AM, James Morris wrote:

>>>

>>>> (1.0) Non Session Management support

>>>

>>> Nice to see a dev who's taking this up. Session management a 'must

>>> have' for jack standalone applications and imho NSM is the best

>>> option for this.

>>

>> Woohoo there is now a grand total of 5 apps supporting it:

>> http://wiki.linuxaudio.org/apps/categories/nsm

>

>I count 7, but yeah despite your sarcasm, that's good news indeed,

>that's already more support then LASH had in it's first days.

>

>But the nice and essential thing about NSM is that it's support apps

>without a state, and apps without NSM support via nsm-proxy.

>Moreover NSM-proxy supports Ladish level 1 also.

>

>>

>> LASH failed despite 26 apps supporting it:

>> http://wiki.linuxaudio.org/apps/all/lash

>

>The problem with LASH is that it has obvious (technical) flaws.

>Session managers today are much better. Imo NSM has a great technical

>design, with advantages compared to other session api's and without

>(essential) technical flaws.

>

>If you think that all the apps apps.linuxaudio.org will support a

>session api, then  you're not very realistic. That's why it's

>essential that NSM support apps without NSM support and apps without a

>state in a user friendly way.

I guess. But for those who need to play around with stuff before they

find what they can use to start being productive it's not good.
>

quoted text
>>

>>

>> Just not enough developers with free time and brain cells not owned

>> by their employers to make it work.

>

>That's not totally true. If you count all the apps with a form of

>session management support, you can't really blame their efforts. On

>the other hand, it's true: session management seems to be primarily a

>users problem not a developers problem, unfortunately.

That many apps already have a form of session management is one of the

problems for NSM. What should a developer do when attempting to support

NSM in an application which already has Jack Session support and LASH

support? It increases the complexity of what the user interface has to

deal with.
>It's kind of a pity that NSM was released not earlier. Because of

quoted text
>other session api's, devs are hesitated to add NSM support, but I'm

>confident that this will change soon.

Maybe it's actually better - at least most people are aware now of the

problems with the other session managers (although from my experience

with LASH the main problems I faced were persistent crashes before ever

figuring out how to use it and way before any awareness of it's design

problems).
In Petri-Foo it wasn't so much of a problem. I simply removed support

for LASH because there was no user base to tell me otherwise. But can I

do that with other apps?
I'm looking at jack-rack for instance.
>

quoted text
>Speaking for myself, I start *all* the linuxaudio applications I use

>(with NSM support or via NSM-proxy) in NSM, because it works. And

>that's why I am optimistic, it's just great that all those years we

>have something that just works! :)

>

>Best regards,

>\r

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev