[LAD] NSM - handling large files

[rosea.grammostola]

On 04/04/2012 11:22 PM, David Robillard wrote:
> On Wed, 2012-04-04 at 21:59 +0200, rosea.grammostola wrote: [...]
>> I think it's essential to the discussion to get the cards on the
>> table, so everybody can make up his own mind and decides which SM
>> is the best solution for the Linuxaudio session puzzle. It would be
>> nice if we could reach agreement on this, but it's a free world
>> indeed. :)
>
> With apologies in advance, here are my cards:

Thanks, with my apologies in advance for my reply. :)
>
> It would be nice if this list could stick to actual
> developer/development problems.

Of course this is the LAD list, so I don't post often on this list, 
except for this topic, started by me and of importance for me.

I think this topic is a special case on LAD, because it's by far more 
interesting for users to have a good SM implementation then for 
developers. For musicians/ user it is a real problem when something 
doesn't work or when a session API is implemented badly (technically 
and/ or socially). Developers care much less.

But if you make such a strict border between devs and users, also in 
such a topic, as you seem to suggest, I'm afraid we'll have to deal with 
the same 'great-technical-design' but 
'sorry-not-yet-usable-if-you-really-want-to-make-music' software issues 
in the coming years on Linux.

Or in the case of session management,'great-minimal-design' but 
'useless-because-you-can-only-use-a-few-apps-and-we-dont-have-a-problem-with-that-because-we-dont-use-it-ourselves'.

I'll tell you why this topic is important to me. I did a talk about 
Linuxaudio. I can't tell you how much of a pain it was to get my stuff 
together. It did cost me more then a *fulltime week, 10h a day* to be 
able to show a more or less workable Linuxaudio workflow. Truly 
ridiculous and it made me realize that JackSession is utopian (and 
probably making music on Linux too) in this state.

It's nice to talk about software design side of Linuxaudio, but actually 
working with it is a whole different story, I tell you...especially the 
combination 'making music' and 'the modular approach'... (NSM seems to 
change this quite a bit though)

But if you're only interested in technical stuff and academic discussion 
about APIs, this might be not very interesting to read for you, my 
apologies.


> up on this thread, and almost nothing at all of value (i.e.
> something towards solving the/a problem) has been contributed since
> last I checked.  Mostly just a bunch of wannabe bureaucracy political
> noise, which only obscures any actual technical points that might
> need fleshing out (i.e. it's actively hurting, not helping). >
> Take the politics to LAU or something.


Call it politics, or call it just an obvious part of the process of 
implementing something like a session manager API, where a large part of 
the community has to deal with. For me it's not politics in the sense 
that I like to see API X supported, rather then API Y, don't get me 
wrong. I just think it's important to get the real true (technical/ LAD 
related) arguments on table, it helps already to get the picture clear 
and to kill argumentation flaws, wrong suggestions and myths. That's in 
the benefit for devs and users.


Regards,
\r