[gmpi] Re: Topic 6: Time representation

Yes, we should be using floating-point numbers for pitches too - and for
every other musical parameter, as well.

Nothing else is adequate to experimental composition - one of the stated
goals of GMPI support. And it will serve the more traditional cases quite
well enough.

In general, software engineers do not think enough like mathemticians or
scientists. There are enormous benefits from placing the parameters of
interest directly into a mathematically tractable space, as opposed to
seeking a "simpler" or "more efficient" representation that does well enough
in some contexts (like ticks for dance music) and very poorly in other
contexts (polyrythms with two grooves happening at once - this happens in
Chopin too).

All musical parameters of interest should have, at a minimum, a
representation in a linear vector space, or metric space, where time is just
absolute real-valued seconds, pitch is just absolute real-valued octaves or
half-steps, and so on. Other representations can be derived from this (such
as bar/beat/tick for musical time, or SMPTE) for musical or programming
convenience.

But the metric space should be the fundamental, low-level representation
that the scheduler and the unit generators see. All academically-based
software synthesizers, such as Csound, Cmix, SuperCollider, PD, and whatnot,
work this way - for good reason.

I think it is distracting to separate time out from other dimensions of
musical 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: "Chris Grigg" <gmpi-public@xxxxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Wednesday, April 30, 2003 4:54 PM
Subject: [gmpi] Re: Topic 6: Time representation


> [agreeing with Tim, and taking issue with Frederick's statement that
> "There is no need to carry this kind of annoyance forward into a new
> standard."]
>
>
> >  > The straightforward thing to do is to represent musical time,
> >which is a real number, with one of the builtin data types that
> >C/C++ provides for real numbers, i.e. float or double. Doubles
> >should probably be used to guarantee enough precision. The unit
> >should be a traditional one, either beats or measures, rather than
> >an artifical technical construct like the tick. I would vote for
> >beats.
> >
> >Disagree - this is not the sort of thing the end musician cares about,
but
> >it IS the sort of thing that impacts the code.
> >
> >A tick is the hosts finest level of granularity.  This abstraction allows
> >for hosts to have very fine or very coarse accuracy, depending on the
needs
> >of the situation.
>
> And harmonizes with the stepped time representation used in Standard
> MIDI Files... and every other mainstream computer musical event
> timing format I'm aware of.  Even SASL uses integers for event times.
> Yes, this -may- make things more irritating for people writing
> -certain- classes of algorithmic composition software, but viewed as
> a fraction of the target developer population that group would be
> quite small, whereas I think it could reasonably be argued that we
> should be optimizing GMPI for the most common use cases.
>
> I mean, yes, time is fluid, but then again so's pitch.  Should we be
> using floats for note pitches too...?
>
> -- Chris
>
> ----------------------------------------------------------------------
> 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: