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

Reduce number of waveform options #6428

Closed
mixxxbot opened this issue Aug 22, 2022 · 10 comments
Closed

Reduce number of waveform options #6428

mixxxbot opened this issue Aug 22, 2022 · 10 comments

Comments

@mixxxbot
Copy link
Collaborator

Reported by: ywwg
Date: 2012-05-11T15:22:52Z
Status: Confirmed
Importance: Low
Launchpad Issue: lp998096
Tags: usability, waveform


I love the new waveforms, but the preferences window for them is ugly and over-engineered. The number of bugs for various individual waveform implementations is also proliferating so reducing the options here will also reduce some of those issues.

I understand that many of these options allow users to fine-tune the waveform for their individual machine's capability, but I think we need to better balance the interests of debugging and the interest in not scaring our users. Most DJs don't know what OpenGL is, or why they'd want to use shaders or not... So the basic waveform settings have to be easily-grasped. Further complexity, for debugging, should be hidden or reduced.

In my ideal world there would be a single waveform dropdown, and it would contain:

  • Off
  • Simple
  • Complex
  • Complex (Hardware accelerated)

(where "hardware accelerated" means opengl)

Simple would be our simplest waveform running at a low fps, like 15fps.
Complex would be a pure-QT filtered waveform running at 30fps. This is our "compatibility mode" for fast systems that have graphics card issues with GL.
Complex (hardware accelerated) would our GL implementation, also running at 30.

As for the options, some of them are useful for debugging and development, but some seem unnecessary to me.

Debugging/Advanced elements:

Having the actual fps is ok for development but unnecessary for most users. If it's running slow they will drop down to Simple. I've been told some people like to boost this to 60 for ultra-smoothness.

99% of the time I don't care what my opengl status is.

Superfluous elements:

I think "visual gain" is unnecessary, and might have mostly been a workaround for some bugs in the analyzing code. I suggest we drop it completely. Perhaps we could replace it with an option to either fill the height with the waveform, or leave the height as a function of the gain.

We should just pick a default zoom. If the user changes the zoom, save that setting as the new default.

I'm not sure why waveform zooms wouldn't be synchronized.

RJ suggested an "advanced" tab... maybe we could have something like:

[ Waveform Dropdown ]
[+] Advanced

So the Advanced options are in a twirl-down section, not a tab, but they are hidden by default.

@mixxxbot
Copy link
Collaborator Author

Commented by: esbrandt
Date: 2012-05-11T18:22:26Z


Agree that the waveform options is rather complex.

Some thoughts.
Actual rate: Drop completely
GL Status: Drop completely
Frame Rate: Leave it in, but decide on slider or stepper.
Synchronize: Drop completely. At least to my knowledge Traktor is the only major soft that allow deck independent zoom but probably only because they do not have parallel waveforms.
Also it allows us to have a global keyboard shortcut for zoom.

Visual gain: My vote is for leaving it in. It is probably not that useful for EDM or other popular music, but for some less bassy older music ( e.g. 70s funk & dancehall) its nice to have an option to emphase some frequency ranges visually to make the most out of the waveforms. Mixxx users likely play out a wide variety of music and leaving Visual gain in as advanced option is reasonable and a unique selling point.
Also it could be useful if wed choose to have a 3-band waveform somewhere in the feature, where the 3 ranges are displayed below each other just like in Scratch/Itch. In that said software i found it not that useful because it is a) not colored as in the standard view and b) the basses dont really stand out but its what is usually used for beatmatching.

Zoom factor: Current waveform zoom range is 1-6 where 1 is default and this is too close (Zoom steps are geeky too). We have less than 1 second of audio visible per default now in the standard skin. Better use something like 100%-10% in steps of 10 where 50% is default so we can use 3 not yet added zoom buttons (In/Out/Reset to default) per deck in the GUI.

Imo the waveform options should move to a separate tab in the Preferences just like crossfader/EQ. Would also make the preferences dialog shrink a bit from it`s current height.

@mixxxbot
Copy link
Collaborator Author

Commented by: rryan
Date: 2012-05-11T18:49:16Z


I agree waveform stuff should probably graduate to its own section now.

I think GL status and actual FPS should stay so that when we get bug
reports about performance we can ask them about things like their OpenGL
version and the true FPS they achieve and they can get that info with
little trouble. Maybe we could hide this inside an advanced section along
with some extra debug output for easy bug reports.

I talked w/ Owen a bit about this but the new waveforms are going to cause
lots of troubles to start with (performance and stability) so being able to
ask people to try different waveform settings and so on is useful.

I think visual-gain might be useful but I think it'd be better as a slider.

I agree w/ jus's comments about zooming. I wasn't sure if separate zoom
levels were useful but since Traktor does it I assume we would get a
feature request at some point for that so why not leave it in?

On Fri, May 11, 2012 at 2:22 PM, jus wrote:

Agree that the waveform options is rather complex.

Some thoughts.
Actual rate: Drop completely
GL Status: Drop completely
Frame Rate: Leave it in, but decide on slider or stepper.
Synchronize: Drop completely. At least to my knowledge Traktor is the only
major soft that allow deck independent zoom but probably only because they
do not have parallel waveforms.
Also it allows us to have a global keyboard shortcut for zoom.

Visual gain: My vote is for leaving it in. It is probably not that useful
for EDM or other popular music, but for some less bassy older music ( e.g.
70s funk & dancehall) its nice to have an option to emphase some
frequency ranges visually to make the most out of the waveforms. Mixxx
users likely play out a wide variety of music and leaving Visual gain in as
advanced option is reasonable and a unique selling point.
Also it could be useful if wed choose to have a 3-band waveform somewhere in the feature, where the 3 ranges are displayed below each other just like in Scratch/Itch. In that said software i found it not that useful because it is a) not colored as in the standard view and b) the basses dont really stand out but its what is usually used for beatmatching.

Zoom factor: Current waveform zoom range is 1-6 where 1 is default and
this is too close (Zoom steps are geeky too). We have less than 1 second
of audio visible per default now in the standard skin. Better use
something like 100%-10% in steps of 10 where 50% is default so we can
use 3 not yet added zoom buttons (In/Out/Reset to default) per deck in
the GUI.

Imo the waveform options should move to a separate tab in the
Preferences just like crossfader/EQ. Would also make the preferences
dialog shrink a bit from it`s current height.

--
You received this bug notification because you are a member of Mixxx
Development Team, which is subscribed to Mixxx.
https://bugs.launchpad.net/bugs/998096

Title:
Reduce number of waveform options

To manage notifications about this bug go to:
https://bugs.launchpad.net/mixxx/+bug/998096/+subscriptions

@mixxxbot
Copy link
Collaborator Author

Commented by: esbrandt
Date: 2012-06-17T10:40:04Z


For reference, the separate bug for moving the waveform to its own section at lp:1014258

@mixxxbot
Copy link
Collaborator Author

Commented by: Pegasus-RPG
Date: 2013-12-16T17:59:44Z


Don't forget my work in bug #⁠896880 incase its helpful.

@mixxxbot
Copy link
Collaborator Author

Commented by: esbrandt
Date: 2014-09-09T09:34:25Z


Alot has changed in the waveforms preferences over the time.
Waveform now has its own preferences tab, and even more waveform (overview) types emerged.

The new preferences tab is much more structured, and should help the users to get by.

But some of the issues of the initial post remain ( Visual gain, zooming, advanced tab...)

@mixxxbot mixxxbot transferred this issue from another repository Aug 24, 2022
@daschuer daschuer removed the bug label May 31, 2023
@uklotzde
Copy link
Contributor

Offer a selection with two options (drop down):

  • Accelerated
  • Non-accelerated

Based on the selected option only show the available variants. Those variants should be distinct by their features and not mention any technical details of the implementation.

@acolombier
Copy link
Member

Following suggestion from Uwe here and in #11615, could we reduce the Waveform type to only provide the type in the combobox, that is

  • Empty
  • Filtered
  • HSV
  • RGB
  • Stacked ("RGB" is redundant as there is no use of the RGB colour space, but only use 3 unique colours)
  • Simple
  • (and potentially in the future with 3-band waveform with moving average #13075) 3-Band

And a checkbox on the right, something like Use acceleration

@Holzhaus
Copy link
Member

Holzhaus commented May 7, 2024

I would leave out the "use acceleration" checkbox. If acceleration is available, use it.

If no hardware accel is desired, this would also apply to the spinnies, so a dedicated checkbox for waveforms does not make sense. I guess the user could just enable safe mode?

@acolombier
Copy link
Member

acolombier commented May 7, 2024

I would leave out the "use acceleration" checkbox. If acceleration is available, use it.

There is an issue with accelerated and non-accelerated waveform actually looking different. I have made a version with the checkbox for now, but we could hide it if not in safe mode easily once the looking issue is fixed.

@ywwg
Copy link
Member

ywwg commented May 10, 2024

I am going to close this one in favor of #13226 because the mixbot stuff is a little spammy and most of this discussion is obsolete.

@ywwg ywwg closed this as not planned Won't fix, can't repro, duplicate, stale May 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants