On Wed, Apr 4, 2012 at 5:22 AM, Rui Nuno Capela <rn...@rncbc.org> wrote:
> On 04/04/2012 12:18 PM, rosea.grammostola wrote: > >> On 04/03/2012 07:04 PM, Rui Nuno Capela wrote: >> >>> 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'? >> >> > 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. > Are you seriously saying that the equivalent of doing: if ( nsm_is_active ) save_here( file ); else save_there( file ); Would require a complete rewrite and overhaul of your application? Say you don't want to do it... That's fine. Say you don't like the NSM design--that's fine too. But don't just make up wild hyperbole out of laziness...
_______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev