export hangs in v2.3

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-devlists.ardour.org
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour
.org

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-devlists.ardour.org
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour
.org

----- Original Message ----- 
From: "John Emmas" <johne53tiscali.co.uk>
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" <johne53tiscali.co.uk>
To: <ardour-devlists.ardour.org>
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-devlists.ardour.org
> http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour
.org

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

On Fri, 2008-06-13 at 18:51 +0000, John Emmas wrote:
> ----- Original Message ----- 
> From: "John Emmas" <johne53tiscali.co.uk>
> 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-devlists.ardour.org
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour
.org

----- Original Message ----- 
From: "Paul Davis" <paullinuxaudiosystems.com>
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" <paullinuxaudiosystems.com>
To: "John Emmas" <johne53tiscali.co.uk>
Cc: <ardour-devlists.ardour.org>
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" <johne53tiscali.co.uk>
>> 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-devlists.ardour.org
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour
.org

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-devlists.ardour.org
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour
.org

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-devlists.ardour.org
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour
.org

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-devlists.ardour.org
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour
.org

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-devlists.ardour.org
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour
.org