export hangs in v2.3

[Jason Schaefer-2]

Hello

I have a project with 7 tracks. 6 of the tracks I want to export and I
have cd range markers set. When I export it, sometimes it exports all
6 and the first one is correct the second is a digital sine sounding
noise and the others are silent. Other times it exports 1 or 2 silent
tracks and hangs. Now when I click the export it writes a 44byte wav
and hangs.

Something possibly related... my 1st track, that I am not exporting,
is really long. I ended the range markers at the end of track 7 and
export still went through the motion of exporting the entire project
(end of track1). I thought I would move the "end" marker up to the end
of track 7 so the export would stop but it still goes to the end track
1. Seems the export should stop at the last range marker or the end
marker.  Anyways, the problem just got worse the more I do, so I'm
writing you.

Also, I do get a message about memory limits (ulimit -l 250000), I
have 1.5gb physical memory. Should I change my memory limit?

Thanks for your help, let me know if you need anything more from me.
_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[John Emmas]

Hi Paul,

Just updated this morning to Ardour SVN 3134.  First, a heads-up.  Ardour
now seems to require a library called "aubio" but this isn't mentioned among
the build dependencies (http://ardour.org/building).

Secondly, when compiling the following module :-

libs/ardour/globals.cc

I get this error :-

In function 'ARDOUR::microseconds_t ARDOUR::get_microseconds()':
libs/ardour/globals.cc:386: error: 'jack_get_time' was not declared in this
scope

Anything I might have missed?

Thanks,

John

_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[John Emmas]

----- Original Message -----
From: "John Emmas" <johne53@...>
Subject: [Ardour-Dev] SVN 3134
>
> libs/ardour/globals.cc:386: error: 'jack_get_time' was not declared in
> this scope
>
There's a comment in libs/ardour/ardour/ardour.h that Jack has been
exporting the function jack_get_time() for a long time.  However, I can't
find anything to support that.  Do I need to upgrade libjack?  My current
version is 0.103.0-6

John




----- Original Message -----
From: "John Emmas" <johne53@...>
To: <ardour-dev@...>
Sent: 13 June 2008 14:45
Subject: [Ardour-Dev] SVN 3134

> Hi Paul,
>
> Just updated this morning to Ardour SVN 3134.  First, a heads-up.  Ardour
> now seems to require a library called "aubio" but this isn't mentioned
> among
> the build dependencies (http://ardour.org/building).
>
> Secondly, when compiling the following module :-
>
> libs/ardour/globals.cc
>
> I get this error :-
>
> In function 'ARDOUR::microseconds_t ARDOUR::get_microseconds()':
> libs/ardour/globals.cc:386: error: 'jack_get_time' was not declared in
> this
> scope
>
> Anything I might have missed?
>
> Thanks,
>
> John
>
> _______________________________________________
> ardour-dev mailing list
> ardour-dev@...
> http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[Paul Davis]

On Fri, 2008-06-13 at 18:51 +0000, John Emmas wrote:

> ----- Original Message -----
> From: "John Emmas" <johne53@...>
> Subject: [Ardour-Dev] SVN 3134
> >
> > libs/ardour/globals.cc:386: error: 'jack_get_time' was not declared in
> > this scope
> >
> There's a comment in libs/ardour/ardour/ardour.h that Jack has been
> exporting the function jack_get_time() for a long time.  However, I can't
> find anything to support that.  Do I need to upgrade libjack?  My current
> version is 0.103.0-6

JACK SVN is currently at 0.111.5


_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[John Emmas]

----- Original Message -----
From: "Paul Davis" <paul@...>
Subject: Re: [Ardour-Dev] SVN 3134
>
> JACK SVN is currently at 0.111.5
>
Hi Paul,

I managed to upgrade to 0.110.0 (which is apparently the most recent version
to be still compatible with 64studio) and it solved the problem.  However,
you might want to update this web page :-

http://ardour.org/building

which is still showing 0.100 as being the minimum requirement for libjack.

John



----- Original Message -----
From: "Paul Davis" <paul@...>
To: "John Emmas" <johne53@...>
Cc: <ardour-dev@...>
Sent: 13 June 2008 19:01
Subject: Re: [Ardour-Dev] SVN 3134

>
> On Fri, 2008-06-13 at 18:51 +0000, John Emmas wrote:
>> ----- Original Message -----
>> From: "John Emmas" <johne53@...>
>> Subject: [Ardour-Dev] SVN 3134
>> >
>> > libs/ardour/globals.cc:386: error: 'jack_get_time' was not declared in
>> > this scope
>> >
>> There's a comment in libs/ardour/ardour/ardour.h that Jack has been
>> exporting the function jack_get_time() for a long time.  However, I can't
>> find anything to support that.  Do I need to upgrade libjack?  My current
>> version is 0.103.0-6
>
> JACK SVN is currently at 0.111.5
>
>

_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[Rich E]

This was something that had stopped me for quite some time from compiling ardour from svn . I use jack from the ubuntu repositories, and ardour always seems to be ahead of them. For about 1 month, I was able to compile ardour with  libjack-0.103.0 from the gutsy repositories... but no longer.  Now it seems that, once again, if I want to use anything other later than 2.41 (which had lots of bugs in my experience), I need to uninstall all ubuntu/ubuntu-studio packages and compile from source.  What a drag.. so much that I gave up on beta-testing ardour.

It is one thing that the 3.0 branch is using jack from svn, but why make 2-ongoing depend on unstable packages as well? What happens when 2.5 comes out and no one can use it because their jack version isn't new enough?

Maybe there are steps to be taken before this happens that I am unaware of.

-rich

On Sat, Jun 14, 2008 at 12:23 AM, John Emmas <johne53@...> wrote:

----- Original Message ----- From: "Paul Davis" <paul@...>
Subject: Re: [Ardour-Dev] SVN 3134

JACK SVN is currently at 0.111.5

Hi Paul,

I managed to upgrade to 0.110.0 (which is apparently the most recent version
to be still compatible with 64studio) and it solved the problem.  However,
you might want to update this web page :-

http://ardour.org/building

which is still showing 0.100 as being the minimum requirement for libjack.

John



----- Original Message ----- From: "Paul Davis" <paul@...>
To: "John Emmas" <johne53@...>
Cc: <ardour-dev@...>
Sent: 13 June 2008 19:01
Subject: Re: [Ardour-Dev] SVN 3134

On Fri, 2008-06-13 at 18:51 +0000, John Emmas wrote:

----- Original Message ----- From: "John Emmas" <johne53@...>
Subject: [Ardour-Dev] SVN 3134
>
> libs/ardour/globals.cc:386: error: 'jack_get_time' was not declared in
> this scope
>
There's a comment in libs/ardour/ardour/ardour.h that Jack has been
exporting the function jack_get_time() for a long time.  However, I can't
find anything to support that.  Do I need to upgrade libjack?  My current
version is 0.103.0-6

JACK SVN is currently at 0.111.5

_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[Paul Davis]

On Sun, 2008-06-15 at 19:20 -0700, Rich E wrote:

> This was something that had stopped me for quite some time from
> compiling ardour from svn . I use jack from the ubuntu repositories,
> and ardour always seems to be ahead of them. For about 1 month, I was
> able to compile ardour with  libjack-0.103.0 from the gutsy
> repositories... but no longer.  Now it seems that, once again, if I
> want to use anything other later than 2.41 (which had lots of bugs in
> my experience), I need to uninstall all ubuntu/ubuntu-studio packages
> and compile from source.  What a drag.. so much that I gave up on
> beta-testing ardour.
>
> It is one thing that the 3.0 branch is using jack from svn, but why
> make 2-ongoing depend on unstable packages as well? What happens when
> 2.5 comes out and no one can use it because their jack version isn't
> new enough?

people who use packages won't get packages till the distribution package
maintainers build them and update the dependencies. people who build
from source will either build from source or wait. what else can we do?

> Maybe there are steps to be taken before this happens that I am
> unaware of.

we cannot be responsible for what versions of JACK are packaged with a
given distribution.  note that JACK 0.109.2 was released in January of
2008, almost 6 months ago. If a distribution has not caught up with that
version, then all we can really do is say "don't bother to try to use
this distribution for beta-testing ardour".


_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[Fernando Lopez-Lezcano]

On Sun, 2008-06-15 at 23:10 -0400, Paul Davis wrote:

> On Sun, 2008-06-15 at 19:20 -0700, Rich E wrote:
> > This was something that had stopped me for quite some time from
> > compiling ardour from svn . I use jack from the ubuntu repositories,
> > and ardour always seems to be ahead of them. For about 1 month, I was
> > able to compile ardour with  libjack-0.103.0 from the gutsy
> > repositories... but no longer.  Now it seems that, once again, if I
> > want to use anything other later than 2.41 (which had lots of bugs in
> > my experience), I need to uninstall all ubuntu/ubuntu-studio packages
> > and compile from source.  What a drag.. so much that I gave up on
> > beta-testing ardour.
> >
> > It is one thing that the 3.0 branch is using jack from svn, but why
> > make 2-ongoing depend on unstable packages as well? What happens when
> > 2.5 comes out and no one can use it because their jack version isn't
> > new enough?
>
> people who use packages won't get packages till the distribution package
> maintainers build them and update the dependencies. people who build
> from source will either build from source or wait. what else can we do?
>
> > Maybe there are steps to be taken before this happens that I am
> > unaware of.
>
> we cannot be responsible for what versions of JACK are packaged with a
> given distribution.  note that JACK 0.109.2 was released in January of
> 2008, almost 6 months ago. If a distribution has not caught up with that
> version, then all we can really do is say "don't bother to try to use
> this distribution for beta-testing ardour".

Well, ahem, if a distribution wants to have a stable jack for production
use 0.109.2 is not an option. It has known problems (that may have just
been solved in svn). So it is not as simple as pictured.

-- Fernando


_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[John Emmas]

Hi all,

Earlier in the year I completed the functionality for an Ardour "session
merger" whereby two Ardour sessions can me merged together.  In fact, if one
of the sessions was non-existent, it could also provide a "Save As" feature
(allowing a session to be renamed) although I haven't got that far yet.

Being a Windows programmer, I haven't yet tackled a GUI for Ardour.  In
fact, the only step I've taken is to buy a book about GTK+ development and
I'm trying to get to grips with some of the concepts.  The book I bought is
called "Foundations of GTK+ Development" by Andrew Krause and although
it's well written and authoritative, I can't help noticing that some of its
concepts would be considered total herecy for a Windows programmer!!  ;-)
For example, under Windows, there's an underlying principle that you never
store (or pass around) pointers to window objects.  Because the OS can swap
these objects to disk and back, you should never assume that they'll be
swapped back to the same physical memory addresses from whence they came.

Of course, modern versions of Windows use a 'virtual machine' addressing
model which alleviates this problem to a great extent.  Nevertheless, it's
considered 'bad form' to assume that GUI object addresses will remain
persistent.  Windows maintains handles for objects (which DO remain
persistent).  Therefore, if you need the address of a GUI object, you find
it out from knowing its handle.  I just wondered if there was any similar
concept in GTK+.  I can't see anything from my book but I don't want to
start programming with a fundamental misconception as big as this.

Another thing I've noticed is that GTK+ seem to be remarkably 'non'
object-oriented.  There seems to be a heavy reliance on global functions
which get used to manipulate objects, rather than the objects knowing how to
manipulate themselves.  Even the most basic things like object placement,
or setting the text for an object - these actions seem to be unknown to the
objects themselves.  Is this a concept that I'll just have to get used to or
should I buy another book??

Thanks,

John

_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[Paul Davis]

On Mon, 2008-06-16 at 08:01 +0000, John Emmas wrote:
> Hi all,
>
> Earlier in the year I completed the functionality for an Ardour "session
> merger" whereby two Ardour sessions can me merged together.  In fact, if one
> of the sessions was non-existent, it could also provide a "Save As" feature
> (allowing a session to be renamed) although I haven't got that far yet.

"Save As" is a *lot* more complicated than that, unfortunately.

> Being a Windows programmer, I haven't yet tackled a GUI for Ardour.  In
> fact, the only step I've taken is to buy a book about GTK+ development and
> I'm trying to get to grips with some of the concepts.  The book I bought is
> called "Foundations of GTK+ Development" by Andrew Krause and although
> it's well written and authoritative, I can't help noticing that some of its
> concepts would be considered total herecy for a Windows programmer!!

Most good, modern programming concepts are a total heresy to windows
programmers. I hate to be so partisan. No, actually, I don't! :)

> model which alleviates this problem to a great extent.  Nevertheless, it's
> considered 'bad form' to assume that GUI object addresses will remain
> persistent.  Windows maintains handles for objects (which DO remain
> persistent).  Therefore, if you need the address of a GUI object, you find
> it out from knowing its handle.  I just wondered if there was any similar
> concept in GTK+.  I can't see anything from my book but I don't want to
> start programming with a fundamental misconception as big as this.

Unix programming doesn't use "handles" very much, because its more or
less always had virtual memory, and so this nonsense of illegal pointers
(let alone the old "far" pointer mess from) has never existed.

The term "handles" in POSIX land tends to be restricted to the handling
of objects that are supposed to totally opaque to the
program/programmer. A good example would be an XWindow in the XWindow
API. The data structure for an XWindow is not accessible to the program,
all you ever use is the address of the data structure. Another example
is the return from dlopen(), used for run-time loading of explicitly
requested shared objects (e.g. plugins). The pointer you get back from
this function points at something, but you don't get to know what it is.

> Another thing I've noticed is that GTK+ seem to be remarkably 'non'
> object-oriented.  There seems to be a heavy reliance on global functions
> which get used to manipulate objects, rather than the objects knowing how to
> manipulate themselves.

C is not an object oriented language, and thus any attempt to do OOP
with it involves making some decisions. There are generally two
approaches to the issue. One is to try to simulate member functions
directly:

        struct SomethingOrOther {
             ....
             int (*aMethodThatReturnsIntAndTakesFloat)(float);
        };

        SomethingOrOther* foo = /* make a new SomethingOrOther */
        int val = foo->aMethodThatReturnsIntAndtakesFloat (3.14159);

some people like this, others think its wrong to try to turn C into C++,
and prefer the other approach:

        struct SomethingOrOther {
            ...
        };

        SomeThingOrOther* foo = /* make a new SomethingOrOther */
        int val = something_or_other_compute_val (foo, 3.14159);

the first method is quite hard to use if you want to do "virtual"
methods like the ones in C++. at least, its quite hard to get right. the
second one is ugly and tedious to write, but you can implement most of
the features of OOP reasonably efficiently and reliably.

>  Even the most basic things like object placement,
> or setting the text for an object - these actions seem to be unknown to the
> objects themselves.  Is this a concept that I'll just have to get used to or
> should I buy another book??

No, the answer is much easier than this. None of Ardour's GUI is written
in GTK+. We use gtkmm which is C++ thin wrapper around GTK, and gives
you a nice C++-idiomatic GUI toolkit.

        Gtk::Window win;
        win.set_title ("Yow!");
        win.show ();

etc. etc. etc.



_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[John Emmas]

----- Original Message -----
From: "Paul Davis" <paul@...>
Subject: Re: [Ardour-Dev] GTK+ (concepts and advice)
>
> Unix programming doesn't use "handles" very much, because its more or
> less always had virtual memory
>
Fair enough....  I just wanted to be sure about that before I go too far
;-)

>
> C is not an object oriented language, and thus any attempt to do OOP
> with it involves making some decisions.
>
Haha - I've been reading this book for over a week without even realising
that GTK+ is written in 'C'.  I suppose I was fooled by the '+'

>
> the answer is much easier than this. None of Ardour's GUI is written
> in GTK+. We use gtkmm which is C++ thin wrapper around GTK, and gives
> you a nice C++-idiomatic GUI toolkit.
>
Thanks.  That's the kind of advice I'm looking for.  What is 'Glade' BTW?  I
thought about using it to design GUI interfaces but it seems to design them
as XML resources which (I gather) get interpeted at runtime.  Is that
useful?  And are there any examples where Ardour uses Glade?  I can see a
library called libglademm but I don't know how or where it gets used.

>
> "Save As" is a *lot* more complicated than that, unfortunately.
>
To do it without re-loading the newly created session would be complicated
(which is the main reason why I haven't done it) but the process itself
isn't difficult (although it's very time consuming if native media is
involved).

John



----- Original Message -----
From: "Paul Davis" <paul@...>
To: "John Emmas" <johne53@...>
Cc: <ardour-dev@...>
Sent: 16 June 2008 14:44
Subject: Re: [Ardour-Dev] GTK+ (concepts and advice)

>
> On Mon, 2008-06-16 at 08:01 +0000, John Emmas wrote:
>> Hi all,
>>
>> Earlier in the year I completed the functionality for an Ardour "session
>> merger" whereby two Ardour sessions can me merged together.  In fact, if
>> one
>> of the sessions was non-existent, it could also provide a "Save As"
>> feature
>> (allowing a session to be renamed) although I haven't got that far yet.
>
> "Save As" is a *lot* more complicated than that, unfortunately.
>
>> Being a Windows programmer, I haven't yet tackled a GUI for Ardour.  In
>> fact, the only step I've taken is to buy a book about GTK+ development
>> and
>> I'm trying to get to grips with some of the concepts.  The book I bought
>> is
>> called "Foundations of GTK+ Development" by Andrew Krause and although
>> it's well written and authoritative, I can't help noticing that some of
>> its
>> concepts would be considered total herecy for a Windows programmer!!
>
> Most good, modern programming concepts are a total heresy to windows
> programmers. I hate to be so partisan. No, actually, I don't! :)
>
>> model which alleviates this problem to a great extent.  Nevertheless,
>> it's
>> considered 'bad form' to assume that GUI object addresses will remain
>> persistent.  Windows maintains handles for objects (which DO remain
>> persistent).  Therefore, if you need the address of a GUI object, you
>> find
>> it out from knowing its handle.  I just wondered if there was any similar
>> concept in GTK+.  I can't see anything from my book but I don't want to
>> start programming with a fundamental misconception as big as this.
>
> Unix programming doesn't use "handles" very much, because its more or
> less always had virtual memory, and so this nonsense of illegal pointers
> (let alone the old "far" pointer mess from) has never existed.
>
> The term "handles" in POSIX land tends to be restricted to the handling
> of objects that are supposed to totally opaque to the
> program/programmer. A good example would be an XWindow in the XWindow
> API. The data structure for an XWindow is not accessible to the program,
> all you ever use is the address of the data structure. Another example
> is the return from dlopen(), used for run-time loading of explicitly
> requested shared objects (e.g. plugins). The pointer you get back from
> this function points at something, but you don't get to know what it is.
>
>> Another thing I've noticed is that GTK+ seem to be remarkably 'non'
>> object-oriented.  There seems to be a heavy reliance on global functions
>> which get used to manipulate objects, rather than the objects knowing how
>> to
>> manipulate themselves.
>
> C is not an object oriented language, and thus any attempt to do OOP
> with it involves making some decisions. There are generally two
> approaches to the issue. One is to try to simulate member functions
> directly:
>
> struct SomethingOrOther {
>      ....
>      int (*aMethodThatReturnsIntAndTakesFloat)(float);
> };
>
> SomethingOrOther* foo = /* make a new SomethingOrOther */
> int val = foo->aMethodThatReturnsIntAndtakesFloat (3.14159);
>
> some people like this, others think its wrong to try to turn C into C++,
> and prefer the other approach:
>
> struct SomethingOrOther {
>     ...
> };
>
> SomeThingOrOther* foo = /* make a new SomethingOrOther */
> int val = something_or_other_compute_val (foo, 3.14159);
>
> the first method is quite hard to use if you want to do "virtual"
> methods like the ones in C++. at least, its quite hard to get right. the
> second one is ugly and tedious to write, but you can implement most of
> the features of OOP reasonably efficiently and reliably.
>
>>  Even the most basic things like object placement,
>> or setting the text for an object - these actions seem to be unknown to
>> the
>> objects themselves.  Is this a concept that I'll just have to get used to
>> or
>> should I buy another book??
>
> No, the answer is much easier than this. None of Ardour's GUI is written
> in GTK+. We use gtkmm which is C++ thin wrapper around GTK, and gives
> you a nice C++-idiomatic GUI toolkit.
>
> Gtk::Window win;
> win.set_title ("Yow!");
> win.show ();
>
> etc. etc. etc.
>
>
>

_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[Paul Davis]

On Mon, 2008-06-16 at 16:32 +0000, John Emmas wrote:

> >
> Thanks.  That's the kind of advice I'm looking for.  What is 'Glade' BTW?  I
> thought about using it to design GUI interfaces but it seems to design them
> as XML resources which (I gather) get interpeted at runtime.  Is that
> useful?  And are there any examples where Ardour uses Glade?  I can see a
> library called libglademm but I don't know how or where it gets used.

Glade is a GUI designer (they used to be called RAD tools at one time).
You are correct that it spits out XML that is loaded at runtime and used
to construct the GUI "dynamically" (older versions emitted C code, but
thats been deprecated for a while).

We don't use Glade anywhere in ardour. My experience has been that Glade
works really well for simple apps and apps where user options do not
interact to create complex patterns of widget sensitivity. This is very
common in Ardour, and its actually easier to just cook up the dialog by
hand and get complete access to everything we need.

> >
> > "Save As" is a *lot* more complicated than that, unfortunately.
> >
> To do it without re-loading the newly created session would be complicated
> (which is the main reason why I haven't done it) but the process itself
> isn't difficult (although it's very time consuming if native media is
> involved).

The problem is that you need to offer some rather complex options to the
user regarding copying the data associated with the session. Once the
user has made those choices, its easy, but presenting them in a
straightforward way is complicated, partly because there are really
smart (and really fast) ways to do the "copying" on a POSIX system that
do not exist on Windows.

--p


_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[John Emmas]

----- Original Message -----
From: "Paul Davis" <paul@...>
Subject: Re: [Ardour-Dev] GTK+ (concepts and advice)
>
> there are really smart (and really fast) ways to do the "copying" on a
> POSIX system that do not exist on Windows.
>
Interesting....  how complicated is it to use this feature and how much
faster is it - and why is "copying" in inverted commas??  :-)

At the moment, I'm using bog standard fopen to do the copying but if there
was a faster method, it might be a significant step towards implementing
'Save As'.

John



----- Original Message -----
From: "Paul Davis" <paul@...>
To: "John Emmas" <johne53@...>
Cc: <ardour-dev@...>
Sent: 16 June 2008 16:03
Subject: Re: [Ardour-Dev] GTK+ (concepts and advice)

>
> On Mon, 2008-06-16 at 16:32 +0000, John Emmas wrote:
>
>> >
>> Thanks.  That's the kind of advice I'm looking for.  What is 'Glade' BTW?
>> I
>> thought about using it to design GUI interfaces but it seems to design
>> them
>> as XML resources which (I gather) get interpeted at runtime.  Is that
>> useful?  And are there any examples where Ardour uses Glade?  I can see a
>> library called libglademm but I don't know how or where it gets used.
>
> Glade is a GUI designer (they used to be called RAD tools at one time).
> You are correct that it spits out XML that is loaded at runtime and used
> to construct the GUI "dynamically" (older versions emitted C code, but
> thats been deprecated for a while).
>
> We don't use Glade anywhere in ardour. My experience has been that Glade
> works really well for simple apps and apps where user options do not
> interact to create complex patterns of widget sensitivity. This is very
> common in Ardour, and its actually easier to just cook up the dialog by
> hand and get complete access to everything we need.
>
>> >
>> > "Save As" is a *lot* more complicated than that, unfortunately.
>> >
>> To do it without re-loading the newly created session would be
>> complicated
>> (which is the main reason why I haven't done it) but the process itself
>> isn't difficult (although it's very time consuming if native media is
>> involved).
>
> The problem is that you need to offer some rather complex options to the
> user regarding copying the data associated with the session. Once the
> user has made those choices, its easy, but presenting them in a
> straightforward way is complicated, partly because there are really
> smart (and really fast) ways to do the "copying" on a POSIX system that
> do not exist on Windows.
>
> --p
>
>

_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[Fons Adriaensen-2]

On Mon, Jun 16, 2008 at 08:19:31PM -0000, John Emmas wrote:

> Interesting....  how complicated is it to use this feature and how much
> faster is it - and why is "copying" in inverted commas??  :-)

In a Unix filesystem a directory is just a list of

(file-or-directory-name, number).

All information about the file itself is not kept in the
directory but in a separate list of 'inodes' as they are
called, which is indexed by the number. There is one such
list oif inodes for each partition.

This means you can 'copy' a file by just creating a new
entry in a directory - as long as you remain on the same
partition. The file data itself is not copied if you do
this, there is just a new pointer to the inode created.
The inodes maintain a count of the number of directory
entries pointing to them. A file is deleted - the disk
space it occupies is marked as free - if the count becomes
zero. There is nothing special about the first 'original'
link which in most cases is the only one. Any other is
just as good.

These are what is called 'hard' links. There are also
'soft' links - these are just a file containing the full
path name of another one, and treated specially by the
system.  Soft links exist in Windows as well (called
'shortcuts' IIRC), but hard links don't.

--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.

_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org

[Paul Davis]

On Mon, 2008-06-16 at 20:19 +0000, John Emmas wrote:

> ----- Original Message -----
> From: "Paul Davis" <paul@...>
> Subject: Re: [Ardour-Dev] GTK+ (concepts and advice)
> >
> > there are really smart (and really fast) ways to do the "copying" on a
> > POSIX system that do not exist on Windows.
> >
> Interesting....  how complicated is it to use this feature and how much
> faster is it - and why is "copying" in inverted commas??  :-)
>
> At the moment, I'm using bog standard fopen to do the copying but if there
> was a faster method, it might be a significant step towards implementing
> 'Save As'.

if the destination directory/folder is on the same filesystem as the
"original", then you can offer the user the option of creating a "hard
link" to the data file. this means that even if you delete the
"original" session, the data files will continue to exist (though they
will be accessible via one path (the new one), and not two). since most
linux users now tend to use their disks as one big huge partition, there
is a high likelihood that this is an option in many situations.

ardour already does this "silently" if you opt to embed (rather than
import) external files into a session. rather than make a copy, it will
make a hard link if possible.

"hard links" are different from "symbolic links" in POSIX; MS tried to
introduce "links" with Vista but only added the "symbolic" kind, once
again reinforcing the old adage "those who don't understand unix are
condemned to reinvent it ... poorly".

<background>
files in a POSIX filesystem are not named paths, but things called
"inodes". a path represents an inode, but you can have more than one
path doing that. when you create a new file in a directory, you are
creating an inode, and then a path entry within the file that *is* the
directory. the path points to the inode, and the process increments the
"link count" of the inode. you can then use the "ln" command to create
other paths that also point to the same inode, which increments the link
count once more. removing 1 or more of the paths that point to the inode
has no impact on the existence of the inode until the last one is
removed. note also that opening the inode from within an application
also increments the link count for the inode, which makes it possible
(for example) to remove a file from the filesystem while an application
has it open with essentially no effect on the application - the inode is
not deleted until the link count drops to zero, which will happen when
the application closes the file). you can see link counts with the ls -l
command.
</background>

--p



_______________________________________________
ardour-dev mailing list
ardour-dev@...
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org