Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closing Issue/67 #76

Merged
merged 6 commits into from
Jan 1, 2016
Merged

Closing Issue/67 #76

merged 6 commits into from
Jan 1, 2016

Conversation

nwolek
Copy link
Member

@nwolek nwolek commented Dec 31, 2015

@tap - Working with this algorithm during testing gave me some insight into it's limitations. I am pretty confident that it is working as expected, it is just quirky because of the way output history is incorporated.

I tried to document these insights in my brief Doxygen comments. Can you read these in particular and see if they make sense?

Oh, just noticed that I didn't use camelCase for last_out! Feel free to change if you want.

@@ -91,7 +91,7 @@ namespace Jamoma {
@param x1 Sample value at prior integer index
@param x2 Sample value at next integer index
@param x3 Unused sample value
@param delta Fractional location between x1 (delta=0) and x1 (delta=1)
@param delta Fractional location between x1 (delta=0) and x2 (delta=1)
@return The interpolated value
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to be consistent with other places in our code, should it be x0 (current input) and x1 (previous input) ?

@tap
Copy link
Member

tap commented Dec 31, 2015

Hi @nwolek -- can you please review my comments in the code review above? Do they square with reality?

@nwolek
Copy link
Member Author

nwolek commented Dec 31, 2015

Regarding x0,x1,x2,x3: when an interpolation requires 4 samples, that happens between x1 and x2. We now have some 2 sample algorithms that are overloaded to accept 4 samples. In this case, I made sure that the interpolation still happens between x1 and x2 so that it would remain consistent should we provide switching between algorithms in the future.

After this decision, I was faced with what to do in the two sample operators. I thought it would be better to remain consistent, so that through out our implementations, the interpolations always happen between x1 and x2. That way you have one set of comments at the start of the class that fits both operators (2 and 4 sample versions).

That was my logic, but I am happy to discuss if you disagree and think it makes things more confusing.

@tap
Copy link
Member

tap commented Dec 31, 2015

Thanks @nwolek -- that sounds a bit tortured :-). Maybe we should think about this whole overloading business... I can't help but think that there is something elegant hiding from us.

(thinking... thinking... thinking...)

I don't know if this is a great idea or a terrible one, but I'm imagining something where we pass C++ iterators as the arguments. By doing this all functions would look something like this pseudo-code:

constexpr T operator()(double delta, std::vector<T>::const_iterator begin, std::vector<T>::const_iterator end) noexcept {
    // so we have a range within a vector now between begin and end
    // that might be 2 samples or 4 or 8, etc...
    // but we should be able figure that out and do the right thing...
}

I'm not sure if this would solve all our ills or just create new ones, but it make sense to explore this further. but first we should take a break!

@nwolek
Copy link
Member Author

nwolek commented Jan 1, 2016

I have opened a new issue to discuss this redesign (issue #78). Since that conversation could take a while, I suggest we complete this pull request.

What is the best way to change the last_out variable to a private mY1? I am going to see if I can add it to the branch.

@nwolek
Copy link
Member Author

nwolek commented Jan 1, 2016

That works. Another reason to make sure that pull requests happen from a terminal branch.

@tap
Copy link
Member

tap commented Jan 1, 2016

Good plan to separate into a separate issue.

tap added a commit that referenced this pull request Jan 1, 2016
@tap tap merged commit f4ca9f8 into master Jan 1, 2016
@nwolek nwolek deleted the issue/67 branch January 1, 2016 19:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants