I bailed on this in #2 since I wanted to think about it more and wasn’t sure it was needed. I think there are times it’s pretty useful, and that there’s a simple thing we can do:
We define the start as time_from_index(sample_rate, span.first_index) and the stop as time_from_index(sample_rate, span.last_index + 1). In other words, if we had sample rate 1 and indices 5:10, we have AlignedSpan(1, 5, 10) which we would map to TimeSpan(Second(5), Second(11)).
In other words, we’re saying that 1 sample is associated to the time of the sample (inclusive) to the time of the next sample (exclusive).
Why?
should allow roundtripping on both TimeSpans v0.2 and v0.3, with either RoundInwards or RoundEndsDown
gives a useful duration; 5 samples @ 1Hz is 5s
Why do we ever need to go back to continuous time? All the cases I’ve found have essentially been to allow interop with code that expects TimeSpans-compatible spans. For example, for use with the Legolas schema for Onda Annotations. I think we should try to avoid mapping back and forth too much, but it’s nice if we can in a principled way.
To close this:
[ ] define TimeSpans.start(::AlignedSpan) and TimeSpans.stop(::AlignedSpan) as above
[ ] Add roundtripping tests (TimeSpan -> AlignedSpan -> TimeSpan only needs to be exact if the original times aligned on sample boundaries already, but AlignedSpan -> TimeSpan -> AlignedSpan should always be exact)
[ ] Decide if we still want our own duration (Maybe? See #2)
[ ] Decide if we want to show continuous time in our show method
[ ] Test use in Onda Annotation?
[ ] Decide if we need to test on TimeSpans v0.2 and v0.3. If so need to deal w Onda compat.
I bailed on this in #2 since I wanted to think about it more and wasn’t sure it was needed. I think there are times it’s pretty useful, and that there’s a simple thing we can do:
We define the
startastime_from_index(sample_rate, span.first_index)and thestopastime_from_index(sample_rate, span.last_index + 1). In other words, if we had sample rate 1 and indices 5:10, we haveAlignedSpan(1, 5, 10)which we would map toTimeSpan(Second(5), Second(11)).In other words, we’re saying that 1 sample is associated to the time of the sample (inclusive) to the time of the next sample (exclusive).
Why?
duration; 5 samples @ 1Hz is 5sWhy do we ever need to go back to continuous time? All the cases I’ve found have essentially been to allow interop with code that expects TimeSpans-compatible spans. For example, for use with the Legolas schema for Onda Annotations. I think we should try to avoid mapping back and forth too much, but it’s nice if we can in a principled way.
To close this:
[ ] define
TimeSpans.start(::AlignedSpan)andTimeSpans.stop(::AlignedSpan)as above[ ] Add roundtripping tests (TimeSpan -> AlignedSpan -> TimeSpan only needs to be exact if the original times aligned on sample boundaries already, but AlignedSpan -> TimeSpan -> AlignedSpan should always be exact)
[ ] Decide if we still want our own
duration(Maybe? See #2)[ ] Decide if we want to show continuous time in our
showmethod[ ] Test use in Onda Annotation?
[ ] Decide if we need to test on TimeSpans v0.2 and v0.3. If so need to deal w Onda compat.