Step shapes about bschaffl HOT 22 CLOSED

Tab 1 will hold the present content of the box

Yes, if by the box you mean the amp section.
Tab 2 will hold the shape editor for the whole pattern, not just one step. So the whole pattern is one totally free form shape, like in B.Shapr.

I'm not sure if it is worth the effort, as I think you can get 80% of the results you would want from tab 1, but if you feel that is not flexible enough, then I think it makes sense to go totally free-form, and reuse the wonderful code from B.Shapr, but for midi.

from bschaffl.

Now I got it. Tab 2 (free form amp curve) replaces tab 1 (amp sliders) or vice versa depending on which tab is activated.

If tab 2 is activated:

• Step numbers should be visible too (as in tab 1)
• Step markers should be visible and movable too (as in tab 1)
• Amp swing should be inactive or invisible

Interesting. This would be some bigger work to do. Likely it will some time.

from bschaffl.

Consider also the sequencer64 method of LFO shape drawing for discrete events, it's kind of like that.

from bschaffl.

Consider also the sequencer64 method of LFO shape drawing for discrete events, it's kind of like that.

Thank you for this idea. You would indeed get something similar here if you convert back a shape to sliders. But the idea behind an optional shape is "drawing" a smooth amp progression curve.

from bschaffl.

Shape edit mode added in f54ef35.

I decided to go the XOR way. The Multiply way might be a bit to complex for the users (keep both, sliders and shape in mind, plus mixing dials or sliders for both, ...). And I want to keep it simple :-).

You can also convert data in both directions. And you will have two options to convert from sliders to shape. Try and you will understand the difference.

The big auto markers button is gone. But you will find a symbol in the new toolbox instead.

from bschaffl.

Thanks for explaining.
I would say OK/cancel is safe enough, but ok.

OK, you can undo, but only in the shape mode (yet).

Great to hear you are working on wider undo support.
I guess once the sliders in this plugin have it, it's easy to port over to the others as well, no?

from bschaffl.

Reset, undo and redo for sliders added in ba1e35c. Also switched to OK/Cancel.

from bschaffl.

If you are going to pick one, I would say c) makes more sense then b), musically.
You more often want the start of a subdivision accented then the middle.

That being said, I tend to favor more options on plugins over fewer.

from bschaffl.

I agree c) makes more sense from musical POV. My ears would expect c), but my eyes b).

from bschaffl.

One more question: Step-specific shapes or the same shape for all steps ?

Step-specific shapes are only applied to the respective step. I think about (at least) three options: constant (= a), linear (= c), and sinusoidal. The shape can be symbolized above or below the respective step amp slider. Combining of type b shapes and type c shapes wouldn't be possible in this way (conflicting overlap). Therefore no type b shapes.

The same shape for all steps variant, however, has the (only) advantage that you can decide between type b and type c shapes.

But with step-specific shapes you are more flexible.

from bschaffl.

I think I'd prefer the same shape for all steps.

Instead of b and c being separate shapes, I'd like them to be accessible via a phase slider.
So IOW:
phase = 0 -> shape c
phase = 0.5 -> shape b
phase = 1 -> wrap around to shape c
Of course the in between values would be available too.

from bschaffl.

I'm imagining two tabs for velocity: one with the sliders and one with the shape editor, just one shape for the whole pattern.
Similar to how ZynAddSubFX has knobs for adsr, but you can also click free, to go to a graphical editor with infinite points.

Bonus points for copying over the settings from the sliders tab to points on the graph in the shape editor. :)

from bschaffl.

A phase slider would be an interesting idea for "accentuation". A single phase slider would be compatible to both, step-specific shapes and a global shape for all steps. Even step-specific accentuation sliders (or better: markers) would be possible if combined with the basic three shape types mentioned before. But on the other hand, there is a real danger to make it too complicated for the user. I'll make a sketch about the different options later.

On the other hand, I do not fully catch your idea with the tabs yet. Likely I misunderstood something. I guess you mean two tabs above the box containing all the up to 16 step sliders, and the markers, and ... Tab 1 will hold the present content of the box (the 16 step sliders, and the markers, and ...) , tab 2 will hold the shape editor for one shape (representing all shapes as all shapes would be the same)? Wouldn't it (tab 2) a bit oversized as there are only two parameters you can modify (shape type and accentuation)? In theory I could implement the full shape editor options from B.Shapr (editing points) to fill the space. But this would be an overkill and the benefit is rather limited. Therefore I wrote it "will be too much" in my initial comment to this issue. But still, a whole tab for a minor feature, wouldn't it be an over-representaion ?

from bschaffl.

The sketch of the idea I had before. There are three different shapes for each step: const., linear, sinus. See popup menu, the displayed orientation of the shape is automatically swapped from left to right or vice versa. The accentuation slider is set to the start. This means that the amp slider value is applied at the start of the respective step and kept constant (const) or is faded to the next step amp slider value (linear, sinus). The yellow curve is only for visualization of the sequence position-dependent amp value. If accent is 0.5, the yellow curve is shifted by 0.5 steps to the right.

Randomness sliders (as discussed in #10) are already included.

from bschaffl.

Coming back to your idea. One tab for sliders and one tab for a shape.

There are different ways to combine both tabs.

1. XOR.
   This is what you suggested before. The input note velocity is multiplied with either the respective slider value or the respective shape value depending on which tab is activated:
    
   output_velocity = input_velocity * (mode == SLIDER_MODE ? slider_value : shape_value)
    
   Although this is rather easy to understand for the user, the tabs may be confusing. Usually, tabs host additional options, not options that exclude each other. Maybe an other widget (e.g., a switch) may help.
    
   Copying (or better: translating) values from sliders to a stepped shape or from a shape to sliders isn't a problem from the programmers side. But this will overwrite data of the respective tab. This can be confusing for the user.

2. Multiply.
   Both tabs are taken in account for the calculation of the output note velocity:
    
   output_velocity = input_velocity * slider_value * shape_value
    
   This is a bit more complex to understand for the users. But there will be no need to translate values between sliders and shape. You use both of them simultaneously.

3. Switch on/off tabs.
   This is a feature you can also see in Helm and will be an extension to idea 2). If both tabs are switched on, then you will get the same behavior as in 2). If one of the two tabs is switched off, then its value (slider_value or shape_value) is set to 1.0. And the behavior would be the same as in 1). Of course, there is also no copying or translating data between the tabs required.

There is another fact to take in account:
Sliders are exposed as control ports and can be automated. Shape points not (OK, it's possible to expose them as control ports too as demonstrated by Alex T. in ZLFO, but there a lots of limitations, like a large amount of control ports are needed and the control values aren't independent from each other).

from bschaffl.

Thanks for considering this.
I'd like to repeat that I can imagine this being more work than worth it, in terms of utility for the user.
You can judge that much better of course, I just don't want you to feel pressured in any way.

the tabs may be confusing

Agreed.

Copying (or better: translating) values from sliders to a stepped shape or from a shape to sliders isn't a problem from the programmers side. But this will overwrite data of the respective tab. This can be confusing for the user.

I think copying should be a user action, as in ZynAddSubFX. I know that under the hood, it isn't copying but translating, but from a user perspective, you "copy the effect".

I don't understand how a shape can be translated back into sliders, as the whole point of shapes is to be more flexible then sliders, no? Would be awesome if you could make the transition work both ways though!
Maybe you meant translating a subset of shapes into sliders?

2. Multiply.

I like this as an additional option to 1.
Could each "tab" get it's own "Amp process" control, in addition to an overall "Amp process" control?

But there will be no need to translate values between sliders and shape.

From a user perspective, this would still be cool to have, as it will allow you to quickly get a rough shape going using the sliders, and then fine-tune it using the shape tab.
Or to copy to the shape tab and then add additional modulation using the sliders,in case you go for "2. Multiply".

Switch on/off tabs.

If you add "Amp process" sliders per tab, this would be unneeded.

Shape points can not be automated.

I think that's an OK trade-off.

Originally I imagined that when you hit the copy button, the sliders would get automatically reset, but I think it would be nicer if just the "Amp process" would get set to 0.
A separate button should allow you to reset the sliders.

As a matter of fact, I think reset should be default on most of your plugins.
More specifically: the ones that have lots of controls and also don't change anything when in the default (reset) state.

Undo/redo is also always great to have, but iiuc a lot of programs don't have it cause it's a pain to implement.
I'm hoping it would be easier for you since you already have it on some of your plugins.
Shall I make separate issues for these ideas?
I think I already asked for a reset button for one of your plugins, but I can't find the issue right now.

from bschaffl.

I don't understand how a shape can be translated back into sliders, as the whole point of shapes is to be more flexible then sliders, no?

It would be a reduction of data. Let's take the following example: You draw a smooth sine wave-like shape in the shape editor. If you switch to the sliders, the midpoints of each step of the shape are translated to the sliders. But if you then switch back, the sliders are translated back to the shape resulting in a sine wave-like stairway shape.

from bschaffl.

Gotcha. Nice solution!

from bschaffl.

@mxmilkiib Oooh, that's nice! I want that in ardour! :)

from bschaffl.

Thanks, very nice!

Minor issues:

• When I click on the convert button, I would expect to convert from current tab to the other tab.
• Why is there a do nothing option instead of OK-cancel?
• Why is do nothing the default?

from bschaffl.

When I click on the convert button, I would expect to convert from current tab to the other tab.

POV. Import (present behavior) vs. export.

Why is do nothing the default?

Converting is destructive. If you convert, all your shape (or slider) data go away. OK, you can undo, but only in the shape mode (yet). Nevertheless it is a potentially dangerous action. Therefore, you actively have to select a converting option.

Why is there a do nothing option instead of OK-cancel?

Safer than OK/Cancel. I think.

from bschaffl.

Once an undo option is also established for sliders, "do nothing" can be replaced by "OK"/"Cancel". I think. This would also result in reduction of code :-).

About the other plugins. I think we only talk about B.Choppr.

from bschaffl.