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

  • From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Sun, 01 Feb 2004 18:57:14 -0500

>On Sun, Feb 01, 2004 at 06:26:38PM -0500, Paul Davis wrote:
>> >But when I run my Windows music software at a PPQ higher than 96, I quickly
>> >run out of CPU for some workloads, for an arguably insignifcant gain.
>> thats because your Windows music software is written
>> incorrectly. there is no reason why increasing ticks-per-beat needs to
>> cause any change in CPU utilitization. only if the user chooses to
>> sequence a large number of events at very closely spaced time
>> intervals should it affect CPU load.
>For a system without smoothing and ramping, it sends a lot of events on
>every tick.  More ticks == more events == more CPU.  Not saying it's RIGHT
>just that it hurts, here. :)

ok, so we can conclude that GMPI should not define ticks-per-beat,
but we should be able to query it. yes?

and no, its not right. events should be sent either on process block
boundaries or per-sample or per-wall-clock-time. anyone who write a
sequencer that interpolates by "sending 1 event per N ticks" needs to
be ... well, you figure it out.


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: