Surge: Morph is an OK-ish name but the display should show position in WT as well as percentage

[mkruselj]

Wavetables are not actually morphing anything, they are crossfading content, unless they calculate wavetables in realtime rather than using samples. As such, it should be renamed to Position, because that describes the position within the sample that is being read out as part of the wavetable.

[baconpaul]

@sense-amr and @itsmedavep your thoughts?

[itsmedavep]

I don’t disagree with the sentiment. I stated the same thing elsewhere when making the label change.

The thing is, that’s not what the slider does.

That slider doesn’t actually switch wavetables discretely. It would interpolates between them. Hence the % based control and finally the resulting name of morph.

At least from the code and previous conversations that’s my understanding.

So I think the right thing to do to fix it properly is twofold

1 update the control to actually switch wavetables as you manipulate it (instead of interpolating)*edit. i take it back I think the control precision is fine.

2 change label to wt position

[baconpaul]

If you don’t want to interpolate use window rather than wavetable right?

(Almost on vaca!)

[itsmedavep]

I believe so but I’m at a client site and can’t confirm.

Regardless a % based control for this is contrary to my expectations. What does 32% of a wavetable’s position mean when using a 1024 wt? I can do the calc but it’s not very useful to me if I have to break out maths to figure it out.

My expectations would be a label of “wt position”

When dragging the control it would display which wavetable your currently on. Wt position = 35

Finally a control that simply moves you through all content in a wavetable.

At a high level the semantic difference between morph or cross fade is weak. Ymmv.

Like what is morphing?
What is a cross fade?
How are they different from one another.

[baconpaul]

There’s a technical problem that the max value of a parameter is a feature of the parameter “once” so if you went real value (like 13.4 is 60% of table 13 and 40% of table 14) you couldn’t make the control respond of table counts changed which they do. That’s why a percentage, while maybe aesthetically unpleasant, is definitely the appropriate implementation given the constraints of surge and our hosts in 1.6

[baconpaul]

(And really really almost on vaca)

[baconpaul]

Oh shoot a final thought. You may be able to change the string representation of this parameter. So keep it as a 0-1 param but have the parameter string stuff just for this one param multiply by wavetable count so the display goes to “table 13.4 (62%)” when you drag. No change to the mechanism internals just the display semantic. Since I’m now out for real and don’t quite know how to do this anyway but it’s kinda like that lfo code Dave, Ill just leave this vague idea hanging here.

[itsmedavep]

@baconpaul Thanks, you articulated what I was very poorly attempting to get across. It just becomes

wt position = 32 of 1024 on the label. The control itself is good for precision.

[sense-amr]

Interesting, i was sure i already made an issue about this with details
in any event .. i think "position" is heading in the right direction and the main points for User functionality is "what can i do to SEE where i am" and "What am i doing with this slider"..

Position is already represented as "%" which means nothing to an end user when he says to himself "OH I REALLY LIKED THAT SOUND AT WT Position 65.7%" .. no one is going to write that down nor is anyone going to resonate with that as a recallable position .. that they as a user can get to again easily..

I propose "Wt #" because THATS actually exactly what it is .. you are AT a particular point in the WT for use.. this also makes it recallable for a user. in their mind to say they can easily recall .. the position of the wavetable they liked the sound from .. oh its "Wavetable Makingwaves.wt and its number 56 on the slider" ..

To this end i could even propose the more precise nomenclature of "index"

[sense-amr]

incidentally .. with regard to the title of this issue .. which i already opened .. before .. Wavetable position in Surge has never been labeled "Morph"

https://github.com/surge-synthesizer/surge/issues/725

[sense-amr]

untill now!! :)

[mkruselj]

Hopefully for the short term :P

[itsmedavep]

After much heated debate the resolution was:

The control should be float.
The wt index your currently on would be nice to display
Evil would like the slider display when dragging to be a % and to show it that way in his DAW as well.

I would like it to be "wt position = 1 of 512" in the GUI when dragging. That is work though.

Also, we landed on an understanding that "morph" is a compromise. It isn't entirely inaccurate as a description of what the slider is doing to the sound based on using the term as a transitive verb.

So kinda close to a resolution.

[sense-amr]

ahh yes and of course remembering it was My issue to begin with :)
hooray!

[baconpaul]

That display is slightly tricky. What you need to do is change morph from a ct_percent to a new type ct_wavetable_percent and then make Parameter format it differently; but it needs to know the max count to do that formatting which you can't store on max, since you still want the value to go 0-1 to not break existing patches. (Just a quick git sweep this morning)

[itsmedavep]

So it's basically, know if its 256, 512, 1024 frames or whatever we end up supporting. Multiply it by the %(float) and then floor the result to be used for GUI display. That about capture it? We keep the control as is right? Only do the math for the label display.

Do we know what the attributes of the .wt files are since we open them to play back? How many frames, how many samples per frame, etc?

[baconpaul]

The number of tables is any number > 5 so it’s not limited to power of 2 and is different for each loaded .wt file. We do know it when we open it and we know it for the current one we have loaded but the place we know it (the oscillator basically) is “far away” from the place we make the string in the parameter so there’s some surgery to be done I fear to get it plumbed through.

I’m away from my computer but I wonder if the parameter type has any place to stash the extra format info? Like if Parameter.h has “void *userData” then we can have the oscillator set the table count on the parameter when we load a different .wt and use that in the display.

Oh we will also need to change the render type from ct_percent to something like ct_percent_with_count (a type we make up)

Again I’m away from the code and this is just ideas from memory but i think yeah that’s the basics of how to do it.

[baconpaul]

So reading through this it seems you all agreed:

1. Among the set of bad names, Morph is not that bad so lets leave it
2. The tooltip should be modified to show position even though the underlying value (which the DAW and what not shows) stays as %

So I changed the title to that and bounced this to 1.6.n

[baconpaul]

If we can accomplish this, with a separate control, we could also add a “supports quantization” which means the drag could snap-to-exact optionally (but still allow modulation). This was a comment by Oberlai on slack