On 01/08/12 "rosea.grammostola" <rosea.grammostola@email-addr-hidden> wrote:
>On 08/01/2012 03:30 AM, James Morris wrote:
>> On 30/07/12 "rosea.grammostola"<rosea.grammostola@email-addr-hidden> 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.
>
>>
>>
>> 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
>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.
>
>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@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed Aug 1 16:15:03 2012
This archive was generated by hypermail 2.1.8 : Wed Aug 01 2012 - 16:15:03 EEST