[gmpi] Re: 3.9 (draft) use cases and stuff

  • From: "Jeff McClintock" <jeffmcc@xxxxxxxxxx>
  • To: <gmpi@xxxxxxxxxxxxx>
  • Date: Fri, 20 Feb 2004 09:37:14 +1300

Hi All,

>2. Tempo sync
 > A plugin wants to do a tempo-synced delay.  The plugin needs to find
>out  when the time will be exactly 3 beats from "now"

RON> doesn't this put us straight into a requirement that plugins be allowed
to look-ahead to future tempo changes?

I mentioned this earlier, I think it needs to be worded better.  My
Attempt..

2. Tempo sync
  A plugin wants to do a tempo-synced delay.  The plugin needs to find
out the exact time between beats at the current tempo, and when that tempo
changes.

In fact the "time between beats at the current tempo" is easily calculated
from the tempo (beats per minute)....so you may as well say...

2. Tempo sync
  A plugin wants to do a tempo-synced delay.  The plugin needs to find the
current tempo, and when that tempo changes.

A tempo synced delay does not need to know the future. It's got to accept
that if some audio enters the delay just before a tempo change, then that
audio will emerge at the wrong time.  That's a rare situation though, and
hard to fix.
   Even if you did know the tempo in advance, trying to adjust the delay
time to compensate would become a mathematical nightmare (imagine the tempo
changing several times, and buffer already containing data recorded at
several tempos).


3. Quantizing

"A quantizer might need to snap events to a point in the time
located in the past."

>I guess I'm saying this suggests that plugins need to be able to report
>their processing delay in musical units as well as sample units?

Very scary, If the tempo changes, then the plugin's delay compensation has
to change?

  I've never implemented plugin delay compensation, so i may be wrong, but I
figure it's not something you can recalculate on the fly because it involves
inserting delays into the graph.

  I think in this example, the quantizer has to request enough processing
delay to cope with a reasonable tempo range, or simply run offline.

Best Regards,
Jeff

----- Original Message ----- 
From: "Ron Kuper" <RonKuper@xxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Friday, February 20, 2004 2:06 AM
Subject: [gmpi] Re: 3.9 (draft) use cases and stuff


This is very useful, Tim.

I've got a few comments, mostly pertaining to the need (or not) for
looking ahead into future tempo changes.

>>>
2. Tempo sync
  A plugin wants to do a tempo-synced delay.  The plugin needs to find
out
  when the time will be exactly 3 beats from "now" at the current tempo,
and
  when that tempo changes.
<<<

I agree that this is a valid use case, but doesn't this put us straight
into a requirement that plugins be allowed to look-ahead to future tempo
changes?  It is possible to do tempo sync without tempo lookahead, just
as long as every tempo change that occurs within an audio frame is given
the plugin in time.  (Maybe just leave out the "3 beats from now" in the
use case.)

>>>
3. Quantizing
<<<

This poses an interesting problem which I'm not sure we've gotten to
yet.  A quantizer might need to snap events to a point in the time
located in the past.  IOW, an event at 1:1:005 might need to be
quantized to 1:1:000.  What happens in this case, is the audio
processing frame spans musical time 1:1:005-1:1:010, that is, the audio
processing frame for the desired quantized time has already passed?

I guess I'm saying this suggests that plugins need to be able to report
their processing delay in musical units as well as sample units?

Also, I think a quantizer can be written without needing to look-ahead
for tempo/meter changes.

>>>
5. Automatic accompaniment
<<<

Again, can this be done without tempo map look-ahead?

>>>
6. Realtime tempo follower
7. Offline tempo analysis
<<<

I would think that 7 follows from 6, using the rule that offline is a
special case of realtime?

>>>
8. Sequencer tracks
9. Audio tracks
Is it notified of transport position in samples?
<<<
This would be the "score time" (as opposed to the "stream time").  Every
processing frame would know the score time.

>>>
What if meter changes dynamically, but the sequenced data no
longer
makes sense?
<<<
When does a sequencer plugin cease to become a plugin, and start
becoming a host? <g>


----------------------------------------------------------------------
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





----------------------------------------------------------------------
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: