[gmpi] Re: Reqs 3.9. Time - opening arguments

  • From: Tim Hockin <thockin@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Sun, 1 Feb 2004 14:45:39 -0800

On Sat, Jan 31, 2004 at 06:28:50PM -0500, gogins@xxxxxxxxxxxx wrote:
> Since there is no penalty for doing it, the time span must be as long as a
> reasonable choice of data type will allow; not hours but as long as
> feasible with a long or long long or something, even if that's centuries or
> whatever.

The time span of what?  Sorry, not parsing properly...

> It should be possible to switch back and forth between sample time and
> music time without introducing an error in sample time or music time (if
> possible - I'm not sure). That means, the resolution of music time must be
> at least as great as sample time - probably, greater.

I've always seen Music Time as something with coarser resolution that sample
time.  The sequencer can align things on music-time boundaries which are
relatively fine grained, but are totally independant of sample time.  

What benefit do we get from music time being more fine grained than sample
time?  Also, how do you handle the increasing market for higher sample
rates?  192 kHz Music Time?  eeek.  I was thinking more like 96-384 ticks
per beat makes sense (tick being an immutable unit of music time).  It works
pretty well in music software today.

Something like that..

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: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: