[Ardour-Dev] ARDOUR::AutomationList and the StateChanged signal

John Emmas johne53 at tiscali.co.uk
Fri Apr 23 08:10:08 PDT 2010


Paul might be able to make more sense of this than me but I eventually
tracked the problem down to this code in gtk2_ardour/audio_region_view.cc
You need to understand that 'AudioRegion::_fade_in' is a member variable of
type 'Curve' which is itself derived from class AutomationList (a list which
can be iterated).

void
AudioRegionView::reset_fade_in_shape ()
{
      reset_fade_in_shape_width ((nframes_t)
                  audio_region()->fade_in().back()->when);
}


Visual C++ sees this as being functionally equivalent to this code (which
also fails)

void
AudioRegionView::reset_fade_in_shape ()
{
      Curve& fadein = audio_region()->fade_in();

      reset_fade_in_shape_width (fadein.back()->when);
}


'fadein.back()' is the code that's failing because by the time it gets
called, 'audio_region()->fade_in()' seems to have gone out of scope.
However, changing the above subtlely so that it makes a copy of '_fade_in'
(rather than taking a reference to it) produces this variant:-

void
AudioRegionView::reset_fade_in_shape ()
{
      Curve fadein = audio_region()->fade_in();

      reset_fade_in_shape_width (fadein.back()->when);
}

and the above seems to work.  So I don't quite know where the problem is.
Is there a subtle difference between the way that gcc compiles the original
code and the way that VC++ compiles it?  Or does the original code return a
reference to an out-of-scope object which gcc (luckily) fails to spot?  Or
does VC++ think that the '_fade_in' object has gone out of scope when in
fact it hasn't (I'd be quite surprised if that were true).

I could maybe do some extra debugging to see if and when '_fade_in' goes out
of scope.

John




More information about the Ardour-Dev mailing list