4 Apr
2012
4 Apr
'12
4:38 p.m.
On 04/04/2012 01:35 PM, rosea.grammostola wrote:
On 04/04/2012 02:22 PM, Rui Nuno Capela wrote:
well, NSM level 0 adds nothing to what JSM already delivers. sorry for
the noise :)
the once self-called "uber-procrastinator" says: prefer what is already
there and "de-facto" working.
of course it's a biased opinion
nuff said :)
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On 04/04/2012 12:18 PM, rosea.grammostola wrote:
Another question. If you compare NSM level 0 (!) with JackSession. Which
session manager do you prefer and why?
On 04/03/2012 07:04 PM, Rui Nuno Capela wrote:
speaking from qtractor pov.:
- level 0: minimal effort as it would be a probable and simple
rephrasing and/or adaptation of the code already in place for
jack-session; also, there's this osc branch somewhat lurking in svn to
get readily merged and apply for the NSM/OSC interface.
- level 1+: pervasive change and effort; almost brand new application
overhaul (iow. won't happen any time soon:) sorry. now, i could suggest NSM API to be split in
levels of compliance and
restrictiveness, so to speak:
- level 0 :- clients just store/retrieve their own private state from a
supplied and independent session sub-directory; no GUI File menu
restrictions; no file location restrictions, no symlinks, no juggling,
no dupes, no sh*t.
- level 1+ :- anything that (may progressively?) imposes each one the
mentioned non-restrictions of level 0.
How much more effort will it be in terms of coding, to implement
'level-1' versus 'level-0'?