[ardour-dev] terminology (range, interval, zone, region, segment)

Mark Knecht markknecht at gmail.com
Tue Oct 4 17:09:17 PDT 2005


On 10/3/05, fons adriaensen <fons.adriaensen at skynet.be> wrote:
> On Mon, Oct 03, 2005 at 08:18:12AM -0700, Mark Knecht wrote:
>
> > Don't act upon my writings here until there is more consensus.
>
> Same remark applies here.
>
> > For what it's worth, I think that the word 'segment' (in American
> > English) applies to any part of something that has been divided
> > divided. This definition is essentially mathematical in nature but I
> > think the key is that something needs to be really divided. For
> > instance, when I have a wave file applied to a track and I break it
> > into two separate pieces each of those pieces is a 'segment'. If I
> > apply two wave files to a track, each file, or it's graphics in the
> > track, is a 'segment'.
>
> Not being an native English speaker, I'd agree with that. After all,
> IIRC, you can 'segment' a thing - slice it up. But then every noun
> can be verbed ;-). For me, segments also do not intersect and add
> up to the whole, not a part of it. In my line of business (space
> telecom) a system is usually divided into a 'ground segment' and
> a 'space segment'.
>
> > I think that 'typically' a region refers to a *continuous* part of a
> > segment. It may be the whole segment or it may be part of it.
> > Typically I think that a 'region' in this context is more abstract.
> > It's an area of the track that is marked, for some reason of interest,
> > but not necessarily physically divided into two parts. For instance a
> > region might be a highlighted portion of a wave file, or possibly more
> > than one wave file, in a track. When I drag my mouse across the
> > screen, selecting portions of the audio, I'm creating a 'region', not
> > a 'segment'.
>
> Again agreed, and I'd add that (for me) a region is something that is
> connected, i.e it only has one part. Same for 'range'.
>
> Region, range, slice, section, part, segment, zone, ... any others
> to consider ?

Hi,
   I think that one problem that the developers have, if they choose
to have it, is that they are somewhat bound by what other tools like
Pro Tools have called things in the past. For instance the area in the
upper right of both Pro Tools and Ardour is called the 'region list'
in Pro Tools. The definition of a region, according to Digidesign does
like this:

"A region is a piece of audio or MIDI data that can also have
associated automation data."

I think that this generally 'fits' what many of us probably think of
when we say 'region', but I have a problem with that definition and
the way Pro Tools actually works. The problem is that when I move a
'region' sitting in a track the automation data doesn't move with it.
I don't think it does in Ardour either. There may be some things that
move with it. Maybe there is embedded info about how to fade from
region to region, etc., but basic automation such as fader levels
don't move.

   So, what's in a region and what isn't in a region, if you agree
with the definition Digi provides above.

   With that definition of a region I have no idea if a 'segment'
makes any sense at all in this program. My thought today is that we'd
be better off not using it if only to simply the language.

   To me a range itself is not ambiguous. It's any contiguous area
defined in the time domain. Ranges can cross regions. The important
part is, I think, that ranges are only in the time domain. They don't
really contain anything. They just define where the program is doing
something.

   A 'selection' as Hermann stated, is a collection of things, either
regions or audio chucks, or something else, that have been selected. I
would suggest that you can only 'select' real things like audio. You
cannot 'select ranges'.

   Slice? I don't know.

   Range markers and Range mode? Really not sure, except for loop
ranges. It is clear to me what those do, or what they should do, at
least in loop recording modes.

   Again, a lot of this will likely be bound by trying to be
reasonably compatible with other programs as to cause as little
confusion as possible.

Cheers,
Mark



More information about the Ardour-Dev mailing list