UI indication for Selected Waveform Classic/Modern

[sense-amr]

Request for tick indicator to appear .. at selected waveform .. so as to assist the user with knowing which of the waveforms they have initially selected for the oscillator in classic/modern .. osc configurations..

This request applies to Surge XT and Surge

[mkruselj]

I vote for only ticking the root menu entry, not any of the submenu entries.

[sense-amr]

thats fine just delete it ..
its obvious its not important enough to develop

[sense-amr]

just delete it .. and have fun with future suggestions people make that you just laugh off..

[mkruselj]

We didn't laugh it off, we have stated the reasoning for our choice. And we have agreed on a compromise to add ticks to first level menu options, so that will be done.

[sense-amr]

So your reasoning is to provide a multi layered selection for Waveform for the person who is making a patch .. where they could select Classic -> Sine .. but to only allow them to reference the Mode of oscillator creation they selected .. instead of the waveform they selected as well .. and the reasoning for that is somehow they should be able to recognise .. what the waveform they selected is .. after they have morphed it in the spectral display ..

[baconpaul]

that's not it @sense-amr
there is no difference at all between classic->saw and classic->square except that one parameter is changed
it's not like there is a different waveform, or different immutable setting

 <snapshot name="Sawtooth" p0="0.0" p1="0.5" p2="0.5" p3="0.0" p4="0.0" p5="0.1" p5_extend_range="0" p6="1"
              retrigger="0"/>
    <snapshot name="Square" p0="-1.0" p1="0.5" p2="0.5" p3="0.0" p4="0.0" p5="0.1" p5_extend_range="0" p6="1"
              retrigger="0"/>

The only difference is that parameter 0 is set to 0 or -1.

So if you load classic->saw and drag shape from 0 to -1 you have exactly the same thing you would have if you loaded classic->square

if it was loading a different wavetable or some such - or if there were any other way the oscillator was changed other than the param settings on front - then it would make sense. But the fact that you initialized with a saw preset (not "loaded a saw wavetable") is just a convenience.

With wavetable oscillator where this does matter we show the wavetable display on the front pane and keep it in the patch

But the fact that you happened to click this menu to get to shape = 0 rather than some other menu isn't a fact we really can remember across patches.

So to your point the "after they have morphed it in the spectral display" is exactly why we can't pick one to choose. If you choose saw, morph shape to -0.5, and choose square and morph shape to -0.5 you have exactly the same thing.

In other words: the classic oscillator is completely specified by and only by the 7 params on the front, and the choice is just presets on those.

[sense-amr]

What are you talking about is with regard to the code.. and with respect .. no one using the Synth to make patches cares about what goes on INSIDE the code .. or what those tab selections ACTUALLY mean or do .. they are only concerned with what it is in relation to their patch creation ..

Also the concept of "the user SHOULD know this or that" just sounds like arrogant and bad decision making in terms of UI .. the user ONLY knows what is there for them to use..

In this case they are presented with a multi layered tab selector that gives THEM the impression that these waveforms ARE distinctly different from each other.. therefore in my opinion AS A USER .. i feel the reference point for the selected waveform in Classic/Modern IS warranted giving the user the ability to SEE what waveform in the options provided.. by the UI , is selected..

So they can say to themselves OH .. ive used Classic -> Sine on Oscillator 1.. which i think is pretty standard information for a patch maker to have .. (despite the hubris around what they SHOULD know).. based on a display which reflects what they have CHANGED not what they have initially selected..

If it wasn't already clear before .. THIS is exactly the point of my request and subsequent issue creation ..

[baconpaul]

You are purposefully not listening to what i'm saying, so i'm done.
Enjoy surge!

[sense-amr]

ah ok ..
but i was listening ..
and attempting to understand how this relates to the benefit of the user.. thats all

[baconpaul]

right ok let me try one more time and see if it helps
When I say "parameter" above I mean "user editable parameter". Like "Slider on the front"
The only difference between choosing clasic->saw and classic->square is one slider is moved.
hold on i'll post a gif

here I am choosing classic/saw and then dragging shape to -1
and i get the exact same thing as classic/square
so after I do that drag to -1 which thing do you want checked
if classic was checked that would b nice. It's on the UI (right where it says classic).
But if you have a patch which is exactly classic/square because you dragged the slider, do you really want classic/saw checked because that's where you started?

:

[sense-amr]

But if you have a patch which is exactly classic/square because you dragged the slider, do you really want classic/saw checked because that's where you started? <-- YES thats all i was asking for .. but not so much modifying it .. just where you started.. because i understand the code probably sets those parameters to MAKE a "Square or Sine" etc.. as you have shown above .. but all the user see's is they have selected Classic -> Sine..

regardless of how technically stupid it might sound.. and i DO get that changing the parameters CHANGES the wave.. but the point is it exists as a UI element and a point of reference .. for making a patch.. so having a point to show thats where you started .. is usually helpful .. the fact that .. EVERYTHING can be changed when making a patch with regard to the shape and or constitution of a wave is the very basis of synthesis itself ..

I mean take for example a Fitler.. that you started off as HP .. but you messed around with the parameters so much that it now sonically represents .. somehing far outside the range of where a HP filter started.. you wouldnt say it was inapropriate to reference the filter type would you ? just because it can effectively be infinitely changed?

[baconpaul]

Right gotcha. So now we understand each other completely. And just don't agree! :)

Obviously you need to know your oscillator is of type classic. And we show that right on the UI! It would be nice if that was checked in the menu too for consistency.

But the fact that you had this particular preset starting point (aside from being technically painful to store but that's not the end of the world) seems really weird, especially when the state space of the oscillators is so enormous. And your comment is why I (sort of seriously) want to take away the presets for classic and modern and just give you the params. I think the presets confuse users into thinking they are different things, and they aren't.

But on the other hand, we check presets and let you edit those. (Although I always kinda hated that too). So it's not like i don't get it.

harumph.

[sense-amr]

The very fact that it can and will be changed dynamically and poentially infinitely is the very reason for why i suggested this ..
Because after changing the initial waveform so much a user might want to revert back to the original init design of that waveform .. .. as they are learning all the time when making .. in synthesis ..

So with a point of reference they are able to say .. ok ive used Sine HERE .. but i smashed the slider a bit hard.. and now ive changed the sound completely, lets go back to what it was .. and not move that slider so much this time?

[sense-amr]

I mean the only compromise i could see is to get rid of the secondary menu for Classic / Modern and some how have them all amalgamated into the one menu option .. Sine (modern) Sine (Classic) .. or whatever .. and allow a check next to them ..

[baconpaul]

(there is no classic sine by the way)

A lot of what you want comes from the defaults. For instance if you choose classic/saw and drag stuff and double click it returns to a default value.

and having a proper undo stack would also be lovely

let me ponder. i think the problem really is that we are exposing these presets at all but that seems pretty draconian.

[sense-amr]

Yes i understand what you mean about how they are technically generated.. but the user doesnt see any of that.. they just see the selection they can make .. and for them i guess that means Ive selected a classic Sine.. untill i morph it into something completely different to where i started.. (which is why i love surge) .. exclaimed the user to themselves with uncontrollable glee!

[baconpaul]

(except there is no classic sine :) )

[sense-amr]

Classic Saw or Square then :D

[sense-amr]

Ok so just to see if iv'e got your explanation correct and understood properly..

The Classic -> Saw is determined by a preset of numbers represented in code..

<snapshot name="Sawtooth" p0="0.0" p1="0.5" p2="0.5" p3="0.0" p4="0.0" p5="0.1" p5_extend_range="0" p6="1"
              retrigger="0"/>
    <snapshot name="Square" p0="-1.0" p1="0.5" p2="0.5" p3="0.0" p4="0.0" p5="0.1" p5_extend_range="0" p6="1"
              retrigger="0"/>

Any modification to those numbers is then NOT "Saw" anymore and would seem redundant in displaying it both from a code and UI perspective..

This makes perfect sense..

Is it perhaps then an idea just to display with maybe a "*" that the initial starting point has been modified ? from the UI perspective ?

would that entail less code problems or structural issues?

[mkruselj]

It would be equally problematic in code. Maybe even more, because it sort of ties into having an undo stack in Surge (so that you can compare states), which is not there and is a huge amount of work. That's all linked to #694 and #733, and these issues are not on our immediate radar.