Ideas for GUI

[magnetophon]

I think you can nicely arrange the main knobs in two pages of 5 rows and 9 columns, since screens are wider than they are tall.

The CAPITALS are names of groups, and the lowercase are knobs

OSCILLATOR PAGE

| FILTER:  | OSC A:    | OSC A: | OSC B:    | OSC B: | OSC C:    | OSC C: | OSC D:    | OSC D: |
|----------+-----------+--------+-----------+--------+-----------+--------+-----------+--------|
| moog     | type      | pmA    | type      | pmA    | type      | pmA    | type      | pmA    |
| ms20     | index/res | pmB    | index/res | pmB    | index/res | pmB    | index/res | pmB    |
| oberheim | octave    | pmC    | octave    | pmC    | octave    | pmC    | octave    | pmC    |
| freq     | phase     | pmD    | phase     | pmD    | phase     | pmD    | phase     | pmD    |
| q        |           |        |           |        |           |        |           |        |

ENVELOPE & LFO PAGE

| ENVELOPE -1 | ENVELOPE 0 | ENVELOPE 1 | ENVELOPE 2 | ENVELOPE 3 | LFO 0:    | LFO 1:    | LFO 2:    | LFO 3:    |
|-------------+------------+------------+------------+------------+-----------+-----------+-----------+-----------|
| attack      | attack     | attack     | attack     | attack     | type      | type      | type      | type      |
| decay       | decay      | decay      | decay      | decay      | index/res | index/res | index/res | index/res |
| sustain     | sustain    | sustain    | sustain    | sustain    | octave    | octave    | octave    | octave    |
| release     | release    | release    | release    | release    | phase     | phase     | phase     | phase     |
| drawing     | drawing    | drawing    | drawing    | drawing    | freq      | freq      | freq      | freq      |

I would love it if the L-R-offset and the macros would work like in helm. So one toggle for L-R-offset and one for each macro. Moving a knob when one of those toggles is on, will create a colored triangle on the knob. That triangle indicates how much L-R offset there is, or in which range a knob is moved by the macros.

Maybe each macro could have it's own color? Maybe when all the toggles are off, there is a triangle that indicates the minimum and maximum values of all the macros and combined with the offset? I haven't thought this trough and would love to hear your thoughts.

On top of that, I think it would be useful to have a page of knobs (filter and osc params) for each macro, so you can fine-tune the sound of one of the macros.

[ryukau]

Thanks for the table. It helps a lot.

Just in case, when I said Helm sytle, I'm thinking about tab view (same as tgroup). If I understand correctly, Helm's UI is just placing tab switch right next to the related controls.

[magnetophon]

By Helm style, I mean pie-points, like this:

I don't see any tabs in Helm. Where are they?

[ryukau]

I'll check the pie-point later.

Pressing the button below (I called this tab switch) basically switches tab to LFO, envelope or other modulations. It doesn't look like tab at all though.

[magnetophon]

Ah, right.

[ryukau]

Oscillator part of UI code generation is almost done. It looks like the image below:

Small knobs on top left of large knobs are L-R offset. I put small knobs there to reduce toggling between main and L-R offset. The look and placement of small knob is bad. I'll change it later. Is this OK to you?

The height of window is 700px for now.

If you have thoughts and/or ideas for this part of UI, please let me know.

[ryukau]

I forgot to add this. Currently using DigiFaustMidi.dsp on master branch, and nrEnvelopes and nrMacros are reduced to 3 to speed up compilation.

[magnetophon]

Looks great!

I'm not sure if it's better to rotate it 90 degrees, so it's wider then it is tall, like in the tables I made.

The 3Dcrossfade branch also compiles quite quick.

[ryukau]

↓ Vertical 1 column layout:

↓ Vertical 2 column layout (Filter can be 1 column):

There's 3 options:

1. Horizontal
2. Vertical 1 column
3. Vertical 2 column

I prefer (1) or (2), because they are less complex to implement than (3). I don't have strong opinion either of (1) or (2) is better than the other.

If you are OK with it, I'll go with vertical 1 column. It looks a bit compact than horizontal.

[magnetophon]

Thanks for making these!

The reason I wanted to rotate, is to better use the horizontal space on the screen.

Option 3 does that the best, so I hope it's not too much extra work!

If it's too much work, I prefer option 1, with the L-R-offset placement of 3. Maybe you can save some more vertical space by putting the names of the category (filter,A,B,C,D) to the left of the knobs instead of above the knobs.

[ryukau]

That's OK, I'll go with option 3.

Do you have idea for placement of X-Y pads for vector crossfade? They are better placed into macro tabs in my opinion. An idea is to extend the tab view to right, and place X-Y pad there. Thought it may be a bit long on horizontal side.

Also would you like to cut out the bottom part, or to put some UI on there?

[ryukau]

To make it clear, I meant vector cross-fade as cross-fade between oscillator ABCD (ab-cd and ac-bd).

[magnetophon]

Yeah, the ABCD-pads should be on the macros tabs. Maybe layout 1 is better after all. Then you can put the ABCD-pads to the right.

Where do you want to put the XYZ-pad?

There is only one, so logically it doesn't make sense on the macro tabs. On the other hand, it is a verry important control, and it would be nice if it is on screen (almost) all the time. A possible solution is:

|-------+----------|
| knobs | XZY-pad  |
| knobs | ABCD-pad |
|-------+----------|

The two lines that say knobs are the knobs from layout 1. The XYZ-pad will show the same values on all 8 tabs (since there is only one) The ABCD-pad will be different for each tab.

If we use layout 1, I would still like the L-R-offset placement of 3 and the names of the category (filter,A,B,C,D) to the left of the knobs instead of above the knobs.

Your thoughts?

Also would you like to cut out the bottom part, or to put some UI on there?

I don't understand.

[ryukau]

My initial plan for layout 1 is like the image below. An obvious downside is a large window size. Layout 2 is a bit tighter, so changing to it may helps here.

Just in case, I don't have strong opinion on this layout, and open to changing to other layouts. Packing widgets into a window is a hard problem for me, and exchanging different ideas helps a lot.

On the other hand, it is a verry important control, and it would be nice if it is on screen (almost) all the time.

I agree on this.

If we extends the width of macro tab view to put X-Y pads, I'd like to have an idea that where to put LFO and envelope controls. Perhaps add more tabs right next to macros?

If we use layout 1, I would still like the L-R-offset placement of 3 and the names of the category (filter,A,B,C,D) to the left of the knobs instead of above the knobs.

I'll provide the image of this version later.

I don't understand.

I was talking about space below the tab view on option 3. Hatched region in image below.

[ryukau]

The image below shows the alternative L-R offset placement. The label placement requires change in C++, so I'll do it later.

[magnetophon]

I was thinking something like this:

Downsides:

• It looks like the XYZ-pad is part of macro1-8 so in other words: like there is a different setting of XYZ for each macro. This will be confusing for new users, but it's not really a downside once you know the synth.
• The env&lfo params are not on screen at the same time as the filter&osc params. I think that is an OK compromise so the window doesn't get too big.

Could you put the knobs of the XYZ-pad also to the right, like in ABCD-pad?

Of course, both rows of tabs would be the with of the whole window. Also, it now looks like the Modulation tab is also selected, because I copy-pasted it. Of course, only one tab can be selected in this layout-idea.

[ryukau]

I'll work on to change layout to your last comment.

To make sure, are you OK with horizontal layout over vertical 1 column layout (option 2 in previous comment)? Vertical 1 column layout is a bit more efficient for saving screen space.

[ryukau]

I pushed X-Y pad and nested tab view layout to master. Please let me know if something is not working. It looks like this:

I made a decision to separate XYZ crossfades to 3 pads. It was easiest to implement. They are linked to each other and it seems OK to me. What do you think?

Current implementation of ABCD crossfade is explicit and very fast to use. But wasting a lot of screen space.

I'll experiment with replacing macro tab view to another representation.

[magnetophon]

Cool, I'll go try it out now!

Why did you display all ab_cd pads at once? I think it's not an important parameter, and it would be better to only show one of them at a time, switching together with the tabs.

I'll experiment with replacing macro tab view to another representation.

I don't understand.

[magnetophon]

The XYZ pads and knobs don't change the sound here. I used an Ardour project that was made with the previous DigiDrie version.

[magnetophon]

The ABCD pads and knobs also don't change the sound here.

[ryukau]

Thanks for testing. XYPads are fixed in latest master.

[magnetophon]

Yes, they work now, thanks.

[ryukau]

Why did you display all ab_cd pads at once?

They are in ad-hoc state. I'm not considering to staying them as is.

However, I'd like to avoid switching tabs.

Switcing tabs become deal breaker to me. I'd like to access particular parameter as fast as possible. When I use synth like DigiDrie, I spend most of time to changing around the modulation. And current macro tab view can introduce extra one click for each change.

This is also the point I said I'll experiment. I have a feeling that the modulation matrix I said previously may solve this issue, but may also introduce different problems. I may come up with different idea and it may not end up with the modulation matrix. That's why I used vague language.

[ryukau]

I added altmacroui branch for experimental UI. It looks like below:

See here for list of shortcuts. Just in case, labels and placement aren't polished.

Pros:

• No tab switching.
• Easy to manipulate row or column.
• Easy to manage mode.

Cons:

• Tiny knobs.
• Height is longer than tab view version. Increased from 700px to 800px.
• Limitation around copy/paste/link.

Highlighting is added to compensate tiny knobs. I have no problem to grab the knobs. However, I'm not sure if the size doesn't cause problem to most of people.

Limitation is that it can only copy/paste/link to row or column. In other words, those actions are coarse grained. Matrix can be separated to each sections (filter and oscillator A/B/C/D) for more fine grained action. However, separation makes it impossible to apply an action to all parameters in matrix, or all parameters in a macro.

I'm planning to port DigiDrie to VST 3, and VSTGUI can't render text rotation. So flipping row and column is not an option for now.

Feedback is welcome!

[magnetophon]

Thanks for making this.

Pros:

• No tab switching.

I think tab switching is not so much a problem when you have keyboard shortcuts. Just hit the number of the macro you want to be in, and start tweaking.

• Easy to manipulate row or column.

Why would you want to manipulate a whole row? (assuming you mean copy/paste/link)

• Easy to manage mode.

What do you mean by mode?

Cons:

• Tiny knobs.

That's OK, but in some cases, like octave, it would be handy to see the exact values of the parameter you are tweaking. For others, like PM, it's very handy if you can see directly if the parameter is exactly at 0, or not. It's not so handy of you have to hoover your mouse over every PM nob to find out why you are not hearing a sine, for example. So in those 2 examples, it matters indirectly that the knobs are small: no place to display exact values.

• Height is longer than tab view version. Increased from 700px to 800px.

Still OK, I think.

• Limitation around copy/paste/link.

This is the main problem, for me. I think the copy/paste/link functions are the most important part of the GUI. Without them, the macro system is not very usable. I mentioned in another post which copy/paste/link functions are needed in my opinion.

So for me, this GUI is not a good option, sorry.

A general remark about the GUI: In the faust gui, the phisical placement of the macro knobs helps to remember which ones belong together. In other words, the position of the knobs can, with a bit of imagination, be related to the position in the cube.

I kind of miss that in your GUIs. Your GUI makes it easier to tweak the sound of one macro, but harder to tweak macros in relation to each other.

Whatever GUI we end up with, I think we need to make it as easy as possible to do that.

[ryukau]

Did you even try it?

Why would you want to manipulate a whole row? (assuming you mean copy/paste/link)

A row is a macro. Edit: I misunderstood row to column.

What do you mean by mode?

Column/row selection and link modes are available for now.

For others, like PM, it's very handy if you can see directly if the parameter is exactly at 0, or not.

When parameter is 0, it's displayed as light color as the image in my previous comment. Non 0 (or non default) value is highlighted with more dark color.

That's OK, but in some cases, like octave, it would be handy to see the exact values of the parameter you are tweaking.

I think this is also a cons of matrix. However, I learned from this experiment that if I will implemente shortcuts to tab view, it will have same limitation. Existing tab view can't handle grouping of parameter, and if I made them to do it, it lose the information of parameter scaling. You said you won't likely looking into C++ code, but if you are interested in the problem I'll explain it.

This is the main problem, for me. I think the copy/paste/link functions are the most important part of the GUI. Without them, the macro system is not very usable. I mentioned in another post which copy/paste/link functions are needed in my opinion.

I'm not sure about "Without them" part. Copy/paste/link are already implemented. You also said following here.

Maybe that is too much work, and not so useful. We can decide later, after we made a bunch of sounds using only the simple copy function (the first).

So currently it only supports copy/paste/link between column (macro) and row (parameters go to a threeDmixer).

[ryukau]

Sorry, I misunderstood about row part.

It is useful for me to copy PMs to other ocillators. Also row can be used for link.

[magnetophon]

Did you even try it?

I am very sorry, I did not. It was quite rude of me to pass judgement anyway, please excuse me.

Now that I'm actually using it, I understand why you did this, and I love it!

I'll write a more detailed reply when I have played tested some more :)

[magnetophon]

How do I change the oscillator type?

[ryukau]

After some consideration, I realized that I lost interest in this project. Dismission to an experiment without even trying is beyond the border line to me. We are losing the benefit of cooperation.

With your skill, you can easily make a UI with framework like JUCE.

I'll fork this repository and modifies it to make my own vector synth.

So we can be both happy.

Good luck on your way.

---

To make sure, all my code under plugin directory is GPLv3. Files under plugin/dpf/License and plugin/dpf/lib belong to their own licenses.

[magnetophon]

Dismission to an experiment without even trying is beyond the border line to me.

Yes, that was a mistake.

We are losing the benefit of cooperation.

I'm sorry you feel that way; I was enjoying this a lot.

I'll fork this repository and modifies it to make my own vector synth.

That's good to hear. If I can help in any way, let me know.

Thank you very much for the code you wrote! All the best to you.