[LAD] [ann] out now petri-foo 0.1.85 / NSM

rosea.grammostola rosea.grammostola at gmail.com
Wed Aug 1 11:32:38 UTC 2012

On 08/01/2012 12:41 PM, James Morris wrote:
> On 01/08/12 "rosea.grammostola"<rosea.grammostola at gmail.com>  wrote:
>> On 08/01/2012 11:53 AM, James Morris wrote:
> ..
>>>>> 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.
>> I don't see what you mean. You've a list of apps with NSM support. You
>> can use those in the NSM session. Other apps you can launch via
>> nsm-proxy. If you want to use Ladish l1, look at the list of apps with
>> ladish l1 support.
> I would but linuxaudio.org seems to have gone down :-(
>>> 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.
>> First, it makes it far more easy to implement NSM. The time consuming
>> 'search work' for adding session support is already done.
>> Second, I assume that it is possible to support more session api's in
>> one application.
> The point I was making is supporting multiple session handlers makes
> the application more complex than it necessarily needs to be and
> increases the amount of code that needs to be maintained.
> If LASH has so many faults and nobody is maintaining LASH itself, by
> dropping support for LASH in clients we kill two birds with one
> stone: 1) there's less maintenence work for devs to do - always good
> and 2) it directs users to better solutions such as NSM.
> But I don't actually know what user base exists for LASH. I want to
> drop support for it but will revolting users castrate me for it?

LASH is dead, period. The only reason not to remove LASH is that Ladish 
supports it. But because Ladish will support NSM in future, it might be 
no problem to completely remove LASH if you add NSM.

JackSession is also more or less dead, because of some flaws in 
practical usage and because of the fact that it is more or less no 
longer maintained any longer. Which is good imo, it's better to have one 
session api then a lot. Ladish supports JS, but other then that there is 
little reason for not replacing JS with NSM.

It might be good for Linuxaudio if the JackSession devs declare 
JackSession to be dead.


More information about the Linux-audio-dev mailing list