On 04/04/2012 05:19 PM, J. Liles wrote:
On Wed, Apr 4, 2012 at 5:22 AM, Rui Nuno Capela <[email protected] <mailto:[email protected]>> 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 );
this is level 0, assuming "file" is the application private state 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...
the rewrite is about level 1+ (my nomenclature, i know:) cheers -- rncbc aka Rui Nuno Capela [email protected] _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
