Re: [LAD] NSM - handling large files

[Louigi Verona]

>From my user perspective - I use samples extensively, however I care very
little about exporting projects.
I do care about preserving them, but I have a special folder called
Sessions where I save projects from all audio apps. Add my sample library
to that and I can preserve everything.



-- 
Louigi Verona
http://www.louigiverona.ru/
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

[David Robillard]

On Thu, 2012-03-29 at 18:29 -0700, J. Liles wrote:
[...]
> Currently, when you drag n' drop an external audio file into a Non-DAW
> timeline (as opposed to recording it from within Non-DAW), the file
> remains external with its path recorded
> in the project's journal. Using a symlink for this would be better in
> *at least* the following two ways:
> 
> 1) Allows archiving scripts etc. to discover and import the external
> source *without having to understand the Non-DAW journal format*
> 2) It would allow Non-DAW to import external sources *without having
> to update (or break) any existing references*
> 
> I cannot imagine any argument that could propose that these are bad things.

Me neither.  Well, not a good one, anyway :)

> If all Linux Audio software dealt with external references in this
> way, archiving/export would be much less problematic.

Yep.  I arrived at this via the experience of actually doing it - a
special magic solution seems feasible when you've got blinders on and
are just thinking about an SM program, but when you realize this can
cross-cut all the way from inside a generic library for loading standard
file(s) formats, through a plugin, through the host, through the session
manager, it's clear links are the only way.  It can be hard enough to
get saving right *without* making the load all weird.

It's not a "YOU MUST DO THIS FOR NON SESSION MANAGER", it's a "you
should do this because it makes external file references manageable"

> However, I would also like to offer an interesting little statistic...
> I, personally, have hundreds of projects representing terabytes of
> data, and in all that I don't have a single project which refers to
> anything external to its project directory. This is something that
> only effects certain users who make extensive use of sound-clip or
> sample libraries. Not people who just do plain old
> recording/synthesis/mixing. So let's try not to make a mountain out of
> a mole hill. What is the actual percentage of users who have
> references to external files *and* a strong need to export their
> sessions? I suspect that it is in fact a very low number.

Certainly true for recorded audio files, sharing those between programs
is pretty esoteric (and if you're doing it, as Fons says, you "know what
you're doing" anyway).  In the greater scheme of things, though, using
sample banks and such is certainly not nichey.
 
When you do work with such things, it really sucks to not have a
reliable way to roll up a finished piece so it will actually work in the
future.

Plus, being able to easily share full sessions and collaborate and stuff
is cool and open sourcey :)

> Furthermore, in addition to the plain old symlinks, a truly robust
> solution might also store e.g. SHA1 hashes of external files, so that
> any mismatch is detectable.

Good idea.  Certainly can't hurt to know, though computing a hash of
some files might be extremely expensive...

-dr

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

[J. Liles]

On Thu, Mar 29, 2012 at 2:23 PM, Rui Nuno Capela  wrote:
>
> indeed. real life that is :)
>
> as far as qtractor is, all media content files, be that either audio or midi
> types, are ALL external files. it's true that some are created and edited
> under qtractor direct control, but they are all external. no exceptions.
>
> otoh, a qtractor session file (xml) is a listing or a map of references
> (links, paths, whatever) to those external files as they are in the
> file-system. but no, never symlinks.
>
> qtractor's "session directory" (aka. its own "session folder") is just an
> user preference, a location where all newly created media files (again,
> audio or midi, recorded or scratch) are located first time they get into
> existence--do not ever confuse this with any portable session directory or
> folder in any way. in fact, you get serious trouble if you do so. although
> there's this qtractor session archive/zip bundle file format (.qtz) which
> serves that particular purpose but as an option and convenience (just like
> an independent, moveable, self-contained zip-folder)

Are you saying that qtractor stores all audio and MIDI files that it
creates in one central folder? That seems quite bizarre. What is the
justification for doing that? How does it benefit the user?

> external or not, all-media content file "awareness" from a foreseeable
> session management entity, being that big or small, central or not, is, if
> you ask me, utopian.

It isn't utopian if one follows David's scheme. A file is a file is a
file (is a symlink). Instead of storing a path to the external file,
create an internal symlink to it and store the path to the symlink
instead. Simple and it allows *any* tool to find *all* of the external
data referred to by a session.

> sure, it would certainly be a really-good-thing(tm) to make a session
> archive portable across file-systems, machine architectures or platforms,
> users, networks, you name it... it really seems like an
> all-in-one/knows-it-all "goddess" application if you ask me. yuck! a
> pipe-dream if i reckon one :)

Well, I certainly agree that the actual need for this kind of
functionality is probably being overestimated.

> otoh. now in particular, those GUI (file menu) restrictions that NSM is
> posing on applications is something i won't comply to any time soon, not
> even later. so sorry. it's way too restrictive to me and my own belongings.
> from what i read, applications must then be modified to run in either of two
> or more awful different session modes eg. managed and non-managed? for
> x-sake, as if we hadn't enough of that already... i am so sorry again, but
> such a design won't fly much above the grass in my lawn... it gives me the
> shivers o,O
>
> but that maybe just a first glance pov. don't take it final

The point of those guidelines is to allow users to know *exactly* what
behavior they can expect.

The chief difficulty I had with implementing LASH support in programs
was that there was no answer as to what 'Save', 'Open', 'New', etc.
should do when running under LASH. Left, as is, the effect of these
operations would vary depending on how individual applications store
their state (whether fully in RAM, in a fixed location on disk, etc.).
This scenario is an absolute nightmare for both implementers and
users. If following a few simple rules to disable certain menu options
is enough to remove this ambiguity entirely, then why is that so hard
for you to accept? Do you *want* to make things ambiguous and
impossible to predict? I know I don't. The rules are not there to be
draconian and imposing--They are there to allow people to have
confidence in what running under session management means regarding
where their data is stored.

> however ;) imho, the SM should only know about application instances that
> are part of the so-called "session", their state of which only each
> application knows about their own, or so i believe, _and_ the means to
> recall that collected set of states later on. if that state is described by
> a set of files, so be it. let's name it state-data-files, or just call it
> _internal_ files perhaps?

I'm not sure what you mean, but to me it is obvious that only programs
which are connected to the session manager are subject to its control.

> more. a session manager (or its protocol spec) should not touch any, any at
> all, of the external (media content?) files that each application are
> possibly working on during their life span.

Of course it shouldn't.

> under the so called session's -folder (or -directory, if you prefer) there
> should be _only_ stored the state-data-files that pertain to each
> participant application. you guess it right, that's the state of each
> participating application instance at the time of the eventual
> "save-this-session-now!" command gets issued (a-la snapshot). and add to
> that the inter-connection state file(s) as it will be certainly the job of
> the SM to gather too. jack-session does this

Re: [LAD] NSM - handling large files

[J. Liles]

On Thu, Mar 29, 2012 at 4:40 PM, David Robillard  wrote:
> On Thu, 2012-03-29 at 22:23 +0100, Rui Nuno Capela wrote:
>> now back to square one. to make that whole session state, folder or
>> directory, as an archival portable one is, quite frankly and imho again,
>> utopian. nuff said :)
>
> It's indeed utopian to think that some centralized special magic program
> and protocol and file format and whatever else will actually get
> universally adopted.
>
> However, files and directories and links are anything but
> unrealistically utopian.  That's my point.
>
> With all due respect, Emanuel, you can see here what happens when you
> make a big complicated mess out of things and try to ram technology down
> implementer's throats without justification: they simply reject it
> outright as a utopian fantasy.
>
> Achieving archival/etc is *trivial* without any fancy/annoying session
> management crap whatsoever.  If apps want to save in a way that prevents
> it, they will always be able to, however if they do, there is *one*
> simple rule that makes *all* the mentioned functionality possible that
> has nothing to do with any specific session manager API/protocol/file
> formats/etc whatsoever:
>
>  * All references to files outside the session directory must be a
> symlink to that file
>
> That's it.  No APIS, no protocols, no session manager file stores, no
> redundant data that may not match reality, no egregious rules.  There's
> not even a requirement for a session manager to be involved whatsoever,
> if an app saves this way independently you can archive its sessions with
> tar or whatever just the same.  If you did want a fancy GUI archival
> tool that reports what files are used and whatever else, you could write
> one, and it wouldn't even depend on the session manager at all - and I
> don't mean it would loosely depend on it by only using OSC or whatever,
> I mean it would not depend on it *at all*, nor would it depend on any
> file format[1].  All even vaguely common languages have everything
> required in their standard library, right now.  All of that Just
> Works-eyness is because it's a simple idea, and doesn't use anything
> that hasn't been baked in to the OS for literally decades.  It doesn't
> get much less unrealistically utopian than this.
>
> Erecting some fantastic non-existent architecture to achieve, in one
> special circumstance, what this simple rule does, is a folly doomed for
> failure.  To really distill it down, since we're on a "reality" trip:
> you can either try to get people to adopt this convention, or you can
> not have archivable/distributable sessions.  There is no option C.
>
> That said, if I'm overlooking something, do tell (i.e. why, exactly, is
> this simple plan not sufficient?), because from where I'm standing it's
> a real mystery why we are acting like this is so damned complicated.
>
> It's not.  At all.
>
> -dr
>
> [1] Try to sell any file format to this crowd and see how far you get...

I absolutely agree on this point. In fact, referring to external files
in this way is now on my TODO list for Non-DAW.

Currently, when you drag n' drop an external audio file into a Non-DAW
timeline (as opposed to recording it from within Non-DAW), the file
remains external with its path recorded
in the project's journal. Using a symlink for this would be better in
*at least* the following two ways:

1) Allows archiving scripts etc. to discover and import the external
source *without having to understand the Non-DAW journal format*
2) It would allow Non-DAW to import external sources *without having
to update (or break) any existing references*

I cannot imagine any argument that could propose that these are bad things.

If all Linux Audio software dealt with external references in this
way, archiving/export would be much less problematic.

However, I would also like to offer an interesting little statistic...
I, personally, have hundreds of projects representing terabytes of
data, and in all that I don't have a single project which refers to
anything external to its project directory. This is something that
only effects certain users who make extensive use of sound-clip or
sample libraries. Not people who just do plain old
recording/synthesis/mixing. So let's try not to make a mountain out of
a mole hill. What is the actual percentage of users who have
references to external files *and* a strong need to export their
sessions? I suspect that it is in fact a very low number.

Furthermore, in addition to the plain old symlinks, a truly robust
solution might also store e.g. SHA1 hashes of external files, so that
any mismatch is detectable.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

[David Robillard]

On Thu, 2012-03-29 at 22:23 +0100, Rui Nuno Capela wrote:
> now back to square one. to make that whole session state, folder or 
> directory, as an archival portable one is, quite frankly and imho again, 
> utopian. nuff said :)

It's indeed utopian to think that some centralized special magic program
and protocol and file format and whatever else will actually get
universally adopted.

However, files and directories and links are anything but
unrealistically utopian.  That's my point.

With all due respect, Emanuel, you can see here what happens when you
make a big complicated mess out of things and try to ram technology down
implementer's throats without justification: they simply reject it
outright as a utopian fantasy.

Achieving archival/etc is *trivial* without any fancy/annoying session
management crap whatsoever.  If apps want to save in a way that prevents
it, they will always be able to, however if they do, there is *one*
simple rule that makes *all* the mentioned functionality possible that
has nothing to do with any specific session manager API/protocol/file
formats/etc whatsoever:

 * All references to files outside the session directory must be a
symlink to that file

That's it.  No APIS, no protocols, no session manager file stores, no
redundant data that may not match reality, no egregious rules.  There's
not even a requirement for a session manager to be involved whatsoever,
if an app saves this way independently you can archive its sessions with
tar or whatever just the same.  If you did want a fancy GUI archival
tool that reports what files are used and whatever else, you could write
one, and it wouldn't even depend on the session manager at all - and I
don't mean it would loosely depend on it by only using OSC or whatever,
I mean it would not depend on it *at all*, nor would it depend on any
file format[1].  All even vaguely common languages have everything
required in their standard library, right now.  All of that Just
Works-eyness is because it's a simple idea, and doesn't use anything
that hasn't been baked in to the OS for literally decades.  It doesn't
get much less unrealistically utopian than this.

Erecting some fantastic non-existent architecture to achieve, in one
special circumstance, what this simple rule does, is a folly doomed for
failure.  To really distill it down, since we're on a "reality" trip:
you can either try to get people to adopt this convention, or you can
not have archivable/distributable sessions.  There is no option C.

That said, if I'm overlooking something, do tell (i.e. why, exactly, is
this simple plan not sufficient?), because from where I'm standing it's
a real mystery why we are acting like this is so damned complicated.

It's not.  At all.

-dr

[1] Try to sell any file format to this crowd and see how far you get...

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

[Rui Nuno Capela]

On 03/29/2012 10:45 PM, Fons Adriaensen wrote:

On Thu, Mar 29, 2012 at 10:23:30PM +0100, Rui Nuno Capela wrote:


otoh. now in particular, those GUI (file menu) restrictions that NSM is
posing on applications is something i won't comply to any time soon, not
even later. so sorry. it's way too restrictive to me and my own
belongings. from what i read, applications must then be modified to run
in either of two or more awful different session modes eg. managed and
non-managed? for x-sake, as if we hadn't enough of that already... i am
so sorry again, but such a design won't fly much above the grass in my
lawn... it gives me the shivers o,O


You can't expect *any* session management system to work in
a reliable way without those rules. That's simple, basic, and
fairly easy to grok logic. The consequences of an app ignoring
this could be far more damaging than those of a user willingly
and knowingly keeping some data 'external'. And they will hit
the average user who doesn't even think about doing such things
and who expects his SM to just work.

Taking these rules into account is no big deal anyway. At least
not if your app has a clean control structure.

Again, the fact that the designer(s) of NSM have clearly stated
these rules is a sign that he/she/they know what is involved, and
has/have the courage to say this instead of going 'the easy way'.



well, you're probably right. i'm sure you are :)

only so like that he rules are telling me that i must code my 
application to run in at least two different modes: one (NSM-)managed 
and the other non-managed--often the original intended one


which one will it be? i ask: when will the user gets to run the 
application in which mode? or is that telling us that all applications 
should then be started under a "totalitarian" ruler as in NSM 
auspices?... oops. just i read the interesting part cf. 
http://non.tuxfamily.org/nsm/#n:1.1.1.7. Add Client, and yeah, really 
scary now... f7u12!


i may say now that people will be always welcome to patch (my) software, 
anytime ;)


cheers
--
rncbc aka Rui Nuno Capela
rn...@rncbc.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

[Fons Adriaensen]

On Thu, Mar 29, 2012 at 10:23:30PM +0100, Rui Nuno Capela wrote:

> otoh. now in particular, those GUI (file menu) restrictions that NSM is  
> posing on applications is something i won't comply to any time soon, not  
> even later. so sorry. it's way too restrictive to me and my own  
> belongings. from what i read, applications must then be modified to run  
> in either of two or more awful different session modes eg. managed and  
> non-managed? for x-sake, as if we hadn't enough of that already... i am  
> so sorry again, but such a design won't fly much above the grass in my  
> lawn... it gives me the shivers o,O

You can't expect *any* session management system to work in
a reliable way without those rules. That's simple, basic, and
fairly easy to grok logic. The consequences of an app ignoring
this could be far more damaging than those of a user willingly
and knowingly keeping some data 'external'. And they will hit
the average user who doesn't even think about doing such things
and who expects his SM to just work.

Taking these rules into account is no big deal anyway. At least
not if your app has a clean control structure.

Again, the fact that the designer(s) of NSM have clearly stated
these rules is a sign that he/she/they know what is involved, and
has/have the courage to say this instead of going 'the easy way'.


Ciao,

-- 
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] HDSP 9652 and Behringer ADA8000

[Fons Adriaensen]

On Thu, Mar 29, 2012 at 10:51:57PM +0200, Giso Grimm wrote:

> > I wonder, what is the link between preparing those files (which 
> > should not involve anything except editing and maybe getting the
> > levels equal, i.e. no hardware involved at all), and that discovery ?
> 
> no link at all, it just happened to be noticed then (only that I boosted
> the levels to reach near fullscale), and I used to have other default
> hdspmixer settings.

Could be related/similar to another problem I discovered: 
clock recovery from the ADAT input can become unstable at
times, it seems to depend on (digital) signal levels and
on which of the 8 channels are being used...

Ciao,

-- 
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

[Rui Nuno Capela]

On 03/29/2012 02:44 PM, 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 ?

2. We record a new file in qtractor. Where would it be stored ?

Should the SM "know" about this file ?

3. A session is duplicated.
How does the SM handle the recorded and external files =

4. A session is exported.
Jonathan said, current practice is a simple directory copy.
Well ! Simple and not bad at all.
But what about the external files ?
Just make some symlinks for them ?




indeed. real life that is :)

as far as qtractor is, all media content files, be that either audio or 
midi types, are ALL external files. it's true that some are created and 
edited under qtractor direct control, but they are all external. no 
exceptions.


otoh, a qtractor session file (xml) is a listing or a map of references 
(links, paths, whatever) to those external files as they are in the 
file-system. but no, never symlinks.


qtractor's "session directory" (aka. its own "session folder") is just 
an user preference, a location where all newly created media files 
(again, audio or midi, recorded or scratch) are located first time they 
get into existence--do not ever confuse this with any portable session 
directory or folder in any way. in fact, you get serious trouble if you 
do so. although there's this qtractor session archive/zip bundle file 
format (.qtz) which serves that particular purpose but as an option and 
convenience (just like an independent, moveable, self-contained zip-folder)


external or not, all-media content file "awareness" from a foreseeable 
session management entity, being that big or small, central or not, is, 
if you ask me, utopian.


sure, it would certainly be a really-good-thing(tm) to make a session 
archive portable across file-systems, machine architectures or 
platforms, users, networks, you name it... it really seems like an 
all-in-one/knows-it-all "goddess" application if you ask me. yuck! a 
pipe-dream if i reckon one :)


otoh. now in particular, those GUI (file menu) restrictions that NSM is 
posing on applications is something i won't comply to any time soon, not 
even later. so sorry. it's way too restrictive to me and my own 
belongings. from what i read, applications must then be modified to run 
in either of two or more awful different session modes eg. managed and 
non-managed? for x-sake, as if we hadn't enough of that already... i am 
so sorry again, but such a design won't fly much above the grass in my 
lawn... it gives me the shivers o,O


but that maybe just a first glance pov. don't take it final

however ;) imho, the SM should only know about application instances 
that are part of the so-called "session", their state of which only each 
application knows about their own, or so i believe, _and_ the means to 
recall that collected set of states later on. if that state is described 
by a set of files, so be it. let's name it state-data-files, or just 
call it _internal_ files perhaps?


more. a session manager (or its protocol spec) should not touch any, any 
at all, of the external (media content?) files that each application are 
possibly working on during their life span.


under the so called session's -folder (or -directory, if you prefer) 
there should be _only_ stored the state-data-files that pertain to each 
participant application. you guess it right, that's the state of each 
participating application instance at the time of the eventual 
"save-this-session-now!" command gets issued (a-la snapshot). and add to 
that the inter-connection state file(s) as it will be certainly the job 
of the SM to gather too. jack-session does this kind of stuff.


now back to square one. to make that whole session state, folder or 
directory, as an archival portable one is, quite frankly and imho again, 
utopian. nuff said :) but (oh no, not again), as a clever guy once said, 
the impossible turns out to be possible when there's someone foolish 
enough to do it ;)


my 2c
--
rncbc aka Rui Nuno Capela
rn...@rncbc.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] HDSP 9652 and Behringer ADA8000

[Giso Grimm]

On 03/29/2012 10:28 PM, Fons Adriaensen wrote:
> On Thu, Mar 29, 2012 at 09:09:26PM +0200, Giso Grimm wrote:
>  
>> Here you might listen, the same piece, same musicians, same place, same
>> mics (Neumann KM184 pair), same positions, same lute (although it was at
>> the luthier for repair in between), one was four month later, the words
>> were changed a bit. Please guess which was ADA8000 and which was Micstasy:
>>
>> http://vegri.net/come_shadow.wav
>> http://vegri.net/come_shape.wav
>>
>> (7 MB each)
>>
 No idea if there's more to break, though. ;) 
>>
>> yes there is, I just discovered while preparing those files :-(  If you
>> drive all outputs near maximum amplitude simultaneously (-1.5 dB FS),
>> the power supply seems to break down, and you hear buzzes (following the
>> peaks of your music). If I take down a few channels everything is fine.
> 
> I wonder, what is the link between preparing those files (which 
> should not involve anything except editing and maybe getting the
> levels equal, i.e. no hardware involved at all), and that discovery ?

no link at all, it just happened to be noticed then (only that I boosted
the levels to reach near fullscale), and I used to have other default
hdspmixer settings.


> Anyway, this is still an 'easy' test, it doesn't stretch the 
> hardware to any limits at all.

Sure, that is the reason why I cut the silence away - there you can hear
clear differences.

> 
> The difference between the Behringer and the Micstasy is not
> about 'audio quality' in the sense of frequency response,
> distortion, etc. It would take really bad engineering to get
> those so bad that it would matter.
> 
> It is all about technical qualities that *do* matter if things
> get a bit more difficult: hum levels, noise levels, the ability
> to change the mic gain while recording without any risk and by
> a defined amount, resistance to RF and mains interference, being
> able to supply stable phantom power on all inputs, etc. etc.

I totally agree, my B.s drove me almost crazy several times. For
concerts (where I need 3 of them) I always have a spare one reachable.

> Try recording a contemporary music concert on location, with
> percussion ranging from barely audible scratches to a bing bang,
> and voices switching between whispering and screaming in a matter
> of seconds. This sort of thing even takes a Micstasy or an Aphex
> 1778A to its limits. Your B. will fail miserably.

I did that as well a few weeks ago, and by B. failed :-)

Right now I don't have additional 4kEUR just for reliability, that's why
I still use my B.s (except when I can borrow a Micstasy), but I cannot
wait the day when I say good bye to them...

Giso
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] HDSP 9652 and Behringer ADA8000

[Fons Adriaensen]

On Thu, Mar 29, 2012 at 09:09:26PM +0200, Giso Grimm wrote:
 
> Here you might listen, the same piece, same musicians, same place, same
> mics (Neumann KM184 pair), same positions, same lute (although it was at
> the luthier for repair in between), one was four month later, the words
> were changed a bit. Please guess which was ADA8000 and which was Micstasy:
> 
> http://vegri.net/come_shadow.wav
> http://vegri.net/come_shape.wav
> 
> (7 MB each)
> 
> >> No idea if there's more to break, though. ;) 
> 
> yes there is, I just discovered while preparing those files :-(  If you
> drive all outputs near maximum amplitude simultaneously (-1.5 dB FS),
> the power supply seems to break down, and you hear buzzes (following the
> peaks of your music). If I take down a few channels everything is fine.

I wonder, what is the link between preparing those files (which 
should not involve anything except editing and maybe getting the
levels equal, i.e. no hardware involved at all), and that discovery ?

Anyway, this is still an 'easy' test, it doesn't stretch the 
hardware to any limits at all.

The difference between the Behringer and the Micstasy is not
about 'audio quality' in the sense of frequency response,
distortion, etc. It would take really bad engineering to get
those so bad that it would matter.

It is all about technical qualities that *do* matter if things
get a bit more difficult: hum levels, noise levels, the ability
to change the mic gain while recording without any risk and by
a defined amount, resistance to RF and mains interference, being
able to supply stable phantom power on all inputs, etc. etc.

Try recording a contemporary music concert on location, with
percussion ranging from barely audible scratches to a bing bang,
and voices switching between whispering and screaming in a matter
of seconds. This sort of thing even takes a Micstasy or an Aphex
1778A to its limits. Your B. will fail miserably.

Ciao,

-- 
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] HDSP 9652 and Behringer ADA8000

[Adrian Knoth]

On Thu, Mar 29, 2012 at 09:09:26PM +0200, Giso Grimm wrote:

> Here you might listen, the same piece, same musicians, same place, same
> mics (Neumann KM184 pair), same positions, same lute (although it was at
> the luthier for repair in between), one was four month later, the words
> were changed a bit. Please guess which was ADA8000 and which was Micstasy:
> 
> http://vegri.net/come_shadow.wav
> http://vegri.net/come_shape.wav

Given my 50:50 chance, I tend to claim "shadow" is the Behringer, but
maybe it's the slightly different reverb that's tricking me.

Let's collect more votes.



Cheers

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] HDSP 9652 and Behringer ADA8000

[Giso Grimm]

On 03/28/2012 11:42 PM, Giso Grimm wrote:
> On 03/28/2012 11:25 PM, Adrian Knoth wrote:
>> On Wed, Mar 28, 2012 at 09:03:24PM +, Fons Adriaensen wrote:
>>
>> [ADA-8000]
>>> other in 6U rack - just 1U space at the top and bottom.
>>> Three of them were fried. You only know when the damage
>>> is done.
>>
>> I've just replaced a broken capacitor in an ADA-8000's power supply
>> yesterday.
> 
> the same happend here once.
> 
> [...complaints on reliability...]
> 
> Until now I had no problems with the outputs of the ADA8000.
> 
> Recently I made a recording (lute & singing), partly with ADA8000,
> partly with RME Micstasy, both with the same Neumann mics, and I could
> barely hear the difference...
> 

Here you might listen, the same piece, same musicians, same place, same
mics (Neumann KM184 pair), same positions, same lute (although it was at
the luthier for repair in between), one was four month later, the words
were changed a bit. Please guess which was ADA8000 and which was Micstasy:

http://vegri.net/come_shadow.wav
http://vegri.net/come_shape.wav

(7 MB each)

>> No idea if there's more to break, though. ;) 

yes there is, I just discovered while preparing those files :-(  If you
drive all outputs near maximum amplitude simultaneously (-1.5 dB FS),
the power supply seems to break down, and you hear buzzes (following the
peaks of your music). If I take down a few channels everything is fine.
All outputs are connected to the inputs of a Presonus HP60.

Cheers,

Giso
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Non Session Management

[David Robillard]

On Thu, 2012-03-29 at 15:29 +0200, Emanuel Rumpf wrote:
> Am 28. März 2012 20:53 schrieb David Robillard :
> >
> > It's sooo complicated because it forces everything involved to use a
> > special file finding and/or loading interface.
> >
> wrong - apps only tell the SM about files used externally - that's all.

In order to do anything useful, most obviously archive, the SM needs the
ability to change those paths.

The only realistic way of achieving this is via links.  Otherwise you
would have to design a "move files" protocol, and in order to
archive/move/etc you'd have to launch every app and use that protocol to
manipulate the session state, because the SM doesn't know every
program's file format.

Not only is that a huge implementation burden on apps, it's clunky and
fragile; a big silly mess to do what tar or a 10 line Python script
could do.

Not a realistic solution.

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] HDSP 9652 and Behringer ADA8000

[Fons Adriaensen]

On Thu, Mar 29, 2012 at 02:27:42PM +0200, Adrian Knoth wrote:
 
> I've already posted the following blind test:
> 
>http://adi.loris.tv/converters/
> 
> One device is Lynx Aurora 16, the other one is Behringer ADA-8000.
> No information was given whether A=Aurora and B=Behringer or vice versa,
> and audio engineers were asked to judge.
> 
> They failed, the outcome was equally distributed, so it's fair to say
> that not even trained ears were able to to hear a difference.
 
No surprise.

With *that* test file (distorted, probably clipped, 1 dB dynamic range)
even a 6-bit AD/DA would sound perfect. 

Ciao,

-- 
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] HDSP 9652 and Behringer ADA8000

[Fons Adriaensen]

On Thu, Mar 29, 2012 at 02:27:42PM +0200, Adrian Knoth wrote:

> Yes, ADA8000 is based on Alesis (now WaveFront Semiconductors) A/D
> (AL1101), D/A (AL1201), an ADAT encoder (OptoGen AL1401) and an ADAT
> receiver (OptoRec AL1402).
> 
> The ADA8000 is a copy of the RME AEB8-I (I had the scheme for it if you
> want), and the scheme is simply an expansion to 8 channels (instead of
> 2) of the appnote given by Alesis for OptoGen and OptoRec.

Which (the appnote) does not include the mic preamp. Strangely 
enough the ADA8000 preamp has a very good noise figure if used
at maximum gain (real max, not just close). It gets very bad
once gain is reduced. That is due to *bad design*, you can 
predict this (without even doing any calculation) by just
looking at the circuit diagram. And the line input is just an
attenuator feeding the mic preamp. I don't think all that is
a copy of anything RME. 

Apart from that, 50,150,250 Hz hum levels increase from left
to right (i.e. as you get closer to the power supply). Which
gets hot enough to fry some eggs if you take 5 mA of phantom
power from each input.

Ciao,

-- 
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Non Session Management

[rosea.grammostola]

On 03/29/2012 04:22 PM, Emanuel Rumpf wrote:

Am 29. März 2012 13:16 schrieb thijs van severen>


IMHO making such a matrix is the only good way to
make a decisions of any kind



I disagree here: Session managers have different concepts.
A simple matrix doesn't do it (show it).

IMHO user _experience_ is most important.
1. is it stable and reliable
2. does it do the job
3. behaves it practically (work-flow, feeling, user-interface)

Thus it is best to simply try - a thing that is difficult, as long
as an application is incomplete.

Fortunately NSM and the other SMs have advanced enough to try.
As I did mention, I have a good feeling with NSM
and I'm trusting this thing to become complete.


I think a conceptual analyses is also needed on forehand, without the SM 
being complete. You could think of questions like:

* is it (in theory) possible to use it crossplatform,
* is it (in theory) possible to use it without X,
* is it (in theory) possible to use it via the network
* etc

You don't want to support an API which can't run (in theory) 
crossplatform. You have some standards a SM should be able to do, like 
there is for JACK and all other kinds of stuff.


But I agree, user experience is important too. So Thijs, Louigi, ... , 
did you try it already? What are your experiences?





Thanks for your opinion.
I tend to agree with you and Renato:
rather not make it too complicated,
but usable and reliable.



+1
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Non Session Management

[Emanuel Rumpf]

Am 29. März 2012 13:16 schrieb thijs van severen >
>
> IMHO making such a matrix is the only good way to
> make a decisions of any kind
>

I disagree here: Session managers have different concepts.
A simple matrix doesn't do it (show it).

IMHO user _experience_ is most important.
1. is it stable and reliable
2. does it do the job
3. behaves it practically (work-flow, feeling, user-interface)

Thus it is best to simply try - a thing that is difficult, as long
as an application is incomplete.

Fortunately NSM and the other SMs have advanced enough to try.
As I did mention, I have a good feeling with NSM
and I'm trusting this thing to become complete.

Thanks for your opinion.
I tend to agree with you and Renato:
rather not make it too complicated,
but usable and reliable.

-- 
E.R.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] NSM - handling large files

[Emanuel Rumpf]

Am 29. März 2012 15:34 schrieb Emanuel Rumpf :


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 ?

2. We record a new file in qtractor. Where would it be stored ?

Should the SM "know" about this file ?

3. A session is duplicated.
How does the SM handle the recorded and external files =

4. A session is exported.
Jonathan said, current practice is a simple directory copy.
Well ! Simple and not bad at all.
But what about the external files ?
Just make some symlinks for them ?


-- 
E.R.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] NSM - handling large files

[Emanuel Rumpf]

The discussion started, with the question about large files.

Keep it simple - store either files or links in the session folder ?
Why not ?

Some more opinions please.

-- 
E.R.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Non Session Management

[Emanuel Rumpf]

Am 28. März 2012 20:53 schrieb David Robillard :
>
> It's sooo complicated because it forces everything involved to use a
> special file finding and/or loading interface.
>
wrong - apps only tell the SM about files used externally - that's all.

> It also requires that central store to remain consistent, which is
> roughly infinity times harder than... well, not.
>
no matter where you store the files - you would want
the session to stay consistent

Forget the _central_ store.
I'm nowhere forcing that.

> Any program that deletes files based on some fantasy of omniscience ...
Where did you get that ?
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Non Session Management

[Emanuel Rumpf]

Am 29. März 2012 10:24 schrieb rosea.grammostola >
>
> How easy or how difficult is it compared to JackSession for example, to add
> NSM support to an application?
>

NSM is not more difficult.

Look at the yoshimi patch:
Include a class, add some handlers, set some options, that's it.
You have to know about OSC, but that's not hard.

-- 
E.R.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] HDSP 9652 and Behringer ADA8000

[Adrian Knoth]

On Wed, Mar 28, 2012 at 11:42:03PM +0200, Giso Grimm wrote:

> Recently I made a recording (lute & singing), partly with ADA8000,
> partly with RME Micstasy, both with the same Neumann mics, and I could
> barely hear the difference...

Which is hardly suprising. ;) I've found the following quote on the
internet:

--- cut here ---
Yes, ADA8000 is based on Alesis (now WaveFront Semiconductors) A/D
(AL1101), D/A (AL1201), an ADAT encoder (OptoGen AL1401) and an ADAT
receiver (OptoRec AL1402).

The ADA8000 is a copy of the RME AEB8-I (I had the scheme for it if you
want), and the scheme is simply an expansion to 8 channels (instead of
2) of the appnote given by Alesis for OptoGen and OptoRec.
--- and here again ---

I've already posted the following blind test:

   http://adi.loris.tv/converters/

One device is Lynx Aurora 16, the other one is Behringer ADA-8000.
No information was given whether A=Aurora and B=Behringer or vice versa,
and audio engineers were asked to judge.

They failed, the outcome was equally distributed, so it's fair to say
that not even trained ears were able to to hear a difference.

Neither can I.


Cheers

PS: The orig file was played from the DAW and re-recorded, thus
involving both - DACs and ADCs.

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Non Session Management

[rosea.grammostola]

On 03/29/2012 01:25 PM, thijs van severen wrote:



2012/3/29 rosea.grammostola mailto:rosea.grammost...@gmail.com>>

On 03/29/2012 01:16 PM, thijs van severen wrote:



2012/3/29 rosea.grammostola mailto:rosea.grammost...@gmail.com>
>>


On 03/29/2012 12:29 PM, thijs van severen wrote:



2012/3/29 Louigi Verona mailto:louigi.ver...@gmail.com>
>
com

>
__gm__ail.com 

 On 03/24/2012 11:09 PM, Fons Adriaensen wrote:
 >
 >>
 >> 3. Clearly defining the way an app should behave w.r.t. its
 >> File menu entries (when managed). This is quite intrusive
 >> to existing clients, but it is IMHO absolutley essential.
 >> Kudos to the designer(s) for the having the courage to do
 >> this instead of allowing application developers to take
 >> the 'least effort' way (which would of course be better
 >> marketing, but invite later misery).
 >
 > How easy or how difficult is it compared to JackSession for
example, to
 > add NSM support to an application?
 >
 > Is it possible to have NSM and JackSession support in one
application?
 >
 > Regards,
 >
 > \r



wasnt there a link somewhere in this mail thread about a
comparison of
all the pros and cons of 'all' SM's ?
i went trough the thread but could not find it  :-(
ah well, maybe i'm just dreaming
would be nice though, such a comparison matrix

Iirc it was just an idea to do make that. It doesn't exist yet.

An overview would be good imo. It would be even better if such a
matrix could help in making a decision for the best SM API to
support, at the moment. As a user who wants to use session
API X, I
don't have much benefits if applications supports session API Y.
Unless I decide to use Ladish, personally that wouldn't be
my choice
though.

IMHO making such a matrix is the only good way to make a
decisions of
any kind
is there anyone that has already made a 'study' that could be
used as
the basis of a comparison matrix ?


A matrix is nice for a quick overview, but for such a decision you
need more in depth information and argumentation. A matrix could
only function as a tool to help with the decision.


true, but currently we dont have any overview at all
any tool is better than no tool, right ?


We use a very old tool: dialogue, discussion and argumentation. :)

Another one: try out and find the pros and cons yourself

Sharing of user and developer experiences

Then there is the NSM API documentation and the JackSession documentation.


But if you want to make such a matrix, go ahead, but it might be harder 
to put it in a matrix then it looks at first sight.



\r

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Non Session Management

[thijs van severen]

2012/3/29 rosea.grammostola 

> On 03/29/2012 01:16 PM, thijs van severen wrote:
>
>>
>>
>> 2012/3/29 rosea.grammostola > >
>>
>>
>>On 03/29/2012 12:29 PM, thijs van severen wrote:
>>
>>
>>
>>2012/3/29 Louigi Verona >
>>> com >>>
>>
>>
>>
>>my 2 cents from user perspective: I know where I save my
>>files, I know
>>where my sample collections are. i know that if i delete my
>>sample
>>collection, sessions won't load. i don't need any program to
>>tell me
>>that.
>>
>>in fact, in using FL Studio or Cubase or LMMS you have the same
>>situation. a project can use same files as another project
>>and if you
>>damage those files - well, sorry.
>>
>>I do not see any reason for complications in session manager
>>design. i
>>agree with david, all of this is unnecessary and only will
>>make NSM a
>>session manager developers would be reluctant to adopt.
>>
>>louigi verona.
>>
>>On 3/29/12, rosea.grammostola >> >
>>
>>
>>>>
>> wrote:
>> > On 03/24/2012 11:09 PM, Fons Adriaensen wrote:
>> >
>> >>
>> >> 3. Clearly defining the way an app should behave w.r.t. its
>> >> File menu entries (when managed). This is quite intrusive
>> >> to existing clients, but it is IMHO absolutley essential.
>> >> Kudos to the designer(s) for the having the courage to do
>> >> this instead of allowing application developers to take
>> >> the 'least effort' way (which would of course be better
>> >> marketing, but invite later misery).
>> >
>> > How easy or how difficult is it compared to JackSession for
>>example, to
>> > add NSM support to an application?
>> >
>> > Is it possible to have NSM and JackSession support in one
>>application?
>> >
>> > Regards,
>> >
>> > \r
>>
>>
>>
>>wasnt there a link somewhere in this mail thread about a
>>comparison of
>>all the pros and cons of 'all' SM's ?
>>i went trough the thread but could not find it  :-(
>>ah well, maybe i'm just dreaming
>>would be nice though, such a comparison matrix
>>
>>Iirc it was just an idea to do make that. It doesn't exist yet.
>>
>>An overview would be good imo. It would be even better if such a
>>matrix could help in making a decision for the best SM API to
>>support, at the moment. As a user who wants to use session API X, I
>>don't have much benefits if applications supports session API Y.
>>Unless I decide to use Ladish, personally that wouldn't be my choice
>>though.
>>
>> IMHO making such a matrix is the only good way to make a decisions of
>> any kind
>> is there anyone that has already made a 'study' that could be used as
>> the basis of a comparison matrix ?
>>
>
> A matrix is nice for a quick overview, but for such a decision you need
> more in depth information and argumentation. A matrix could only function
> as a tool to help with the decision.


true, but currently we dont have any overview at all
any tool is better than no tool, right ?



follow me on my Audio & Linux blog  !
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Non Session Management

[rosea.grammostola]

On 03/29/2012 01:16 PM, thijs van severen wrote:



2012/3/29 rosea.grammostola mailto:rosea.grammost...@gmail.com>>

On 03/29/2012 12:29 PM, thijs van severen wrote:



2012/3/29 Louigi Verona mailto:louigi.ver...@gmail.com>
>>


my 2 cents from user perspective: I know where I save my
files, I know
where my sample collections are. i know that if i delete my
sample
collection, sessions won't load. i don't need any program to
tell me
that.

in fact, in using FL Studio or Cubase or LMMS you have the same
situation. a project can use same files as another project
and if you
damage those files - well, sorry.

I do not see any reason for complications in session manager
design. i
agree with david, all of this is unnecessary and only will
make NSM a
session manager developers would be reluctant to adopt.

louigi verona.

On 3/29/12, rosea.grammostola mailto:rosea.grammost...@gmail.com>
>> wrote:
 > On 03/24/2012 11:09 PM, Fons Adriaensen wrote:
 >
 >>
 >> 3. Clearly defining the way an app should behave w.r.t. its
 >> File menu entries (when managed). This is quite intrusive
 >> to existing clients, but it is IMHO absolutley essential.
 >> Kudos to the designer(s) for the having the courage to do
 >> this instead of allowing application developers to take
 >> the 'least effort' way (which would of course be better
 >> marketing, but invite later misery).
 >
 > How easy or how difficult is it compared to JackSession for
example, to
 > add NSM support to an application?
 >
 > Is it possible to have NSM and JackSession support in one
application?
 >
 > Regards,
 >
 > \r



wasnt there a link somewhere in this mail thread about a
comparison of
all the pros and cons of 'all' SM's ?
i went trough the thread but could not find it  :-(
ah well, maybe i'm just dreaming
would be nice though, such a comparison matrix

Iirc it was just an idea to do make that. It doesn't exist yet.

An overview would be good imo. It would be even better if such a
matrix could help in making a decision for the best SM API to
support, at the moment. As a user who wants to use session API X, I
don't have much benefits if applications supports session API Y.
Unless I decide to use Ladish, personally that wouldn't be my choice
though.

IMHO making such a matrix is the only good way to make a decisions of
any kind
is there anyone that has already made a 'study' that could be used as
the basis of a comparison matrix ?


A matrix is nice for a quick overview, but for such a decision you need 
more in depth information and argumentation. A matrix could only 
function as a tool to help with the decision.


\r



___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Non Session Management

[thijs van severen]

2012/3/29 rosea.grammostola 

> On 03/29/2012 12:29 PM, thijs van severen wrote:
>
>>
>>
>> 2012/3/29 Louigi Verona > >
>>
>>
>>my 2 cents from user perspective: I know where I save my files, I know
>>where my sample collections are. i know that if i delete my sample
>>collection, sessions won't load. i don't need any program to tell me
>>that.
>>
>>in fact, in using FL Studio or Cubase or LMMS you have the same
>>situation. a project can use same files as another project and if you
>>damage those files - well, sorry.
>>
>>I do not see any reason for complications in session manager design. i
>>agree with david, all of this is unnecessary and only will make NSM a
>>session manager developers would be reluctant to adopt.
>>
>>louigi verona.
>>
>>On 3/29/12, rosea.grammostola >>
>> wrote:
>> > On 03/24/2012 11:09 PM, Fons Adriaensen wrote:
>> >
>> >>
>> >> 3. Clearly defining the way an app should behave w.r.t. its
>> >> File menu entries (when managed). This is quite intrusive
>> >> to existing clients, but it is IMHO absolutley essential.
>> >> Kudos to the designer(s) for the having the courage to do
>> >> this instead of allowing application developers to take
>> >> the 'least effort' way (which would of course be better
>> >> marketing, but invite later misery).
>> >
>> > How easy or how difficult is it compared to JackSession for
>>example, to
>> > add NSM support to an application?
>> >
>> > Is it possible to have NSM and JackSession support in one
>>application?
>> >
>> > Regards,
>> >
>> > \r
>>
>>
>>
>> wasnt there a link somewhere in this mail thread about a comparison of
>> all the pros and cons of 'all' SM's ?
>> i went trough the thread but could not find it  :-(
>> ah well, maybe i'm just dreaming
>> would be nice though, such a comparison matrix
>>
>>  Iirc it was just an idea to do make that. It doesn't exist yet.
>
> An overview would be good imo. It would be even better if such a matrix
> could help in making a decision for the best SM API to support, at the
> moment. As a user who wants to use session API X, I don't have much
> benefits if applications supports session API Y. Unless I decide to use
> Ladish, personally that wouldn't be my choice though.
>
>
IMHO making such a matrix is the only good way to make a decisions of any
kind
is there anyone that has already made a 'study' that could be used as the
basis of a comparison matrix ?
thijs


-- 

follow me on my Audio & Linux blog  !
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Non Session Management

[rosea.grammostola]

On 03/29/2012 11:41 AM, rosea.grammostola wrote:

On 03/29/2012 12:02 PM, Louigi Verona wrote:

my 2 cents from user perspective: I know where I save my files, I know
where my sample collections are. i know that if i delete my sample
collection, sessions won't load. i don't need any program to tell me
that.

in fact, in using FL Studio or Cubase or LMMS you have the same
situation. a project can use same files as another project and if you
damage those files - well, sorry.


Ah your reply was a reaction on the 'saving large file in NSM 
discussion'. I would suggest you to quote the relevant part of the 
discussion and then type your reply, otherwise it's hard follow the 
discussion(s).


\r






Where are we talking about? The fact that the session manager manages
the saving of the projects only? E.g. that's not possible to save a
yoshimi 'project' from the GUI in Yoshimi when Yoshimi is in a session.
(see below for details ***)

It's a good thing to discuss indeed!

The situation with a session is different I think. In your examples you
use one application. In a Ardour session files are stored in the project
folder normally.

With a session you use more then one different applications, that's
makes the stuff rather complex. I see an good point in making the
situation less complex for and by the SM.
Afaik you can do with your files what you want, by copying or moving
from the NON Session folder.
I also expect that an Ardour project saved in a NSM session, can also be
opened by Ardour without being in a NSM session.
Also I guess it will be still possible to export files (and import) from
Ardour to anywhere you want, if Ardour would be in a NSM session.

An example why this can be useful is the problems I had using
JackSession with Hydrogen. Hydrogen didn't do the saving of the session
folder and the hydrogen project right. This was probably avoided when
they added NSM and followed the strict rules of it.




I do not see any reason for complications in session manager design. i
agree with david, all of this is unnecessary and only will make NSM a
session manager developers would be reluctant to adopt.


That's how you see it, but the question is, is this true? Maybe we
should let the developers speak for themselves. It would be good anyway
that they speak out.

It might be good if Jonathan Liles explains here why he has made the
choice.

\r


***

1.1.1. New

This option may empty/reset the current file or project (possibly after
user confirmation). UNDER NO CIRCUMSTANCES should it allow the user to
create a new project/file in another location.
1.1.2. Open

This option MUST be disabled.

The application may, however, elect to implement an option called
'Import into Session', creates a copy of a file/project which is then
saved at the session path provided by NSM.
1.1.3. Save

This option should behave as normal, saving the current file/project as
established by the NSM open message.

UNDER NO CIRCUMSTANCES should this option present the user with a choice
of where to save the file.
1.1.4. Save As

This option MUST be disabled.

The application may, however, elect to implement an option called
'Export from Session', which creates a copy of the current file/project
which is then saved in a user-specified location outside of the session
path provided by NSM.
1.1.5. Close (as distinguished from Quit or Exit)

This option MUST be disabled unless its meaning is to disconnect the
application from session management.
1.1.6. Quit or Exit

This option may behave as normal (possibly asking the user to confirm
exiting).



http://non.tuxfamily.org/nsm/API.html



















___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Non Session Management

[rosea.grammostola]

On 03/29/2012 12:29 PM, thijs van severen wrote:



2012/3/29 Louigi Verona mailto:louigi.ver...@gmail.com>>

my 2 cents from user perspective: I know where I save my files, I know
where my sample collections are. i know that if i delete my sample
collection, sessions won't load. i don't need any program to tell me
that.

in fact, in using FL Studio or Cubase or LMMS you have the same
situation. a project can use same files as another project and if you
damage those files - well, sorry.

I do not see any reason for complications in session manager design. i
agree with david, all of this is unnecessary and only will make NSM a
session manager developers would be reluctant to adopt.

louigi verona.

On 3/29/12, rosea.grammostola mailto:rosea.grammost...@gmail.com>> wrote:
 > On 03/24/2012 11:09 PM, Fons Adriaensen wrote:
 >
 >>
 >> 3. Clearly defining the way an app should behave w.r.t. its
 >> File menu entries (when managed). This is quite intrusive
 >> to existing clients, but it is IMHO absolutley essential.
 >> Kudos to the designer(s) for the having the courage to do
 >> this instead of allowing application developers to take
 >> the 'least effort' way (which would of course be better
 >> marketing, but invite later misery).
 >
 > How easy or how difficult is it compared to JackSession for
example, to
 > add NSM support to an application?
 >
 > Is it possible to have NSM and JackSession support in one
application?
 >
 > Regards,
 >
 > \r



wasnt there a link somewhere in this mail thread about a comparison of
all the pros and cons of 'all' SM's ?
i went trough the thread but could not find it  :-(
ah well, maybe i'm just dreaming
would be nice though, such a comparison matrix


Iirc it was just an idea to do make that. It doesn't exist yet.

An overview would be good imo. It would be even better if such a matrix 
could help in making a decision for the best SM API to support, at the 
moment. As a user who wants to use session API X, I don't have much 
benefits if applications supports session API Y. Unless I decide to use 
Ladish, personally that wouldn't be my choice though.


\r
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Non Session Management

[rosea.grammostola]

On 03/29/2012 12:02 PM, Louigi Verona wrote:

my 2 cents from user perspective: I know where I save my files, I know
where my sample collections are. i know that if i delete my sample
collection, sessions won't load. i don't need any program to tell me
that.

in fact, in using FL Studio or Cubase or LMMS you have the same
situation. a project can use same files as another project and if you
damage those files - well, sorry.



Where are we talking about? The fact that the session manager manages 
the saving of the projects only? E.g. that's not possible to save a 
yoshimi 'project' from the GUI in Yoshimi when Yoshimi is in a session. 
(see below for details ***)


It's a good thing to discuss indeed!

The situation with a session is different I think. In your examples you 
use one application. In a Ardour session files are stored in the project 
folder normally.


With a session you use more then one different applications, that's 
makes the stuff rather complex. I see an good point in making the 
situation less complex for and by the SM.
Afaik you can do with your files what you want, by copying or moving 
from the NON Session folder.
I also expect that an Ardour project saved in a NSM session, can also be 
opened by Ardour without being in a NSM session.
Also I guess it will be still possible to export files (and import) from 
Ardour to anywhere you want, if Ardour would be in a NSM session.


An example why this can be useful is the problems I had using 
JackSession with Hydrogen. Hydrogen didn't do the saving of the session 
folder and the hydrogen project right. This was probably avoided when 
they added NSM and followed the strict rules of it.





I do not see any reason for complications in session manager design. i
agree with david, all of this is unnecessary and only will make NSM a
session manager developers would be reluctant to adopt.


That's how you see it, but the question is, is this true? Maybe we 
should let the developers speak for themselves. It would be good anyway 
that they speak out.


It might be good if Jonathan Liles explains here why he has made the choice.

\r


***

1.1.1. New

This option may empty/reset the current file or project (possibly after 
user confirmation). UNDER NO CIRCUMSTANCES should it allow the user to 
create a new project/file in another location.

1.1.2. Open

This option MUST be disabled.

The application may, however, elect to implement an option called 
'Import into Session', creates a copy of a file/project which is then 
saved at the session path provided by NSM.

1.1.3. Save

This option should behave as normal, saving the current file/project as 
established by the NSM open message.


UNDER NO CIRCUMSTANCES should this option present the user with a choice 
of where to save the file.

1.1.4. Save As

This option MUST be disabled.

The application may, however, elect to implement an option called 
'Export from Session', which creates a copy of the current file/project 
which is then saved in a user-specified location outside of the session 
path provided by NSM.

1.1.5. Close (as distinguished from Quit or Exit)

This option MUST be disabled unless its meaning is to disconnect the 
application from session management.

1.1.6. Quit or Exit

This option may behave as normal (possibly asking the user to confirm 
exiting).




http://non.tuxfamily.org/nsm/API.html

















___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Non Session Management

[thijs van severen]

2012/3/29 Louigi Verona 

> my 2 cents from user perspective: I know where I save my files, I know
> where my sample collections are. i know that if i delete my sample
> collection, sessions won't load. i don't need any program to tell me
> that.
>
> in fact, in using FL Studio or Cubase or LMMS you have the same
> situation. a project can use same files as another project and if you
> damage those files - well, sorry.
>
> I do not see any reason for complications in session manager design. i
> agree with david, all of this is unnecessary and only will make NSM a
> session manager developers would be reluctant to adopt.
>
> louigi verona.
>
> On 3/29/12, rosea.grammostola  wrote:
> > On 03/24/2012 11:09 PM, Fons Adriaensen wrote:
> >
> >>
> >> 3. Clearly defining the way an app should behave w.r.t. its
> >> File menu entries (when managed). This is quite intrusive
> >> to existing clients, but it is IMHO absolutley essential.
> >> Kudos to the designer(s) for the having the courage to do
> >> this instead of allowing application developers to take
> >> the 'least effort' way (which would of course be better
> >> marketing, but invite later misery).
> >
> > How easy or how difficult is it compared to JackSession for example, to
> > add NSM support to an application?
> >
> > Is it possible to have NSM and JackSession support in one application?
> >
> > Regards,
> >
> > \r
>


wasnt there a link somewhere in this mail thread about a comparison of all
the pros and cons of 'all' SM's ?
i went trough the thread but could not find it  :-(
ah well, maybe i'm just dreaming
would be nice though, such a comparison matrix


follow me on my Audio & Linux blog  !
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Non Session Management

[Louigi Verona]

my 2 cents from user perspective: I know where I save my files, I know
where my sample collections are. i know that if i delete my sample
collection, sessions won't load. i don't need any program to tell me
that.

in fact, in using FL Studio or Cubase or LMMS you have the same
situation. a project can use same files as another project and if you
damage those files - well, sorry.

I do not see any reason for complications in session manager design. i
agree with david, all of this is unnecessary and only will make NSM a
session manager developers would be reluctant to adopt.

louigi verona.

On 3/29/12, rosea.grammostola  wrote:
> On 03/24/2012 11:09 PM, Fons Adriaensen wrote:
>
>>
>> 3. Clearly defining the way an app should behave w.r.t. its
>> File menu entries (when managed). This is quite intrusive
>> to existing clients, but it is IMHO absolutley essential.
>> Kudos to the designer(s) for the having the courage to do
>> this instead of allowing application developers to take
>> the 'least effort' way (which would of course be better
>> marketing, but invite later misery).
>
> How easy or how difficult is it compared to JackSession for example, to
> add NSM support to an application?
>
> Is it possible to have NSM and JackSession support in one application?
>
> Regards,
>
> \r
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>


-- 
Louigi Verona
http://www.louigiverona.ru/
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Non Session Management

[rosea.grammostola]

On 03/24/2012 11:09 PM, Fons Adriaensen wrote:



3. Clearly defining the way an app should behave w.r.t. its
File menu entries (when managed). This is quite intrusive
to existing clients, but it is IMHO absolutley essential.
Kudos to the designer(s) for the having the courage to do
this instead of allowing application developers to take
the 'least effort' way (which would of course be better
marketing, but invite later misery).


How easy or how difficult is it compared to JackSession for example, to 
add NSM support to an application?


Is it possible to have NSM and JackSession support in one application?

Regards,

\r
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev