<br><br><div class="gmail_quote">2012/3/29 rosea.grammostola <span dir="ltr"><<a href="mailto:rosea.grammostola@gmail.com">rosea.grammostola@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

On 03/29/2012 12:29 PM, thijs van severen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
2012/3/29 Louigi Verona <<a href="mailto:louigi.verona@gmail.com" target="_blank">louigi.verona@gmail.com</a><br>
<mailto:<a href="mailto:louigi.verona@gmail.com" target="_blank">louigi.verona@gmail.<u></u>com</a>>><div class="im"><br>
<br>
    my 2 cents from user perspective: I know where I save my files, I know<br>
    where my sample collections are. i know that if i delete my sample<br>
    collection, sessions won't load. i don't need any program to tell me<br>
    that.<br>
<br>
    in fact, in using FL Studio or Cubase or LMMS you have the same<br>
    situation. a project can use same files as another project and if you<br>
    damage those files - well, sorry.<br>
<br>
    I do not see any reason for complications in session manager design. i<br>
    agree with david, all of this is unnecessary and only will make NSM a<br>
    session manager developers would be reluctant to adopt.<br>
<br>
    louigi verona.<br>
<br>
    On 3/29/12, rosea.grammostola <<a href="mailto:rosea.grammostola@gmail.com" target="_blank">rosea.grammostola@gmail.com</a><br></div><div class="im">
    <mailto:<a href="mailto:rosea.grammostola@gmail.com" target="_blank">rosea.grammostola@<u></u>gmail.com</a>>> wrote:<br>
     > On 03/24/2012 11:09 PM, Fons Adriaensen wrote:<br>
     ><br>
     >><br>
     >> 3. Clearly defining the way an app should behave w.r.t. its<br>
     >>     File menu entries (when managed). This is quite intrusive<br>
     >>     to existing clients, but it is IMHO absolutley essential.<br>
     >>     Kudos to the designer(s) for the having the courage to do<br>
     >>     this instead of allowing application developers to take<br>
     >>     the 'least effort' way (which would of course be better<br>
     >>     marketing, but invite later misery).<br>
     ><br>
     > How easy or how difficult is it compared to JackSession for<br>
    example, to<br>
     > add NSM support to an application?<br>
     ><br>
     > Is it possible to have NSM and JackSession support in one<br>
    application?<br>
     ><br>
     > Regards,<br>
     ><br>
     > \r<br>
<br>
<br>
<br>
wasnt there a link somewhere in this mail thread about a comparison of<br>
all the pros and cons of 'all' SM's ?<br>
i went trough the thread but could not find it  :-(<br>
ah well, maybe i'm just dreaming<br>
would be nice though, such a comparison matrix<br>
<br>
</div></blockquote>
Iirc it was just an idea to do make that. It doesn't exist yet.<br>
<br>
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.<span class="HOEnZb"><font color="#888888"><br>


<br></font></span></blockquote><div> </div><div>IMHO making such a matrix is the only good way to make a decisions of any kind</div><div>is there anyone that has already made a 'study' that could be used as the basis of a comparison matrix ?</div>

</div>thijs<br><br clear="all"><div><br></div>-- <br><br><div>follow me on my <a href="http://audio-and-linux.blogspot.com/" target="_blank">Audio & Linux blog</a> !</div><br>