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

  • From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Thu, 05 Feb 2004 14:39:09 -0500

>So by the time the process cycle is done, that UST time that is associated
>with the start of the block is non-deterministically obsolete, and when the
>processed block hits the airwaves it is obsolete by the audio latency time.
>
>Is that right?  Assuming that is acceptable and useful, OK.

Tim, JACK has all this implemented all ready. I don't know if its
worth getting that deeply into this for a reqs phase.

>But how do you assign UST time to events?  Do you assign it the UST time at
>which the event was generated?  Or do you interpolate based on the UST at
>the start of buffer?

for input events (e.g. MIDI or equivalent), you need the UST when they
were received.

>/* assign UST when you generate the event */
>Plug A process()
>       create an event bound for Plug C at timestamp 1234
>               UST now is 5000
>       done
>Plug B process()
>       create an event bound for Plug C at timestamp 1230
>               UST now is 5005
>       done
>
>You end up with events that are in order by timestamp, but not by UST.

OK, now i see what you have a problem with.

I'm sorry. I was talking only about stamping the process() "event"
(think back to some of the XAP discussions), and events received
"realtime" from external devices. 

Yes, you cannot add UST to events that are computed for the
future. And so yes, UST would also be useless in an "offline" (non
realtime) situation.

>> Right, you can't define it so easily without references that reach
>> outside of GMPI. For 99% of all cases, its sample currently emerging
>> from the connector of a representative physical endpoint in a GMPI
>> graph.
>
>So, in the middle of a process block that means...?

Well, again, JACK defines it, but it requires some caveats about
physical hardware and signal routing.

--p

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