[LAD] Non Session Management

[thijs van severen]

2012/3/29 rosea.grammostola <rosea.grammostola at gmail.com>

> On 03/29/2012 01:16 PM, thijs van severen wrote:
>
>>
>>
>> 2012/3/29 rosea.grammostola <rosea.grammostola at gmail.com
>> <mailto:rosea.grammostola@**gmail.com <rosea.grammostola at gmail.com>>>
>>
>>
>>    On 03/29/2012 12:29 PM, thijs van severen wrote:
>>
>>
>>
>>        2012/3/29 Louigi Verona <louigi.verona at gmail.com
>>        <mailto:louigi.verona at gmail.**com <louigi.verona at gmail.com>>
>>        <mailto:louigi.verona at gmail.__**com <mailto:louigi.verona at gmail.**
>> com <louigi.verona at gmail.com>>>>
>>
>>
>>
>>            my 2 cents from user perspective: I know where I save my
>>        files, I know
>>            where my sample collections are. i know that if i delete my
>>        sample
>>            collection, sessions won't load. i don't need any program to
>>        tell me
>>            that.
>>
>>            in fact, in using FL Studio or Cubase or LMMS you have the same
>>            situation. a project can use same files as another project
>>        and if you
>>            damage those files - well, sorry.
>>
>>            I do not see any reason for complications in session manager
>>        design. i
>>            agree with david, all of this is unnecessary and only will
>>        make NSM a
>>            session manager developers would be reluctant to adopt.
>>
>>            louigi verona.
>>
>>            On 3/29/12, rosea.grammostola <rosea.grammostola at gmail.com
>>        <mailto:rosea.grammostola@**gmail.com<rosea.grammostola at gmail.com>
>> >
>>        <mailto:rosea.grammostola at __gm**ail.com <http://gmail.com>
>>
>>        <mailto:rosea.grammostola@**gmail.com<rosea.grammostola at gmail.com>>>>
>> wrote:
>>         > On 03/24/2012 11:09 PM, Fons Adriaensen wrote:
>>         >
>>         >>
>>         >> 3. Clearly defining the way an app should behave w.r.t. its
>>         >>     File menu entries (when managed). This is quite intrusive
>>         >>     to existing clients, but it is IMHO absolutley essential.
>>         >>     Kudos to the designer(s) for the having the courage to do
>>         >>     this instead of allowing application developers to take
>>         >>     the 'least effort' way (which would of course be better
>>         >>     marketing, but invite later misery).
>>         >
>>         > How easy or how difficult is it compared to JackSession for
>>            example, to
>>         > add NSM support to an application?
>>         >
>>         > Is it possible to have NSM and JackSession support in one
>>            application?
>>         >
>>         > Regards,
>>         >
>>         > \r
>>
>>
>>
>>        wasnt there a link somewhere in this mail thread about a
>>        comparison of
>>        all the pros and cons of 'all' SM's ?
>>        i went trough the thread but could not find it  :-(
>>        ah well, maybe i'm just dreaming
>>        would be nice though, such a comparison matrix
>>
>>    Iirc it was just an idea to do make that. It doesn't exist yet.
>>
>>    An overview would be good imo. It would be even better if such a
>>    matrix could help in making a decision for the best SM API to
>>    support, at the moment. As a user who wants to use session API X, I
>>    don't have much benefits if applications supports session API Y.
>>    Unless I decide to use Ladish, personally that wouldn't be my choice
>>    though.
>>
>> IMHO making such a matrix is the only good way to make a decisions of
>> any kind
>> is there anyone that has already made a 'study' that could be used as
>> the basis of a comparison matrix ?
>>
>
> A matrix is nice for a quick overview, but for such a decision you need
> more in depth information and argumentation. A matrix could only function
> as a tool to help with the decision.


true, but currently we dont have any overview at all
any tool is better than no tool, right ?



follow me on my Audio & Linux blog <http://audio-and-linux.blogspot.com/> !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20120329/b8cd4c65/attachment.html>