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

[ENV1]

It's really a bitch of a material, I agree!

You can say that again!

[ras.s]

• * Number of voices is now stored per preset
  * new global gain (+6dB, 0, -6dB) added
  * retrigger mode for MONO1/2 added
  * VCA level as function of slider position updated (closer to hardware)

Nice update, especially that storing the number of voices. I don't know if this has been asked before, but could it be possible to have the plugin load a default bank on startup? Like if there's a file called "default.PG8XBank" in the same folder as the plugin, it would try and load that. That would save a few mouse clicks when getting started.

Cheers.

[Schiffbauer]

ENV1 - why a GUI with grey buttons ? - for a real emulation (and this is a real emulation (I had the JX8P for
several years and used it intensively)) the PG8 needs the right colours too.....
The GUI with the coloured buttons is great, so why not.

BTW, that´s a really good and surely hard work, Martin....my compliments....
best regards
Armin (aka Kujashi)

[crimsonwarlock]

It's really a bitch of a material, I agree!

You can say that again!

Roland made that color specifically so that if anyone, somewhere in the future (back then) would try to emulate this synthesizer, it would appear to be impossible

When this thing is finished, Roland's response will be: "OK, it does sound pretty good, but hey, that GUI color is totally off.... epic fail"


Serious respect for the effort so far, both the synthesizer itself and the GUI. Keep going guys, it's a classic in the making.

[martin_l]

ENV1 - why a GUI with grey buttons ? - for a real emulation (and this is a real emulation (I had the JX8P for
several years and used it intensively)) the PG8 needs the right colours too.....
The GUI with the coloured buttons is great, so why not.

BTW, that´s a really good and surely hard work, Martin....my compliments....
best regards
Armin (aka Kujashi)

Thanks, Armin.

Yes, I definitely vote for the coloured membrane buttons, and ENV1 is working on them,

By the way, once the version 2 is out, I will convert your banks to make them available to the new version.

Cheers,
Martin

[ENV1]

Why a GUI with grey buttons ?

The GUI with the coloured buttons is great, so why not.

Like i said, that was a screenshot from an older pre-resize draft, which means it didnt have the membrane style buttons yet. (Which BTW arent finished yet either, its all just placeholders right now.) It was only meant to show the BG style im leaning heavily towards, i.e. the soft semi-dark grey with a touch of glare.

The grey buttons were actually inspired by the ones found on the real programmer and only served as placeholders too. I guess since Roland has used this very type of buttons on the JX-10 (amongst others) they probably would have worked as an acceptable alternative to the membranes too, but thats not what Martin wants for this plugin, so membranes it is.

[ENV1]

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?

[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

[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.

Yep, that would be even better.

(As this method would also 'delinearize' the automation values exposed to the host.)

So you dont need the highlight images anymore? Or did you plan this change for sometime later down the road?

[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 !

[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.

[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.

[martin_l]

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.

Yep, that would be even better.

(As this method would also 'delinearize' the automation values exposed to the host.)

So you dont need the highlight images anymore? Or did you plan this change for sometime later down the road?

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.

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.


About the highlights on the n-way sliders, I added them in the old synthedit version, where I had the small numeric readouts below every slider and knob.

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.

[martin_l]

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.

[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.