Sticky design issues - my 2 cents

[KronosTheLate]

To reiterate:

Interpolation

Currently for real-valued indices like time we are just rounding to the nearest sample index, but often you'll want an interpolated value. How does the user specify what type of interpolation they want? One idea would be to allow an interpolation type symbol in the indexing, like x[1.25s, :cubic], but that seems a little weird. Another option would be to have LinearInterpolator{T}, CubicInterpolator{T}, etc. wrappers that determine interpolation behavior.
I don't like the idea of interpolating a signal when indexed, without warning to the user. If I index a sampled signal, I expect a value that is actually in the signal.

I would suggest that the returned value is the closes one to the given index, no interpolation. And that a new function can be used when the user explicitly wants to interpolate. Something like interpolate(x::SampledBuf, 1.25s, :cubic). Then, the x[1.25s, :cubic] syntax could be syntactic sugar to call the explicit interpolator - I see no harm in that, and I think it is a cool possibility.

The suggested syntax could even be extended so that x[1.25s, max] and x[1.25s, min] would mean that the returned value should be max (less than or equal) or min (greater than or equal) to the specified index respectivly. This would give even more control to the user, but keep the sensible default that the returned value is as close as possible to the specified value.

Relative vs. Absolute indexing

When we take a slice of a SampleBuf (e.g. take the span from 1s to 3s of a 10s audio buffer), what is the indexing domain of the result? Specifically, is it 1s-3s, or is it 0s-2s? For time-domain signals I can see wanting indexing relative to the beginning of the buffer, but in frequency-domain buffers it seems you usually want to keep the frequency information. Keeping track of the time information could also be useful if you split out a signal for processing and then want to re-combine things at the end.

How about when indexing with integers, the index starts at 0. But when indexing with quantities with units, the relative position in the original signal is respected. The object returned from an indexing like x[1s:2s] would then have to store the index offset in a field - this could be manually set to zero is not of interest, by a function remove_offset.