[ardour-dev] new feature: export all ranges

[Andre Raue]

nick mainsbridge wrote:
> On Thu, 2006-01-05 at 11:20 +0100, Andre Raue wrote:
>>Andre Raue wrote:
>>>Paul Davis wrote:
>>>>could we get you to checkout ardour2 via the CVS snapshot and try to
>>>>integrate what you've done into that version?
>>>>
>>>>--p
>>>Yes, I'll try that using the current tarball. I'll keep you informed 
>>>about the progress. Work will proceed in two steps:
>>>a) Introduce the flag IsRange.
[snip...]

[...snip]
> 
> hi.
> currently a range is a location whose start and endpoints differ, so a
> new type IsRange is sort of superfluous imho.
> everything else you want to do seems great from here.
> 

Let me try to explain my thoughts. Please let me know if it is 
reasonable for you. I'd like to start with...

...my definition of 'IsRange':
All and only those Location objects that have range markers are flagged 
with IsRange. Loop and punch ranges do not get flagged with IsRange.

As I understand it are range markers those kind of markers, that appear 
in the range markers ruler in the GUI. So maybe it would be better to 
call the flag IsRangeMarker?!?

Motivation:
If I want to export all ranges (defined by range markers), I need to get 
a list of those ranges, in order to know what I should export.

I thought about going without a flag before. But there are some points, 
that made me introduce this flag:
Checking for different start and end points in order to get a list of 
all ranges is not enough, as I would get loop and punch ranges, too. 
Thus I would have to check for Location objects that aren't flagged at 
all and that have different start and end points. This may work now but 
I don't think it to be save for the future.
Example: Someone introduces in about one or two years a new type of 
location that does not get any flag and that has different start and end 
points. What will happen is, that the export-all-ranges feature will 
have a malfunction. Correcting this malfunction at that point of time 
will cause much more effort than introducing a flag now.
Yes, you are right. The flag is not necessary right now. But I think, 
introducing it right now could decrease effort in the future.

In addition I think it to be more consistent if every kind of Location 
had it's own flag. I thought it to be even better if each kind of 
location had it's own _class_ derived from Location. But this would mean 
a lot of refactoring. My time is very limited, so that I dropped the 
last idea.

Greetings

Andre