It might be a good idea to discuss NSM (and it's implementation) and
compare it with other Session Managers, at LAC2012. Such a conference
could be a nice opportunity to share ideas to improve Linuxaudio session
management in general. Unfortunately I'm not able to attend this year.
For those
On 04/11/2012 08:42 AM, rosea.grammostola wrote:
It might be a good idea to discuss NSM (and it's implementation) and
compare it with other Session Managers, at LAC2012. Such a conference
could be a nice opportunity to share ideas to improve Linuxaudio
session management in general.
On 04/11/2012 03:18 PM, Dave Phillips wrote:
Hey Dirk,
We'll miss you ! I still tell people about the fellow who approached me
on a train platform in Dublin and asked if I was Dave Phillips.
Hehe, I did the same when I saw Bono standing at Dublin central. He
still tells his friends about it
On Wed, 11 Apr 2012 15:36:30 +0200
rosea.grammostola rosea.grammost...@gmail.com wrote:
On 04/11/2012 03:18 PM, Dave Phillips wrote:
Hey Dirk,
We'll miss you ! I still tell people about the fellow who
approached me on a train platform in Dublin and asked if I was Dave
Phillips.
On 04/06/2012 09:06 PM, Joel Roth wrote:
On Wed, Apr 04, 2012 at 10:12:53PM +0200, rosea.grammostola wrote:
Afaik, NSM gives us all we users need when it comes to LAU session
management Correct me if I'm wrong.
It would be great if the core functionality of NSM
could be separated out from
On Mon, Apr 09, 2012 at 05:27:54PM +0200, rosea.grammostola wrote:
Personally I saw it as an advantage of JackSession, that it has JACK
involved and that it only needs the JACK dependency. After the comments
by Fons and by trying NSM myself, I think that it is an advantage of NSM
On Mon, Apr 9, 2012 at 9:03 AM, Fons Adriaensen f...@linuxaudio.org wrote:
On Mon, Apr 09, 2012 at 05:27:54PM +0200, rosea.grammostola wrote:
Personally I saw it as an advantage of JackSession, that it has JACK
involved and that it only needs the JACK dependency. After the comments
by
On Mon, Apr 09, 2012 at 09:35:27AM -0700, J. Liles wrote:
This is true. Liblo is not a hard dependency. Anything that can
send/receive OSC messages should work. It definitely doesn't use wildcards
and I haven't actually found a use for OSC wildcards yet period,
Same here... In all cases where
On Fri, Apr 06, 2012 at 01:07:57PM -0700, J. Liles wrote:
On Fri, Apr 6, 2012 at 12:06 PM, Joel Roth jo...@pobox.com wrote:
On Wed, Apr 04, 2012 at 10:12:53PM +0200, rosea.grammostola wrote:
Afaik, NSM gives us all we users need when it comes to LAU session
management Correct me if
On Wed, Apr 04, 2012 at 10:12:53PM +0200, rosea.grammostola wrote:
Afaik, NSM gives us all we users need when it comes to LAU session
management Correct me if I'm wrong.
It would be great if the core functionality of NSM
could be separated out from the GUI to support
console users and
On Fri, Apr 6, 2012 at 12:06 PM, Joel Roth jo...@pobox.com wrote:
On Wed, Apr 04, 2012 at 10:12:53PM +0200, rosea.grammostola wrote:
Afaik, NSM gives us all we users need when it comes to LAU session
management Correct me if I'm wrong.
It would be great if the core functionality of NSM
On 04/05/2012 12:25 AM, David Robillard wrote:
On Tue, 2012-04-03 at 18:04 +0100, Rui Nuno Capela wrote:
[...]
ardour gets all its stuff under one own session directory, on a per
session/project basis, iirc just like NSM mandates,
bbbuut...:) making that one and the same directory as from
On Thu, Apr 05, 2012 at 12:14:03PM +0100, Rui Nuno Capela wrote:
from what I read on the NSM User API specs. you can only create new,
open and save NSM-managed sessions as in each participating client
project's sub-directories. existing individual projects are out of the
picture.
On 04/05/2012 01:16 PM, Fons Adriaensen wrote:
On Thu, Apr 05, 2012 at 12:14:03PM +0100, Rui Nuno Capela wrote:
from what I read on the NSM User API specs. you can only create new,
open and save NSM-managed sessions as in each participating client
project's sub-directories. existing
On Thu, Apr 05, 2012 at 03:19:24PM +0100, Rui Nuno Capela wrote:
On 04/05/2012 01:16 PM, Fons Adriaensen wrote:
On Thu, Apr 05, 2012 at 12:14:03PM +0100, Rui Nuno Capela wrote:
from what I read on the NSM User API specs. you can only create new,
open and save NSM-managed sessions as in each
On 04/05/2012 03:48 PM, Fons Adriaensen wrote:
On Thu, Apr 05, 2012 at 03:19:24PM +0100, Rui Nuno Capela wrote:
On 04/05/2012 01:16 PM, Fons Adriaensen wrote:
On Thu, Apr 05, 2012 at 12:14:03PM +0100, Rui Nuno Capela wrote:
from what I read on the NSM User API specs. you can only create
On Thu, 2012-04-05 at 17:20 +0100, Rui Nuno Capela wrote:
[...]
re. (2) then i concur with you when Open and Save(As...) shall be
enabled *but* having different code-paths, behavior or internal
semantics if you prefer, when in managed than in native/original aka.
non-managed modes. chalked!
On Thu, 2012-04-05 at 12:14 +0100, Rui Nuno Capela wrote:
On 04/05/2012 12:25 AM, David Robillard wrote:
On Tue, 2012-04-03 at 18:04 +0100, Rui Nuno Capela wrote:
[...]
ardour gets all its stuff under one own session directory, on a per
session/project basis, iirc just like NSM mandates,
On Thu, 05 Apr 2012 12:14:03 +0100
Rui Nuno Capela rn...@rncbc.org wrote:
iow. what if, assuming Ardour were about a fully-compliant NSM client
and you want to open an existing Ardour session, one you've been working
hard previously but stand-lone ie. outside the NSM umbrella? i read that
On Thu, Apr 5, 2012 at 10:48 AM, David Robillard d...@drobilla.net wrote:
On Thu, 2012-04-05 at 12:14 +0100, Rui Nuno Capela wrote:
On 04/05/2012 12:25 AM, David Robillard wrote:
On Tue, 2012-04-03 at 18:04 +0100, Rui Nuno Capela wrote:
[...]
ardour gets all its stuff under one own
On Thu, 2012-04-05 at 11:14 -0700, J. Liles wrote:
[...]
Dealing with existing projects is what the optional Import to
Session and Export from Session commands are there for. These are
basically Open and Save As but with *defined* semantics.
My mistake, I was just going by what Rui wrote
On 04/05/2012 07:14 PM, J. Liles wrote:
On Thu, Apr 5, 2012 at 10:48 AM, David Robillard d...@drobilla.net
mailto:d...@drobilla.net wrote:
On Thu, 2012-04-05 at 12:14 +0100, Rui Nuno Capela wrote:
On 04/05/2012 12:25 AM, David Robillard wrote:
On Tue, 2012-04-03 at 18:04
Guys, I read about JACK Session, tried it out. It does seem very capable.
And if more apps add support (which, as people say in this discussion, is
not that difficult), wouldn't JACK Session be a good, stable way to restore
sessions? After all, JACK is a basic thing for Linux Audio and adding
Am 4. April 2012 08:11 schrieb Louigi Verona louigi.ver...@gmail.com:
Am I missing something here?
Yes,
search the archives.
or visit
http://wiki.linuxaudio.org/wiki/user/emrum/jack_session_2_draft
to see,
what NSM tries to improve, by imposing some meaningful rules.
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
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
On 04/04/2012 02:22 PM, Rui Nuno Capela 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
Am 4. April 2012 11:18 schrieb rosea.grammostola rosea.grammost...@gmail.com:
How much more effort will it be in terms of coding, to implement 'level-1'
versus 'level-0'?
For anyone who prefers to work with apps-do-whatever-they-want appraoch
or
On Wed, Apr 04, 2012 at 01:25:02PM +, Emanuel Rumpf wrote:
For anyone who prefers to work with apps-do-whatever-they-want appraoch
or we-have-zero-to-X-support-levels-so-you-dont-know-what-to-expect ,
there are alternatives: JackSession, Lash, Ladish.
I would prefere at least *one* SM
On 04/04/2012 03:51 PM, Fons Adriaensen wrote:
if ever I add session management to any
app then that app will obey the NSM rules or very similar
ones if the session manager is not NSM - it is the obvious
thing to do if you want something that works.
Could you elaborate your reasons for this,
On 04/04/2012 01:35 PM, rosea.grammostola wrote:
On 04/04/2012 02:22 PM, Rui Nuno Capela 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:
-
On 04/04/2012 04:39 PM, Rui Nuno Capela wrote:
Another question. If you compare NSM level 0 (!) with JackSession. Which
session manager do you prefer and why?
well, NSM level 0 adds nothing to what JSM already delivers. sorry for
the noise :)
the once self-called uber-procrastinator says:
On 04/04/2012 04:55 PM, rosea.grammostola wrote:
On 04/04/2012 04:39 PM, Rui Nuno Capela wrote:
Another question. If you compare NSM level 0 (!) with JackSession. Which
session manager do you prefer and why?
well, NSM level 0 adds nothing to what JSM already delivers. sorry for
the noise :)
On 04/04/2012 03:55 PM, rosea.grammostola wrote:
On 04/04/2012 04:39 PM, Rui Nuno Capela wrote:
Another question. If you compare NSM level 0 (!) with JackSession. Which
session manager do you prefer and why?
well, NSM level 0 adds nothing to what JSM already delivers. sorry for
the noise :)
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
On 04/04/2012 05:46 PM, Rui Nuno Capela wrote:
On 04/04/2012 03:55 PM, rosea.grammostola wrote:
On 04/04/2012 04:39 PM, Rui Nuno Capela wrote:
Another question. If you compare NSM level 0 (!) with JackSession.
Which
session manager do you prefer and why?
well, NSM level 0 adds nothing to
On Wed, Apr 04, 2012 at 04:37:59PM +0200, rosea.grammostola wrote:
Could you elaborate your reasons for this, for those who don't see this
as obvious?
I could. But it wouldn't help anyone.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream,
On 04/04/2012 05:19 PM, J. Liles wrote:
On Wed, Apr 4, 2012 at 5:22 AM, Rui Nuno Capela rn...@rncbc.org
mailto: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
On 04/04/2012 05:19 PM, rosea.grammostola wrote:
... On that topic I conclude that Qjackctl doesn't support infra
clients by purpose and that I don't see it happen that there will be
another GUI who does support in the near future.
wait, it's not by purpose but just overlooked ok?
On 04/04/2012 08:51 PM, Rui Nuno Capela wrote:
On 04/04/2012 05:19 PM, rosea.grammostola wrote:
... On that topic I conclude that Qjackctl doesn't support infra
clients by purpose and that I don't see it happen that there will be
another GUI who does support in the near future.
wait, it's
On 04/04/2012 09:59 PM, rosea.grammostola wrote:
But of course, this are not the only reason to prefer one SM above the
other. As mentioned in my previous mails, there are arguments for me atm
to say that NSM gives a user more then JackSession (even with the
hypothetical level-0). NSM seems to
On Wed, Apr 04, 2012 at 09:19:57AM -0700, J. Liles wrote:
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
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
On Wed, Apr 4, 2012 at 1:48 PM, Fons Adriaensen f...@linuxaudio.org wrote:
On Wed, Apr 04, 2012 at 09:19:57AM -0700, J. Liles wrote:
Are you seriously saying that the equivalent of doing:
if ( nsm_is_active )
save_here( file );
else
save_there( file );
Would require
On Wed, Apr 4, 2012 at 3:22 PM, J. Liles malnour...@gmail.com wrote:
On Wed, Apr 4, 2012 at 1:48 PM, Fons Adriaensen f...@linuxaudio.orgwrote:
On Wed, Apr 04, 2012 at 09:19:57AM -0700, J. Liles wrote:
Are you seriously saying that the equivalent of doing:
if ( nsm_is_active )
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
On Tue, 2012-04-03 at 18:04 +0100, Rui Nuno Capela wrote:
[...]
ardour gets all its stuff under one own session directory, on a per
session/project basis, iirc just like NSM mandates,
bbbuut...:) making that one and the same directory as from an
outsider/independent session manager
Am 2. April 2012 20:05 schrieb Emanuel Rumpf xb...@web.de:
NSM has some nice rules already, to make things behave smooth.
Now add a few sensible rules, to make sure that
audio-file management works equally well.
These are really very simple points, I say.
Proposing a few simple
- offer accaptable integrity.
All further, extended functionality (export, import, copy, ...)
could then become part of a script or of version 2.0 of NSM.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
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
On Tue, 3 Apr 2012 07:04:55 +
Emanuel Rumpf xb...@web.de wrote many things.
Emanuel,
why don't you write your own Session Manager (Protocol)?
You seem to be very knowledgable.
Nils
___
Linux-audio-dev mailing list
On 04/03/2012 10:05 AM, rncbc wrote:
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
On 04/03/2012 11:38 AM, rosea.grammostola wrote:
On 04/03/2012 10:05 AM, rncbc wrote:
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,
On 03.04.2012 10:38, rosea.grammostola wrote:
On 04/03/2012 10:05 AM, rncbc wrote:
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,
On 04/03/2012 02:55 PM, rosea.grammostola wrote:
On 04/03/2012 11:51 AM, rncbc wrote:
On 03.04.2012 10:38, rosea.grammostola wrote:
On 04/03/2012 10:05 AM, rncbc wrote:
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
Am 3. April 2012 09:21 schrieb Nils l...@nilsgey.de:
why don't you write your own Session Manager (Protocol)?
You seem to be very knowledgable.
I did not write a whole sequencer app yet, that's why I don't call
that utopian ;)
But Riu did.
- I'm not able to do it better than NSM
- we do not
Guys, is there any info on JACK Session state? What apps are supported? How
to use?
--
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
On 04/03/2012 04:18 PM, Louigi Verona wrote:
Guys, is there any info on JACK Session state? What apps are supported?
How to use?
http://tangostudio.tuxfamily.org/en/documentations/jacksession
___
Linux-audio-dev mailing list
On 04/03/2012 01:55 PM, rosea.grammostola wrote:
On 04/03/2012 11:51 AM, rncbc wrote:
On 03.04.2012 10:38, rosea.grammostola wrote:
On 04/03/2012 10:05 AM, rncbc wrote:
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
On Tue, Apr 3, 2012 at 6:35 AM, rosea.grammostola
rosea.grammost...@gmail.com wrote:
[quote=Liles]
Currently one of the strong points of NSM is that applications with heavy
state (e.g. large audio files) know *exactly* where to put the state at the
time they join the session. This eliminates
On Tue, Apr 3, 2012 at 10:04 AM, Rui Nuno Capela rn...@rncbc.org wrote:
jack-session has some fsck-up restrictions of its own
one that i had historical complaints is about this non-reusable session
directory restriction (here, the non particle, is not a pun;) which meant
that you can't save
On 03/30/2012 12:27 PM, Paul Davis wrote:
re: the central media location - in rui's defense i'd like to point
out that it took cubase more than 10 years to move away from something
fairly close to his model.
Ok, that will be 5 yrs for Rui then ;)
Serious though. What does this mean for
On Mon, Apr 2, 2012 at 9:11 AM, rosea.grammostola
rosea.grammost...@gmail.com wrote:
On 03/30/2012 12:27 PM, Paul Davis wrote:
re: the central media location - in rui's defense i'd like to point
out that it took cubase more than 10 years to move away from something
fairly close to his model.
Am 2. April 2012 19:17 schrieb J. Liles malnour...@gmail.com:
Anyway,
from my perspective, correcting the problem is as simple as adding a
rule to the NSM API that states:
* When connected to a session, the client *MUST* store all new media
(recorded audio, etc.) related to the open project
nb. all this applies whether the external files symlinking are
implemented or not (will that be an option or shall be mandatory by SM
protocol design?);
Do all target filesystems support symbolic links?
___
Linux-audio-dev mailing list
Am 2. April 2012 20:39 schrieb Paul Giblock pgib...@gmail.com:
Do all target filesystems support symbolic links?
yeah ? what would happen to the links, if one copied the session
folder to his/her fat32 usb-stick ?
simply don't !! ?
or de-reference...
--
E.R.
On Mon, Apr 2, 2012 at 12:07 PM, Paul Giblock pgib...@gmail.com wrote:
I didn't necessarily mean for transport or archival. I imagine just
dereference it is one of the motivations for links in the first place. I
was more concerned about windows users, or people with large external
(fat32)
On Mon, Apr 2, 2012 at 11:29 AM, Emanuel Rumpf xb...@web.de wrote:
I thought - that's what we would not want: store large files in the
session dir !?
because duplicating a session should stay a light and fast process.
Personally, I'm fine with having large files in my session
directories.
On Mon, Apr 2, 2012 at 3:11 PM, J. Liles malnour...@gmail.com wrote:
On Mon, Apr 2, 2012 at 12:07 PM, Paul Giblock pgib...@gmail.com wrote:
I didn't necessarily mean for transport or archival. I imagine just
dereference it is one of the motivations for links in the first place.
I
was more
Can't agree with that. USB Thumb Drives for instance are still one of the
most common ways to transport sessions and other data and are often
formatted FAT32 for interoperability purposes.
Seablade
Luckily tar files do support symlinks. Some folks even create a ext2
fs formatted
Am 2. April 2012 21:22 schrieb J. Liles malnour...@gmail.com:
Personally, I'm fine with having large files in my session
directories. In fact, that's exactly where I want them.
Why would one
want to duplicate a session with a lot of pre-recorded audio?
Maybe with recorded audio, you wouldn't
A new thought:
Lets say we did store the session as tar.gz,
and we de-referenced the symlinks.
Means: We have all files related to the session th the tar.gz.
So far, so good.
Now we re-import the session to NSM:
We extract that tar.gz in the NSM sessions-folder.
Note: instead of symlinks we
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.
--
On 03/30/2012 03:48 AM, J. Liles wrote:
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
re: the central media location - in rui's defense i'd like to point
out that it took cubase more than 10 years to move away from something
fairly close to his model.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
Am 30. März 2012 03:29 schrieb J. Liles malnour...@gmail.com:
If all Linux Audio software dealt with external references in this
way, archiving/export would be much less problematic.
Finding a solution for externals, was the whole point of this discussion.
After all the many arguments, I'm
On Fri, Mar 30, 2012 at 05:31:57PM +0200, Emanuel Rumpf wrote:
Am 30. März 2012 03:29 schrieb J. Liles malnour...@gmail.com:
If all Linux Audio software dealt with external references in this
way, archiving/export would be much less problematic.
Finding a solution for externals, was
On Fri, Mar 30, 2012 at 09:07:07PM +0200, Lieven Moors wrote:
Would there be anything against using hard links?
A hard link makes the file pointed to part of the session
directory, just as moving or copying the file would. There
is no difference between a hard link and the original - both
are
Personally I prefer Ardour's behavior myself. I do keep my samples on an
external drive, but in the end the ability to maintain a self-contained
session for portability purposes is important to me. But to each their own.
Seablade
On Fri, Mar 30, 2012 at 4:53 PM, Fons Adriaensen
On Fri, Mar 30, 2012 at 05:14:50PM -0400, Thomas Vecchione wrote:
Personally I prefer Ardour's behavior myself. I do keep my samples on an
external drive, but in the end the ability to maintain a self-contained
session for portability purposes is important to me.
You always have that
Not awake enough to debate here, but my memory and your's of Ardour's
behavior doesn't seem to be matching up I don't believe. But I ened more
sleep before I really dig into that.
Seablade
On Fri, Mar 30, 2012 at 5:27 PM, Fons Adriaensen f...@linuxaudio.orgwrote:
On Fri, Mar 30, 2012 at
On Fri, 2012-03-30 at 20:53 +, Fons Adriaensen wrote:
On Fri, Mar 30, 2012 at 09:07:07PM +0200, Lieven Moors wrote:
Would there be anything against using hard links?
Nedko mentioned this idea on IRC as well...
Apart from that, hard links are possible only within the
same file system.
On Fri, Mar 30, 2012 at 08:53:26PM +, Fons Adriaensen wrote:
On Fri, Mar 30, 2012 at 09:07:07PM +0200, Lieven Moors wrote:
Would there be anything against using hard links?
A hard link makes the file pointed to part of the session
directory, just as moving or copying the file would.
On 03/30/2012 10:27 PM, Fons Adriaensen wrote:
On Fri, Mar 30, 2012 at 05:14:50PM -0400, Thomas Vecchione wrote:
Personally I prefer Ardour's behavior myself. I do keep my samples on an
external drive, but in the end the ability to maintain a self-contained
session for portability purposes is
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
Am 29. März 2012 15:34 schrieb Emanuel Rumpf xb...@web.de:
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
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.
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.
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
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
On Thu, Mar 29, 2012 at 4:40 PM, David Robillard d...@drobilla.net 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 :)
On Thu, Mar 29, 2012 at 2:23 PM, Rui Nuno Capela rn...@rncbc.org 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
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
93 matches
Mail list logo
