5 Jun
2012
5 Jun
'12
12:34 p.m.
Hi All,
From what I can tell, it looks like the LV2 Atom
Sequence specification
allows you to send events with arbitrary units for the
timestamp.
I have a few questions about this:
1. How are we to know whether a particular unit uses the *double* field in
the timestamp union, or the *uint64_t *field in the timestamp union.
2. The specification says "The unit field is either a URID that described
an appropriate time stamp type, or may be 0 where a default stamp type is
known." In what circumstances would the timestamp be known? When can I
expect to see a zero in that field?
3. Are the timestamps absolute times? Or relative to the previous event?
Or relative to the start of the audio chunk? Does it depend on the units
used?
4. Why does the
documentation<http://lv2plug.in/doc/html/structLV2__Atom__Sequence__Body.html>show
|FRAMES |SUBFRMS| as the timestamp field? From what I can tell, there
is no unit which includes frames and subframes subdivided that way,
and the sampler
example </> just uses the full 64 bits as a frames field. Is this just a
relic from the old event port documentation? (the diagram seems familiar).
5. How are hosts/plugins supposed to deal with the multiplicity of units?
For example, suppose I'm a plugin or host that wants to receive MIDI data.
How am I supposed to know what timestamp unit to expect? Is there a
facility for converting between different units automatically? The only
extra information required to convert between any two time units would be
the bpm and sample rate. It would be rather annoying to have to implement
a bunch of unit conversion code in every host/plugin you write in order to
make sure it can handle any unit which is tossed at it.
Thanks,
Jeremy
5 Jun
5 Jun
2:47 p.m.
On Tue, Jun 5, 2012 at 6:34 AM, Jeremy Salwen <jeremysalwen(a)gmail.com>wrote;wrote:
4. Why does the
documentation<http://lv2plug.in/doc/html/structLV2__Atom__Sequence__Body.html>show
|FRAMES |SUBFRMS| as the timestamp field? From what I can tell, there
is no unit which includes frames and subframes subdivided that way, and the sampler
example just uses the full 64 bits as a frames field. Is this just a
relic from the old event port documentation? (the diagram seems familiar).
video timecode.
9:44 p.m.
On Tue, 2012-06-05 at 06:34 -0400, Jeremy Salwen wrote:
Hi All,
From what I can tell, it looks like the LV2 Atom Sequence
specification allows you to send events with arbitrary units for the
timestamp.
I have a few questions about this:
1. How are we to know whether a particular unit uses the double field
in the timestamp union, or the uint64_t field in the timestamp union.
Context. When used as event ports in the run() callback, it is always
frames, like everything else.
I deliberately avoided complicating it with a bunch of stuff to handle
beat-based time stamps in this context since this would almost certainly
be unused (learned that lesson with the event extension). It can be
added later if need be.
2. The specification says "The unit field is
either a URID that
described an appropriate time stamp type, or may be 0 where a default
stamp type is known." In what circumstances would the timestamp be
known? When can I expect to see a zero in that field?
See above.
3. Are the timestamps absolute times? Or relative to
the previous
event? Or relative to the start of the audio chunk? Does it depend on
the units used?
Absolute from the start of the Sequence.
4. Why does the documentation show |FRAMES |SUBFRMS|
as the timestamp
field? From what I can tell, there is no unit which includes frames
and subframes subdivided that way, and the sampler example just uses
the full 64 bits as a frames field. Is this just a relic from the old
event port documentation? (the diagram seems familiar).
Oops, relic. I will fix this.
5. How are hosts/plugins supposed to deal with the
multiplicity of
units? For example, suppose I'm a plugin or host that wants to
receive MIDI data. How am I supposed to know what timestamp unit to
expect? Is there a facility for converting between different units
automatically? The only extra information required to convert between
any two time units would be the bpm and sample rate. It would be
rather annoying to have to implement a bunch of unit conversion code
in every host/plugin you write in order to make sure it can handle any
unit which is tossed at it.
Indeed it would be. Hence why none of this is there, so the extension
does not imply you are expected to have to deal with any of that. I
suppose the fact that it is audio frames in this context needs to be
more clear.
In short, when used as port buffers, it's always frames, don't worry
about it. The potential for other time stamp types is there for other
cases, since it's possible to use Sequences in other non-port-buffer
ways (e.g. you could send around events with entire sequences as their
payloads)
Cheers,
-dr
P.S. lv2-dev is a better place for this sort of thing
11:54 p.m.
On Tue, Jun 5, 2012 at 3:44 PM, David Robillard <d(a)drobilla.net> wrote:
On Tue, 2012-06-05 at 06:34 -0400, Jeremy Salwen
wrote:
If the timestamps are absolute, are they reset on every call to activate()?
I thought lv2-dev was for developing the lv2 spec and extensions, but my
questions were more about implementation of plugins/hosts.
Jeremy
Hi All,
From what I can tell, it looks like the LV2 Atom Sequence
specification allows you to send events with arbitrary units for the
timestamp.
I have a few questions about this:
1. How are we to know whether a particular unit uses the double field
in the timestamp union, or the uint64_t field in the timestamp union.
Context. When used as event ports in the run() callback, it is always
frames, like everything else.
I deliberately avoided complicating it with a bunch of stuff to handle
beat-based time stamps in this context since this would almost certainly
be unused (learned that lesson with the event extension). It can be
added later if need be.
2. The specification says "The unit field is
either a URID that
described an appropriate time stamp type, or may be 0 where a default
stamp type is known." In what circumstances would the timestamp be
known? When can I expect to see a zero in that field?
See above.
3. Are the timestamps absolute times? Or
relative to the previous
event? Or relative to the start of the audio chunk? Does it depend on
the units used?
Absolute from the start of the Sequence.
4. Why does the documentation show |FRAMES
|SUBFRMS| as the timestamp
field? From what I can tell, there is no unit which includes frames
and subframes subdivided that way, and the sampler example just uses
the full 64 bits as a frames field. Is this just a relic from the old
event port documentation? (the diagram seems familiar).
Oops, relic. I will fix this.
5. How are hosts/plugins supposed to deal with
the multiplicity of
units? For example, suppose I'm a plugin or host that wants to
receive MIDI data. How am I supposed to know what timestamp unit to
expect? Is there a facility for converting between different units
automatically? The only extra information required to convert between
any two time units would be the bpm and sample rate. It would be
rather annoying to have to implement a bunch of unit conversion code
in every host/plugin you write in order to make sure it can handle any
unit which is tossed at it.
Indeed it would be. Hence why none of this is there, so the extension
does not imply you are expected to have to deal with any of that. I
suppose the fact that it is audio frames in this context needs to be
more clear.
In short, when used as port buffers, it's always frames, don't worry
about it. The potential for other time stamp types is there for other
cases, since it's possible to use Sequences in other non-port-buffer
ways (e.g. you could send around events with entire sequences as their
payloads)
Cheers,
-dr
P.S. lv2-dev is a better place for this sort of thing
Thanks David,
7 Jun
7 Jun
12:50 a.m.
On Tue, 2012-06-05 at 17:54 -0400, Jeremy Salwen wrote:
[...]
If the timestamps are absolute, are they reset on
every call to
activate()?
Sorry, I guess my answer was ambiguous. In this case they are relative
to the start of the run() call. Same as event (and every other plugin
spec AFAIK)
I thought lv2-dev was for developing the lv2 spec and
extensions, but
my questions were more about implementation of plugins/hosts.
Any sort of development stuff related to LV2 is welcome. It's just
nicer for archive purposes; no worries either way, though
-dr
4581
days inactive
4582
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
3 participants
participants (3)
-
David Robillard -
Jeremy Salwen -
Paul Davis