Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Hans Kieserman <hkieserman@ma...> - 2002-05-17 18:41:30
Why are the durations for Indications stored as properties instead of event->getDuration()?
Would a vote for unifying that Event interface be interesting to anyone? (Sorry if I'm missing any obvious comments or design documentation- haven't made it through all of it yet)
Sign-up for your own FREE Personalized E-mail at Mail.com
From: Chris Cannam <cannam@al...> - 2002-05-17 18:50:19
Hans Kieserman wrote:
> Why are the durations for Indications stored as properties instead of event->getDuration()?
No very compelling reason. I tend to think of the Event's
duration as being a "sounding" duration, and it would seem
strange to have a non-sounding event with a non-zero duration.
I like the fact that the sound layer can easily discard any
event with a zero duration without having to examine it, but
I think in practice this kind of decision is always based on
the event type anyway.
One practical reason is that the notation editor calculates
theoretical space for events (as part of the calculation of
ideal bar width) based on their durations, and giving
Indication a non-zero duration would require a special case
there. That wouldn't matter, except that other event types
might also need special cases; it seems better to have a
convention that getDuration returns a sounding duration. I
suppose I could just document that convention.
Sorry that was so long-winded.
> Would a vote for unifying that Event interface