PG8X (inspired by the JX8P): new beta version uploaded

[martin_l]

BTW, Martin, i had a great idea for the 2/3/4-notch sliders.

Since you already have 2/3/4-state images for the highlight-positions, it would be easy to put the slidercaps onto those as well so that when the highlight switches, the cap would go straight to the right notch too. That way the caps could no longer move between notches, thus resulting in a much more realistic feel. The control-image could then either be the combined highlight/cap images themselves or an overlayed invisible image specially made for that purpose.

Would you like this?

Hi ENV1,

I think it would be better to include this 'locking to positions' into the code, controlling the sliders, rather than the GUI elements. If we have that, I think that the highlighting of the positions is no longer necessary.


Cheers,
Martin

i dont like the way the sliders "jump" immidiatly to the position the mouse is over when you first click on them. moving them from their current position with the scroll wheel is fine, but point and dragging is less than ideal and kind of fustrating.

You can prevent the jumping by holding SHIFT when clicking.
The current way is the default how sliders behave using the WDL-OL framework. I have to see how I could change that default behaviour.

Update: I just had a look in the code of the Slider class, and removed the snap to position command in normal mode. I added that "CTRL" + MouseClick will immediately put the slider to the position of the click.

This behaviour will be available in the next release.

[layzer]

BTW, Martin, i had a great idea for the 2/3/4-notch sliders.

Since you already have 2/3/4-state images for the highlight-positions, it would be easy to put the slidercaps onto those as well so that when the highlight switches, the cap would go straight to the right notch too. That way the caps could no longer move between notches, thus resulting in a much more realistic feel. The control-image could then either be the combined highlight/cap images themselves or an overlayed invisible image specially made for that purpose.

Would you like this?

Hi ENV1,

I think it would be better to include this 'locking to positions' into the code, controlling the sliders, rather than the GUI elements. If we have that, I think that the highlighting of the positions is no longer necessary.


Cheers,
Martin

i dont like the way the sliders "jump" immidiatly to the position the mouse is over when you first click on them. moving them from their current position with the scroll wheel is fine, but point and dragging is less than ideal and kind of fustrating.

You can prevent the jumping by holding SHIFT when clicking.
The current way is the default how sliders behave using the WDL-OL framework. I have to see how I could change that default behaviour.

Update: I just had a look in the code of the Slider class, and removed the snap to position command in normal mode. I added that "CTRL" + MouseClick will immediately put the slider to the position of the click.

This behaviour will be available in the next release.

sounds good, reversing the "jump to" and "ctrl+" slider movement behavior as default would be much better!

[martin_l]

sounds good, reversing the "jump to" and "ctrl+" slider movement behavior as default would be much better!

Getting confused now. Which behaviour would you prefer as the default, i.e. left mouse button, no modifiers?

The currently available beta (2015-02-22) has the following:

default: jump to mouse position
shift+mouse: don't jump and fine movement
right-click: open Midi Learn panel


The next version will have:

default: relative slider movement (normal pace, no jump))
ctrl+mouse: jump to mouse position (then drag at normal pace)
shift+mouse: don't jump and fine control
right-click: open Midi Learn panel

Unchanged: mouse wheel will increment/decrement the values.

Cheers,
Martin

[ENV1]

If I am not wrong, the values exposed to the host are ALWAYS continuous in the range form 0-1. That means, that using the host's GUI, you can always generate continuous movements.

Its always 0-1, but not necessarily always continuous in a linear fashion.

Example: The Downsampler Filter Stages param in your old SE version.

You have:

- 0.00000 alias 2
- 0.16667 alias 3
- 0.33333 alias 4
- [...]
- 1.00000 alias 8

Using VSTHost, (for example), one could of course type in numbers other than these since it allows for manual entering of numerical values. (Not all hosts might, i dont know.) However, using VSTHosts slider to set this control will never give you values other than these because it will jump directly to them, skipping everything inbetween. So its still between 0 and 1, but the linearity/continuity is broken. (Which is good.)

On the other hand, making the slider to 'click' into position, would mean that the plugin is always only reporting the quantised values to the host.

That would be optimal. (In my opinion.)

Now, that I have the LED readout panel, and possibly the n-way sliders, which click into position, these highlights are not really necessary anymore. So, they could be dropped. If you think that they look better, feel free to keep them.

No, i concur. I think the UI is large enough to see the positions well enough without the highlighting. I will strike them from the list of ToDos.

Getting confused now. Which behaviour would you prefer as the default, i.e. left mouse button, no modifiers?

My Opinion: This JumpToPosition mode is just about as annoying as the circular mode for knobs. Personally i think you might as well drop it entirely because except for making a CS-80 style bender ribbon i cant think of one single scenario where this kind of behavior would actually be helpful in tweaking a control such as a common slider.

My vote would therefore go to this schema:

default: relative slider movement (normal pace, no jump)
shift+mouse: don't jump and fine control
right-click: open Midi Learn panel
mousewheel: fine control

[EvilDragon]

My Opinion: This JumpToPosition mode is just about as annoying as the circular mode for knobs. Personally i think you might as well drop it entirely because except for making a CS-80 style bender ribbon i cant think of one single scenario where this kind of behavior would actually be helpful in tweaking a control such as a common slider.

My vote would therefore go to this schema:

default: relative slider movement (normal pace, no jump)
shift+mouse: don't jump and fine control
right-click: open Midi Learn panel
mousewheel: fine control

Agreed. Drop it!

[layzer]

yeah, what ED and ENV1 said. sorry for the confusion

[martin_l]

My Opinion: This JumpToPosition mode is just about as annoying as the circular mode for knobs. Personally i think you might as well drop it entirely because except for making a CS-80 style bender ribbon i cant think of one single scenario where this kind of behavior would actually be helpful in tweaking a control such as a common slider.

My vote would therefore go to this schema:

default: relative slider movement (normal pace, no jump)
shift+mouse: don't jump and fine control
right-click: open Midi Learn panel
mousewheel: fine control

Agreed. Drop it!

Well, I think having the option to jump using CTRL+mouseclick does not hurt those who don't like it. Simply, don't hold CTRL, but at least it gives a further option for some who might want it.

So, I will go with the scheme I have implemented last night in my personal version.

[davetbass]

Sorry if I don't completey understand this but I had a question about values exposed to the Host and it might be related

in LMMS with host Vestige, there is a panel which shows all the knobs that are connected to UI

in order to record mod wheel data and play it back, currently you need a "Mod Wheel" button on the panel

for example Phutura has one:

http://www.phuturetone.com/phutura.php

is this something that can be added to the PG8X?

and not to be a wise guy, but let's not divert the man's precious time to the panel color, the sonic color is what's important, although I do get kind of sentimental looking at the panel, remembering when I used to play one in the music store, depressed I could never afford one, haha good times !

As I said earlier, I have not tried LMMS and Vestige. But, can't you just record MIDI data in it? How do you record the notes? Mod Wheel is just MIDI CC 1, and you should be able to draw these MIDI messages in the same way as you draw the notes, if you don't have a MIDI keyboard.

Thanks Martin, it can record the MIDI data, it just doesn't respond to the recorded data on playback, but that's the fault of Vestige, Although VSTi with "mod wheel" in the toolbox can do it
but I don't understand how to explain what that is. Thanks!

[ENV1]

Heres my proposal for a final UI.

Most important changes:

- Blueish-grey background similar to Roland SH-101

- Integrated all except MIDI related controls where they make sense in order to minimize 'paneling'

- Shortened all 2-step sliders to actually required size

- Rearranged and finished membrane buttons

- Added LEDs to membrane buttons

- Adapted display background to accommodate 2x27 characters

- Added ML-VST logo


The only extra panel needed now is that for the MIDI stuff. This is up next.


Things im not happy with:

- POLYPHONIC SYNTHESIZER in red. It clashes like hell with the background. I would recommend a blueish tone here because that would look fine.

- Position of Display. For symmetry reasons i would have preferred to put it above the membrane console, (like on the real JX-8P), but that wont be possible if the vertical size is to remain below 768px.


Screenshot:

click for fullsize

[Spitfire31]

Looks very slick.

My final objections:

1) I find the background too dark, meaning not enough contrast between the dark background and the slider controls. I was much more comfortable with the lighter and slightly warm background.

2) I'm dead against the bluish tone that you seem to like so much. Whatever does the SH-101 have to do with this instrument?

I hope that the next version of this quite wonderful instrument will be skinnable…

However, very pro job on the GUI, even if I, as a longtime photo and video pro, disagree with the background tone.

Kind regards,

Joachim

[EvilDragon]

That looks neat!

Why not align the display with the membrane buttons vertically? Then center the logo above them both? Also, I'd put the ML-VST logo on top as well - doesn't make a whole lot of sense to have it in Osc section just to fill in the void...


Topnotch job otherwise!

[martin_l]

I think, I would keep the panels, at least one more 'advanced' panel. The last GUI is getting too crowded with all the extra controls (which were not available on the hardware) exposed on the main GUI.

Would it be possible to make the slider backgrounds a bit lighter. They seem much darker than the background, and having them a bit lighter would give the slider caps more contrast.

My Logo could be at the top, besides the PG-8X.

Cheers,
Martin

[ENV1]

Like i said, i wish it were different but to make a UI that is to the liking of everyone just isnt possible.

Right now what matters the most is whether Martin likes it, otherwise ill be redoing this background forever.

(And Martin said he liked one of the older drafts which was a similar grey, so thats what i went with now.)

I can still make some different BGs later. Now i really need to focus on one direction, otherwise i will never get this done.

[ENV1]

I think, I would keep the panels, at least one more 'advanced' panel. The last GUI is getting too crowded with all the extra controls (which were not available on the hardware) exposed on the main GUI.

So you mean 2 extra panels?

MIDI and one other?

Which controls exactly should i put on the 'other'? (List would be cool.)

Would it be possible to make the slider backgrounds a bit lighter. They seem much darker than the background, and having them a bit lighter would give the slider caps more contrast.

Sure, no problem.

I made them darker because they are darker than the BG on the real programmer, but i actually would like them brighter myself, so im glad you say 'brighter'.

My Logo could be at the top, besides the PG-8X.

Ill see if i can squeeze it in.

(Will have to shrink it then though.)

[jbuonacc]

click for fullsize

i think you've done a hell of a job with this so far.

- i noticed that the VirtualCZ synth has a nice background similar to what you need for this. check it out.
- why is the 'G' in "PG-8X" shaped wrong? looks silly.
- i agree that the red text looks crap at the top. the size looks off as well.
- the screen would look better centered over the membrane buttons.
- the logo looks absolutely cheap and hokey, this synth deserves better. it would also look like crap anywhere except where it is, or at the top left corner of the synth.

are you done yet?