[gmpi] Re: 3.9 (draft) use cases and stuff
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Thu, 19 Feb 2004 18:47:33 -0800
On Thu, Feb 19, 2004 at 08:06:13AM -0500, Ron Kuper wrote:
> >>>
> 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.)
Right. The wording needs to be fixed, then :) What I am trying to convey
is that it needs to figure out when some future "now" is 3 beats from some
past "now".
Perhaps:
A plugin wants to do a tempo-synced delay. The plugin needs to find out
exactly how many sample frames constitute a given number of beats at the
current tempo, and when the tempo changes.
> >>>
> 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?
So latency changes with the tempo? eeek. I think that if you need to
quantize into the past, then you need to have some amount of latency. Maybe
there is a parameter which the user can change to allow more backwards time?
Doesn't require lookahead, but could benefit from it. Given the nature of
quantizing, it would need to look-ahead at live input, so I think latency is
the best answer..
> >>>
> 5. Automatic accompaniment
> <<<
>
> Again, can this be done without tempo map look-ahead?
Assuming you can get a smart-enough algorithm and fast enough system, I
don't see why not. ?
> >>>
> 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?
7 wants to bundle up a map and hand it back to the host. 6 just wants to
send events Just In Time. That's the fundamental diff.
> >>>
> 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.
But each of those works better with a different unit base. An audio track
(without time stretch or beat marking) would not care about the musical
unit. It would have a hard time converting "Bar 40, Beat 3" into a proper
sample offset. A music-oriented sequence track would have a hard time
converting "sample 123456" into a musical position.
> 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>
A question I have been asking myself more and more. Having a dynamic tempo
is not too bad. Having a dynamic time signature is a LOT more complicated.
Maybe it is not worth it? Or maybe those FEW plugins that care about meter
will figure it out on their own?
----------------------------------------------------------------------
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:
