How should we handle sample interpolation?

[nwolek]

In the following issue from JamomaCore, we talked a bit about interpolation from the TTSampleMatrix:
jamoma/JamomaCore#127

Probably not an urgent priority, but @tap and I should have a discussion about how we want to address this with the new SampleBundle model before we go too far down the road. I don't think interpolation should be completely the users' responsibility.

My initial instinct: only ImmutableSampleBundles should have methods for pulling samples that are interpolated. Not sure if that is feasible though.

[nwolek]

Trying to review this and clarify what I meant here. I was basically wishing that interpolation be part of the functionality built into SampleBundle, like it was in my re-design of SampleMartix. Now that I am reviewing terminology, it seems the method would best sit at the SampleVector level to avoid confusion. Right now we do nothing more than this:

using SampleVector = std::vector;

That gives us both operator[] and at() functions. These return a reference to the element at a specific index.

I would propose a function like the following that provides element access with interpolation baked in:

Jamoma::SampleVector sv (3); 
sv[0] = 0.0;
sv[1] = 1.0;
sv[2] = 1.5;
Jamoma::Sample interp_out1 = sv.value_at(0.5);
// output should be 0.5
Jamoma::Sample interp_out1 = sv.value_at(1.5);
// output should be 1.25

My instinct tells me putting it at such a low level would be very DRY. This would greatly simplify other tasks, such as our recent discussions about Delays and issue #60. However, I notice that this uses Jamoma::CircularStorage so we would need a similar function there.

@tap: Any thoughts? Reaction?

[tap]

I like the gist of this. I wonder if one can overload the [] operator for floats. If so, then it could be as easy as

auto out = sv[0.5];

Questions:

• I guess the default for this should be linear interpolation?
• What do we do at the ends? In the case of a delay line / circular buffer we want to wrap, but that may or may not generally be the case?
• How does the allpass interpolation work here?

I don't know if it is possible to do the following, or if we need to think about some other syntax.

auto out = sv<cubic>[0.5];

Hmmm... Thinking more about the wrapping at the ends dependent on type and the allpass maybe also dependent on something or another I wonder if the interpolation should be outside of the data container and then applied to it. This would be consistent with the "STL Algorithms":http://en.cppreference.com/w/cpp/algorithm which are defined so that they can be applied to any of the standard data containers.

?

[nwolek]

I like this syntax very much:

auto out = sv<cubic>[1.5];
auto out = sv<linear>[1.5];
auto out = sv<allpass>[1.5];
auto out = sv<spline>[1.5];

It seems very clear what is going on. Compare that to the way things are now:

Jamoma::Interpolation::Cubic<Jamoma::Sample> my_cubic;
Jamoma::Interpolation::Linear<Jamoma::Sample> my_linear;
Jamoma::Interpolation::Allpass<Jamoma::Sample> my_allpass; // FYI does not exist yet
Jamoma::Interpolation::Spline<Jamoma::Sample> my_spline;

auto out = my_cubic(sv[0],sv[1],0.5);
auto out = my_linear(sv[0],sv[1],0.5);
auto out = my_allpass(sv[0],sv[1],0.5);
auto out = my_spline(sv[0],sv[1],sv[2],sv[3],0.5);

We push the burden for figuring out a lot of things into the SampleVector class itself.

NOTE: one reason I suggested value_at() initially over square brackets is the C++ documentation states that at() checks bounds, while square brackets does not. If we intend to include this boundary checking with this, we should strongly consider a naming that alludes to this inclusion.