Re: [LAD] NSM - handling large files

On 03.04.2012 06:49, Joel Roth wrote:
> On Thu, Mar 29, 2012 at 03:44:17PM +0200, Emanuel Rumpf wrote:
>
>> Back to life - back to reality
>>
>> 1. We start qtractor as part of a session, create some midi-tracks,
>> include some external wav-files.
>>
>> Should the SM "know" about these external files, as I suggested ?
>> (Allowing the user to find out basic info about it. )
>> Or leave it completely to qtractor ?
>
<snip>
>
> As I understand it, the primary motivation for a session
> manager is to be able to save and restore the state of an
> audio project[1] that consists of multiple interconnected
> programs running on a multiprocessing Linux system.
>
> In other words, the minimum capability sufficient to be
> useful would be some sort of checkpointing mechanism.
>
> A secondary goal, discussed extensively here, is that it
> would be nice to be able to copy a session or export a
> session. This is where all the contentious issues with
> handling filesystem objects comes up.
>
> The latter goal should be optional, IMO, rather than required.
>
</snip>

this is exactly what i've been trying to tell (only that my english
wording leaves a lot to be desired)

thanks Joel :)

the primary goal is already achieved by qtractor on jack-session and
ladish; the second goal is the one i called "utopian".

speaking from a developer's pov. i find it very unlikely that NSM will
ever get broader acceptance than jack-session and/or ladish, given the
"utopian" restrictions it poses on client application design.

i wonder for a while: modifying an application to participate in
jack-session, for instance, is dead simple and costs only a small amount
of developer time and effort, provided he/she has the proper motivation
;)

otoh. i have this creepy feeling that, to comply to NSM, one has to
compromise a lot of the application design and behavior--gui
restrictions, file location restrictions, osc managing interface, to
name a few--not that they are bad ideas at all, quite the contrary, but
they impose a kind of non-negligible (pun intended;) change into
application workings, unless coded to comply to the NSM-client-logo from
day zero.

i keep wondering: if that ever flies above its toes then i'll certainly
call it "The linux-audio revolution" (or miracle, scnr:)

cheers

--
rncbc aka Rui Nuno Capela
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev