[gmpi] Re: Topic 6: Time representation
- From: RonKuper@xxxxxxxxxxxx
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 29 Apr 2003 13:52:55 -0400
>>>
Please, no... this is the worst and most difficult part of DXi to
implement
<<<
I wasn't suggesting we emulate or repeat the DXi model. Events with
durations are unavoidable IMO. It's not only note events. It could also be
"shape events", segments of an evolving parameter change such as a volume
increase. These things exist in DirectX today. Not to assume we'll agree
to make it the same in GMPI, but there are also benefits to both approaches.
-----Original Message-----
From: Angus F. Hewlett [mailto:amulet@xxxxxxxxxxxxx]
Sent: Tuesday, April 29, 2003 1:47 PM
To: gmpi@xxxxxxxxxxxxx
Subject: [gmpi] Re: Topic 6: Time representation
On Tue, 29 Apr 2003 RonKuper@xxxxxxxxxxxx wrote:
> Sorry, I beg to differ.
> One can imagine using GMPI to implement a MIDI only plugin. It seems that
> MIDI data should be processed solely in musical time.
The way I see it, MIDI data is just a subset of event data, and events
should be processed in absolute time unless there's a really, really good
reason to do otherwise.
> Soft synths would naturally want incoming musical events (MIDI or
whatever)
> to be expressed on a musical timeline, but rendered on a sample timeline.
> The host could convert musical events to a sample timeline, but what if we
> adopt a note event structure that has an implicit duration? Then the
> note-off time (in the future) become corrupt if the tempo changes between
> note on and note off. Not so if note times and durations were expressed
in
> musical units.
Please, no... this is the worst and most difficult part of DXi to
implement. I understand it has reasonable goals, but the way DXi handles
events is absolutely painful for plugin developers (well, this plugin
developer anyways). I'm all for an architecture that has no knowledge of
the future beyond the end of the current processing segment.
Notes-with-implicit-musical-duration is an absolute nightmare for plugin
developers.
> >>>
> The one potential problem with this scheme is that it is not good for
> dealing with plugins that want to have knowledge of "future" events beyond
> the end of the current process block.
> <<<
> MIDI quantizers and arpeggiators fall into this category. It's not only
> about being able to deal with tempo changes, its about being able to
> position musical (output) data on the song's timeline without worrying the
> position might change later.
It doesn't have to be implemented in that way... such a plugin can buffer
internally and does not position -anything- on the timeline until the time
is right for it to do so (i.e. during the processing slice in which the
event falls). The plugin can track tempo changes and song position and
simply wait for the right time to output the event. OK, this makes things
a little harder for MIDI plugin developers (although really not that much
harder), but a great deal easier for softsynth developers.
Regards,
Angus.
----------------------------------------------------------------------
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:
