[gmpi] Re: Topic 6: Time representation

I agree with Frederick, and I would add that mathematical clarity is
revealed by doing as he suggests, and obscured by sticking in engineering
hacks that are not actually needed.

If we want a plugin standard that will work for more than a few styles of
music, we are actually, as matter of software engineering, going to require
that mathematical clarity. So let's build in that clarity, abstraction, and
simplicity at the basic level of representation.

===========================================
Michael Gogins
gogins at pipeline period com
Irreducible Productions
Silence, a language for programming music and sound
Available at http://www.csounds.com
===========================================


----- Original Message ----- 
From: "Frederick Umminger" <Frederick_Umminger@xxxxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Wednesday, April 30, 2003 8:41 PM
Subject: [gmpi] Re: Topic 6: Time representation


>
>
> -----Original Message-----
> From: Chris Grigg [mailto:gmpi-public@xxxxxxxxxxxxxx]
> >
> >That seems like a philosophical argument to me, not a technical one.
> >Would you agree that there is some sufficiently fine stepped
> >resolution beyond which, for a given tempo, in the context of a
> >sampled audio DAW/sequencer or a MIDI-like instrument, the difference
> >between a float representation of a time position and a stepped time
> >position is inaudible to humans?
> >
> > -- Chris
>
> ----------------------------------------------------------------------
>
> The technical argument is that for clarity and simplicity you should
represent data with its natural data type in the chosen implementation
language, in natural units. By not doing so you are unnecessarily adding
extra complications.
>
> Some of these complications are: the need to convert to ordinary units of
musical time (e.g. beats) and back; the arbitrary conversion constant
involved; rounding issues when performing operations on musical time values;
lack of language support for fixed point; conversion between different tick
bases, if they are settable; user interfaces for settability; do ticks per
second need to evenly divide the sample rate? ; the video frame rate?; the
buffer block rate?; what happens if we need to support new rates in the
future?; does this limit the possible tempos?; possible rhythms?; etc.
>
> It is just a lot simpler to represent musical time as musical time, rather
than as musical time multiplied by a large arbitrary constant and then
quantized to the nearest integer.
>
> -Frederick Umminger
>
> ----------------------------------------------------------------------
> Generalized Music Plugin Interface (GMPI) public discussion list
> Participation in this list is contingent upon your abiding by the
> following rules:  Please stay on topic.  You are responsible for your own
> words.  Please respect your fellow subscribers.  Please do not
> redistribute anyone else's words without their permission.
>
> Archive: http://www.freelists.org/archives/gmpi
> Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
>


----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: