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

InstrumentSoundShaping refactoring #7229

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

michaelgregorius
Copy link
Contributor

@michaelgregorius michaelgregorius commented Apr 27, 2024

Accessors for volume, cutoff, resonance

Add accessors for the volume, cutoff and resonance parameters (envelope and LFO). Use references instead of pointers.

This makes the code less technical and more readable as it for example removes lots of static casts. The casts are now done in a special helper method that returns the parameters for a given target.

Remove EnvelopeAndLfoParameters array

Remove the EnvelopeAndLfoParameters array and use explicit instances for volume, cutoff, resonance. This simplifies construction and initialization of the instances.

Besides the array this also removes the Target enum and the NumTargets value.

To simplify storage and retrieval of the parameters three private methods have been added which provide the node names of the volume, cutoff and resonance parameters.

Adjust InstrumentSoundShapingView to the removed NumTargets property.

Remove friend relationship

Remove the friend relationship between InstrumentSoundShaping and InstrumentSoundShapingView by providing the models via getters.

Fix memory leak

This pull request also removes a memory leak because the InstrumentSoundShaping has no explicit destructor and it therefore has never deleted the EnvelopeAndLfoParameters instances that it instantiated in its constructor.

Add private accessors for the volume, cutoff and resonance parameters (envelope and LFO).

This makes the code less technical and more readable as it for example removes lots of static casts. The casts are now done in a special helper method that returns the parameters for a given target.
Remove the `EnvelopeAndLfoParameters` array and use explicit instances for volume, cutoff, resonance. This simplifies construction and initialization of the instances.

Besides the array this also removes the `Target` enum and the `NumTargets` value.

To simplify storage and retrieval of the parameters three private methods have been added which provide the node names of the volume, cutoff and resonance parameters.

Adjust `InstrumentSoundShapingView` to the removed `NumTargets` property.
Use references to the volume, cutoff and resonance parameters instead of pointers.
Remove the friend relationship between `InstrumentSoundShaping` and its related view by providing the models via getters.
Get rid of `InstrumentSoundShaping::targetNames` by using translations and strings directly. Move the remaining stuff into `InstrumentSoundShapingView` until it is removed there as well.
Remove the array of EnvelopeAndLfoViews and use dedicated instances instead.

This also enables the final removal of the remaining `targetNames`.
…ingRefactoring

Conflicts:
* src/core/InstrumentSoundShaping.cpp
* src/gui/instrument/InstrumentSoundShapingView.cpp
@michaelgregorius
Copy link
Contributor Author

@DomClark, it seems that you are currently on a review run. 😅 Can you please check this pull request as well? In my opinion it improves the readability in the context of the instrument sound shaping a lot because it gets rid or for-loops and complex array accesses.

Objects are now defined and named in a much more straight-forward way so that it becomes much more obvious what's happening in the code.

Comment on lines 372 to 400
const EnvelopeAndLfoParameters& InstrumentSoundShaping::getVolumeParameters() const
{
return m_volumeParameters;
}

EnvelopeAndLfoParameters& InstrumentSoundShaping::getVolumeParameters()
{
return m_volumeParameters;
}

const EnvelopeAndLfoParameters& InstrumentSoundShaping::getCutoffParameters() const
{
return m_cutoffParameters;
}

EnvelopeAndLfoParameters& InstrumentSoundShaping::getCutoffParameters()
{
return m_cutoffParameters;
}

const EnvelopeAndLfoParameters& InstrumentSoundShaping::getResonanceParameters() const
{
return m_resonanceParameters;
}

EnvelopeAndLfoParameters& InstrumentSoundShaping::getResonanceParameters()
{
return m_resonanceParameters;
}
Copy link
Member

Choose a reason for hiding this comment

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

I think these definitions can go in the header, like for the other model getters.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done with commit 09ac77b.

Comment on lines +265 to +266
auto& cutoffParameters = getCutoffParameters();
if (cutoffParameters.isUsed())
Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure what the advantage is to using getters internally within the class to access its own members. It just seems to increase verbosity compared to using member variables directly. (The const overloads of the getters can be removed too if this is changed.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think this is a leftover from the incremental refactoring when the retrieval of the parameters was abstracted in these methods while still using the old array implementation.

However, I don't think it's really bad because the advantage is that it hides the implementation details of the retrieval/storage, i.e. the class does not have to care where the parameters come from or how they are managed. If I'd pepper the code with direct member accesses now it would feel like a degradation to me so I'd like to keep this as is.

Move the code of some getters into the header file.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants