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

Binaural Monitoring fixes #183

Merged
merged 14 commits into from
Feb 17, 2022
Merged

Binaural Monitoring fixes #183

merged 14 commits into from
Feb 17, 2022

Conversation

firthm01
Copy link
Collaborator

Inversion controls - closes #177
Use OSC config file rather than project data - closes #182
Patch JUCE to detect occupied port on Windows - closes #169
Gracefully handle plug-ins mismatch - closes #180

@firthm01 firthm01 requested a review from rsjbailey February 15, 2022 13:48
Comment on lines +124 to +130
std::shared_ptr<ToggleButton> button) {
button->addListener(this);
oscInvertYawButton_ = button;
setOscInvertYaw(cachedOscInvertYaw_);
Copy link
Contributor

Choose a reason for hiding this comment

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

Nitpicking again, could std::move all the passed buttons into their member vars to avoid copying the shared_ptr twice (once in pass-by-value, once in the copy-assign), e.g.
oscInvertPitchButton_ = std::move(button);
In practice probably doesn't matter as these methods won't get called often.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is a C+P of the existing pattern in other plugins so we should change this everywhere if we're going to tackle it here.

Comment on lines +341 to +349
} else if (parameterIndex == (int)ParameterId::OSC_INVERT_YAW) {
updater_.callOnMessageThread([this, parameterIndex, newValue]() {
notifyParameterChanged(ParameterId::OSC_INVERT_YAW,
p_->getOscInvertYaw()->get());
setOscInvertYaw(p_->getOscInvertYaw()->get());
});
Copy link
Contributor

Choose a reason for hiding this comment

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

I mentioned I'd noticed an odd pattern when I was going through these classes - this is it.
Not sure why we are capturing newValue, then retrieving it from the parameter rather then just using the value? Looks like a common pattern pretty much everywhere.

I guess we should either use newValue rather than doing p_->xxx->get(), or remove it from the lambda captures and have it as an unused/unnamed parameter in the parameterValueChanged function?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yeah, good point. I wonder if it's because it's on a different thread and it's better to just get the "current" value than the one passed in?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is another C+P of an existing pattern - should be tidied everywhere

saves to project data
~/Library/Audio/Plug-Ins/VST3/ear-production-suite/EAR Binaural Monitoring.settings
0.6.0 didn't have the all_available_items field, so bin mon didn't reserve any channels in BEAR and it crashed when we tried to pump metadata in to BEAR. Fixes #180
JUCE patch fixed return value of osc.connect
@firthm01 firthm01 merged commit 95bae61 into main Feb 17, 2022
@firthm01 firthm01 deleted the bin-mon-fixes branch February 17, 2022 13:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants