<br><br><div class="gmail_quote">On Mon, Apr 9, 2012 at 9:03 AM, Fons Adriaensen <span dir="ltr"><<a href="mailto:fons@linuxaudio.org">fons@linuxaudio.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Mon, Apr 09, 2012 at 05:27:54PM +0200, rosea.grammostola wrote:<br>
<br>
> Personally I saw it as an advantage of JackSession, that it has JACK<br>
> involved and that it only needs the JACK dependency. After the comments<br>
> by Fons and by trying NSM myself, I think that it is an advantage of NSM<br>
> instead, that it is independent of JACK. It's more easy to add apps<br>
> without JACK support to the session and to keep apps with JACK support<br>
> outside the session (by purpose). It gives you as a user more freedom<br>
> and flexibility overall and so I think it's a better design choice.<br>
> These advantages out weights the disadvantage of having one extra<br>
> dependency to support NSM (liblo).<br>
<br>
</div>Liblo is *not* a dependency of any app using NSM. Since the NSM protocol<br>
specifies the actual messages, an app can send an receive them whatever<br>
code or library the developer prefers. In fact NSM does not add any<br>
dependencies at all.<br>
<br>
<br>
To ensure things stay like that, I'd like to see the following<br>
added to the NSM specs:<br>
<br>
* All communication is done using simple OSC messages,<br>
* i.e. without using bundles or wildcards.<br>
<br>
That way even the most basic OSC support would be enough to<br>
use NSM. And with the protocol as it stands, nothing is lost.<br>
<div class="im HOEnZb"><br></div></blockquote><div><br>This is true. Liblo is not a hard dependency. Anything that can send/receive OSC messages should work. It definitely doesn't use wildcards and I haven't actually found a use for OSC wildcards yet period, so I don't have a problem with officially avoiding them. Bundles are useful for some things (especially when delivering a list like response, because OSC has no more obvious way to indicate 'end of list'), and aren't very complicated at the stream level (just ordinary messages preceded by something that says, 'hey, this is a bundle of such and such length'), but, yeah, I don't have any idea how many of the OSC implementations out there support them. With liblo, it's only *generating* the bundle that is complicated. Receiving it is easy.The lowest common denominator here (that people are likely to actually use) is probably the Python OSC implementation. And, anyway, the current implementation doesn't use them for anything (if it did, it would probably use them for the session list response [not something most clients will even use] and the announce response/open pair [all clients use this one]).<br>
<br></div></div>