Re: [linux-audio-dev] Re: Timed Event Editor Framework

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Re: Timed Event Editor Framework
From: David Slomin (dgslomin_AT_CS.Princeton.EDU)
Date: ke syys   01 1999 - 21:32:29 EDT


On Mon, 30 Aug 1999, Eli Brandt wrote:

(continuing the debate over whether or not to merge tracks for the
internal representation of data in a MIDI sequencer)

> How about escalating the structure's tree-depth? The first version
> gets more for-each levels but the inner loop stays clean:
>
> for each_group in merged_groups
> for each_track in each_group
> old_e.time = e.time; output old_e
> old_e = e
>
> vs.
>
> for each event e in flattened_all_groups_in_tracks
> this_old_e = (old_e[e.track])[e.group]
> this_old_e.time = e.time; output this_old_e
> (old_e[e.track])[e.group] = e
>
> And with a more-involved structure the second loop involves things like
> (((old_e[e.level1index])[e.level2index])[e.level3index])[e.level4index]
> (and that isn't a one-piece multidimensional array).

I'm afraid I don't understand this part here. I'm not sure what you
mean by a "group". Remember that the model I'm discussing is not supposed
to support patterns, loops, etc, but rather just a linear list (or
parallel linear lists) of events.

> Other sorts of scenarios: apply a function to some part of a musical
> structure -- call it on that part of the data structure, or grovel
> through all the data elements determining whether they're in the part?
> (Is speed a concern?) Rearrange a musical structure -- twiddle
> pointers at the top level, or grovel again munging all the data
> elements' tags?

The point about speed is well taken.

As for "rearranging musical structure", that sounds like a heavyhanded way
of saying "reordering the tracks". I agree that exchanging two pointers
in a list of tracks is far easier and faster than modifying an integer
"track number" field for every event in the two tracks in question.
 
You have me pretty much convinced (remember, we weren't fighting after
all :-) ), but I do have one more issue that would need to be resolved:

In the merged list, there is one definite, user and API controlled order
of events. No two events are truly simultaneous, even if they have the
same timestamp. This is advantageous for purposes like dropping markers
(I'm a HUGE fan of using markers rather than selections for editing
except when you need discontinous selection). It is perfectly valid to
drop a marker between two events with the same timestamp. How do you
handle this when you use separate lists for separate tracks?

Nearly convinced,
Div.


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:53 EST