-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Improved Waveshaper / Spline-based graph replacement #4367
base: master
Are you sure you want to change the base?
Conversation
m_outputModel( 1.0f, 0.0f, 5.0f, 0.01f, this, tr( "Output gain" ) ), | ||
m_wavegraphModel( 0.0f, 1.0f, 200, this ), | ||
m_clipModel( false, this ), | ||
m_vectorGraphModel( this, true ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should match the order of initialization and declaration to avoid compiler warning. It means m_vectorGraphModel
should be initialized before m_clipModel
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I've been ignoring that but I will get to it eventually :)
Does anybody know why the circleci build is failing? This error seems cryptic to me.
Edit: It's always after updating Xpressive. I wonder if I accidentally updated the submodules... |
plugins/CMakeLists.txt
Outdated
@@ -80,6 +80,7 @@ IF("${PLUGIN_LIST}" STREQUAL "") | |||
VstEffect | |||
watsyn | |||
waveshaper | |||
waveshaper2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor, but use tabs instead of spaces.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do, I edited that with a different editor. Thanks for catching this.
Oh that was literally it. Well I can't complain. |
Right, that makes sense. I don't think that a decision here is something I should be making myself then, it sounds like it will span across the entire software and affect most future development. Perhaps this is something I should create an issue for to start a discussion. |
The question in my mind is, how much do we want to rip up the current system to implement these UI changes? Having something external that says "this knob hooks up here" would be great, but it's a completely different paradigm from what we currently have, and implementing it would involve a lot of well-thought-out core changes in a number of areas. But in the end I don't know what's best and I'm going off of assumptions. I think I'll make an issue for discussion later today. |
My own opinion as an observer is that with the current LMMS development community and the current internal LMMS architecture an organized large scale UI upgrade isn't feasible at this time. Any work would need to be much smaller scale otherwise the trend of individuals building moderate sized goals, getting frustrated, and subsequently leaving the project, will likely continue. For Zyn the used approach was to upgrade the internal architecture to make large scale GUI changes feasible with restricted developer resources, so that may be an option for LMMS, though keep in mind that's a very large project within itself. |
And I really don't feel equipped to do that kind of overhaul, both from lack of general experience as well as a lack of knowledge of the inner workings of the software. My current plan is to slowly start developing widgets that could be useful later so as to save time for whoever puts it all together, be it me or somebody else. Still, I completely agree that implementing the UI for an individual plugin or feature shouldn't take weeks and should be doable by someone fairly new to the codebase. |
@SecondFlight Just to answer on your questions, when I said gui scaling I meant that it should look crisp and pixel perfect on all resolutions even high display resolutions like "retina". FL studio have some nice settings for scaling gui so you if user feel that his gui is too small he can just scale it up. https://www.image-line.com/support/flstudio_online_manual/html/envsettings_general.htm |
Oh come on, checkRight will only be true if rightPoint is initialized. |
return false; | ||
} | ||
|
||
float VectorGraph::calculateSample(float input) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to have this as a separate function? I think one can use model()->calculateSample
directly.
return castModel<VectorGraphModel>(); | ||
} | ||
|
||
inline int getWidth() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please consider not using get
prefix unless the meaning is ambiguous without it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can be confused with QWidget::width()
, so I think we should check if we really need this.
@PhysSong, |
I've resolved merge conflicts and applied minor fixes. Modernization and other reviews are not applied yet. I'll try to continue working on this. |
static inline bool floatEqual(float a, float b, float epsilon) | ||
{ | ||
return qFabs(a - b) < epsilon; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No reason to reside in a class.
VectorGraphPoint * VectorGraphModel::getPoint(int index) | ||
{ | ||
return & m_points[index]; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Returning by address looks weird.
return result; | ||
} | ||
|
||
float calculateSingleCurve(float input, VectorGraphPoint * point); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be moved to VectorGraphPoint
instead.
#include <QWidget> | ||
#include <QPainter> | ||
#include <QVector> | ||
#include <QtMath> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Standard C++ math functions look better than Qt math functions.
{ | ||
Q_OBJECT | ||
public: | ||
enum TensionType |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be in the model class.
#include "Song.h" | ||
|
||
|
||
#define onedB 1.1220184543019633f |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
constexpr
instead
Fruity Waveshaper is one of the plugins I use the most in FL. It's a fantastic general-purpose digital distortion. The Waveshaper plugin by Diizy is good and definitely has its place, but it is lacking in a few key areas:
The original plugin is very similar to the 8-bit shaper by Xfer. Again, not a bad thing, but I certainly think another option would provide a better workflow and overall general-purpose plugin.
The changes I plan to make are two-fold:
Todo:
Refactor with usability in mindcommentsdocumentation