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

VST, AU, AAX, CLAP, etc. Plugin Virtual Instruments Discussion
Locked New Topic
RELATED
PRODUCTS
pg-8x

Post

Ben [KVR] wrote:Jeez guys. Stop with the bickering. Let things go. Go outside, float downstream. Chill the f**k out!
No prob.

Post

Ben [KVR] wrote:Jeez guys. Stop with the bickering. Let things go. Go outside, float downstream. Chill the f**k out!
http://www.youtube.com/watch?v=UacV3KwYsR0
HW SYNTHS [KORG T2EX - AKAI AX80 - YAMAHA SY77 - ENSONIQ VFX]
HW MODULES [OBi M1000 - ROLAND MKS-50 - ROLAND JV880 - KURZ 1000PX]
SW [CHARLATAN - OBXD - OXE - ELEKTRO - MICROTERA - M1 - SURGE - RMiV]
DAW [ENERGY XT2/1U RACK WINXP / MAUDIO 1010LT PCI]

Post

Maybe I should through into the discussion that much of the problem is caused by the attempt to be also AU compatible, bringing up the good old Mac vs. PC flame.

Or that I am not using zero-delay filters ( WHAT!!??? ), and finally whether DCO synths (such as the JX8P) are analogue or not (or even whether it is analogue or analog).

Come on guys, we had already too many threads here on KVR which end in mayhem. So, can you PLEASE just stop this childish behaviour here, before the thread get's blocked, or I loose my motivation of developing plugins in the first place...


Admiral Quality had some valid points here which I will take onboard and investigate further. I do not agree with all his conclusions (and not necessarily with the way they were presented), but what I will finally implement will depend on what really works without inconsistencies.

Clearly, there is the debate on keepers and restorers. I am currently searching the plugin developer forum here to see previous opinions on that. It also seems to me that both can be implemented properly, possibly by abandoning the VST-own preset system. I might start a new thread in the developer forum to investigate that further.

My personal preference still is the model where one has to write the current patch into the bank, and save the bank to make it permanent.

My reasons for this are:

Many people are using MidiLearn to control the sound while playing. If every change of the patch immediately is permanent, every performance will contaminate the bank. If I do sound design, it is an easy to hit one button so WRITE the sound into the bank.

Explicit saving of the bank helps to keep different projects separate of each other. If written sounds immediately go into a default bank, a different project will get affected by changes in another project.

The model I am having in mind, which fits best into my workflow, when working with plugins is as follows:

* Changes to parameters are not automatically saved.
* A write button saves them into the bank.
* The bank needs to be explicitly written to disk to make it available to other projects.

HOWEVER:

* When saving a project, BOTH the current patch (with changed parameters and a 'dirty bit') as well as the current state of the bank (with all WRITES which have happened in the project) are saved with the project and restored when loading the project again.

If the host is taking regular snapshots, NO edits to the patch should get lost, as the current (dirty) patch should be saved with every snapshot.


I am even considering to implement a Keeper/Restorer switch in the settings, if I manage.

Obviously, this will be quite a task for me to get it working all consistently, and I hope I can get your support on this (regardless of which religion you are).

Obviously, the most important goal is to develop a plugin which WORKS.


OK, please let the mutual insulting behind now. I on my part will be back to development work, trying to experiment with various preset schemes. A particular headache seems to be the AU plugin...


Cheers,
Martin

Post

martin_l wrote:Or that I am not using zero-delay filters ( WHAT!!??? )
Yeah, how come that's not happening? :scared: :help:

Post

martin_l wrote:My personal preference still is the model where one has to write the current patch into the bank, and save the bank to make it permanent.
Thats 100% KORG/hardware style, and its a good system too because technically it will allow for both restorer and keeper behavior at the same time. (Thanks to the write function, which keepers like SynthEdit plugins dont have, hence they keep in any case.)

- If you want restorer behavior, dont write until youre certain that you want to keep the edits.

- If you want keeper behavior, write the preset and you can switch to another without losing anything.

Kind of a vari-solution, if you will. As long as it is explained in the manual, nobody should have a problem with it.

Post

ENV1 wrote:
martin_l wrote:My personal preference still is the model where one has to write the current patch into the bank, and save the bank to make it permanent.
Thats 100% KORG/hardware style, and its a good system too because technically it will allow for both restorer and keeper behavior at the same time. .. As long as it is explained in the manual, nobody should have a problem with it.
I agree but, if this changes, I won't be too upset...it is the sound of the synth that matters most.

:phones:
바보

Post

Your solution sounds fine to me, Martin. And keep going with that plugin. I think it sounds damn good and offers a good interface. I'm sure many, many people appreciate it.

Post

With the current implementation (on Mac OS 10.9.3), when I re-Save an fxb that I've Loaded previously and then edited, in the system Save dialogue the title becomes the whole path of the file, with the previous file name at the end, like so:

/Users/Joey Coole/Desktop/PG8X files/[file name].fxb

I assume this is not intended behaviour? At least I've never seen it before.

Also, since I'm mainly a tweaker – if I tweak an existing patch and then want to

1) keep the name but add, say my initials and a number (for example CELESTE 1_JS01)

and

2) save the tweaked and renamed patch to another slot without overwriting an existant patch,

how do I do it, without having to re-type the original name of the patch?

This is something I do a lot, so a smooth workflow in this respect would be appreciated. ;-)

Kind regards,

Joachim
If it were easy, anybody could do it!

Post

Spitfire31 wrote:With the current implementation (on Mac OS 10.9.3), when I re-Save an fxb that I've Loaded previously and then edited, in the system Save dialogue the title becomes the whole path of the file, with the previous file name at the end, like so:

/Users/Joey Coole/Desktop/PG8X files/[file name].fxb

I assume this is not intended behaviour? At least I've never seen it before.
That is strange. I cannot reproduce that on my Mac 10.7.5 system. As far as I can tell, the dialog box is created by the system. I will have a look into it.
Spitfire31 wrote: Also, since I'm mainly a tweaker – if I tweak an existing patch and then want to

1) keep the name but add, say my initials and a number (for example CELESTE 1_JS01)
That is already fixed, but I have not yet released that version. The name editor will be initialised with the current name of the patch, rather than a blank field.
Spitfire31 wrote: and

2) save the tweaked and renamed patch to another slot without overwriting an existant patch,

how do I do it, without having to re-type the original name of the patch?

This is something I do a lot, so a smooth workflow in this respect would be appreciated. ;-)

Right now, you can save a patch into a different slot by clicking WRITE and then selecting a different programme (while the programme number is displayed in red).

As you have seen in the earlier discussions about the preset system in this thread, I am rethinking the system at the moment. It is very likely to change in some way. I still have to experiment with different methods, before I will settle on the one, which is working consistently, and makes most people happy. As I can see, whatever that system will be, it won't make everybody happy, but I will try to do my best.

As I said before, I am happy to hear what people see as their preferred workflow.


Cheers,
Martin

Post

ENV1 wrote:
martin_l wrote:My personal preference still is the model where one has to write the current patch into the bank, and save the bank to make it permanent.
Thats 100% KORG/hardware style, and its a good system too because technically it will allow for both restorer and keeper behavior at the same time. (Thanks to the write function, which keepers like SynthEdit plugins dont have, hence they keep in any case.)

- If you want restorer behavior, dont write until youre certain that you want to keep the edits.

- If you want keeper behavior, write the preset and you can switch to another without losing anything.

Kind of a vari-solution, if you will. As long as it is explained in the manual, nobody should have a problem with it.
Having the KLC for years, and the KLC being at the permament top of my "gear" (with FM8) I would say that it is the solution I prefer by far, since it is the one I'm used for almost 10 years, and since it seems to me one of the most guarantied solutions for any loss of data.
Build your life everyday as if you would live for a thousand years. Marvel at the Life everyday as if you would die tomorrow.
I'm now severely diseased since September 2018.

Post

BlackWinny wrote:
ENV1 wrote:
martin_l wrote:My personal preference still is the model where one has to write the current patch into the bank, and save the bank to make it permanent.
Thats 100% KORG/hardware style, and its a good system too because technically it will allow for both restorer and keeper behavior at the same time. (Thanks to the write function, which keepers like SynthEdit plugins dont have, hence they keep in any case.)

- If you want restorer behavior, dont write until youre certain that you want to keep the edits.

- If you want keeper behavior, write the preset and you can switch to another without losing anything.

Kind of a vari-solution, if you will. As long as it is explained in the manual, nobody should have a problem with it.
Having the KLC for years, and the KLC being at the permament top of my "gear" (with FM8) I would say that it is the solution I prefer by far, since it is the one I'm used for almost 10 years, and since it seems to me one of the most guarantied solutions for any loss of data.
As Admiral Quality indicated, there are inconsistencies of this approach with the "VST" bank approach. I noticed that myself and agree with his conclusions on this point.

However, it is not a big deal. The solution is to only expose 1 patch to the host and do the preset handling completely inside the plugin. This is, how many plugins on the market work.

I also had a closer look at how to handle presets in AU, and it seems that there, it is the only viable way. So it looks like I am going to try to implement that in the next days. It requires quite some changes to the framework I am using, but is definitely doable.

As far as I can see, it also should not be a big problem to implement a Keeper/Restorer switch, based on which changes are either stored immediately, or only after writing them explicitly.

Cheers,
Martin

Post

Hi Martin. Recently I discovered PG8X. I like the sound very much, although cannot compare it with JX8P - because I've never played JX8P.

It would be great to see new GUI. I don't like current GUI at all and I belive that many users share my view. I mean.. the quality of images and text is poor... especially if you compare it to this:

http://www.rockendorf.de/image/ScreenshotEditor.jpg
http://apps4idevices.com/data/o0/images ... 02-001.jpg
http://kentai.ch/wp-content/uploads/201 ... G_0044.png

(I love the latter)

Best
--Karol

Post

karol wrote:Hi Martin. Recently I discovered PG8X. I like the sound very much, although cannot compare it with JX8P - because I've never played JX8P.

It would be great to see new GUI. I don't like current GUI at all and I belive that many users share my view. I mean.. the quality of images and text is poor... especially if you compare it to this:

http://www.rockendorf.de/image/ScreenshotEditor.jpg
http://apps4idevices.com/data/o0/images ... 02-001.jpg
http://kentai.ch/wp-content/uploads/201 ... G_0044.png

(I love the latter)

Best
--Karol
Hello Karol

Probably that the GUI will be improved when Martin has totally resolved the most important aspect of the synth... its work. And perhaps with the help of kind guys who here at KVR are specialists of wonderful GUIs (I think to Layzer and some others) and who are often actually nice to make it.
Build your life everyday as if you would live for a thousand years. Marvel at the Life everyday as if you would die tomorrow.
I'm now severely diseased since September 2018.

Post

martin_l wrote:As Admiral Quality indicated, there are inconsistencies of this approach with the "VST" bank approach. I noticed that myself and agree with his conclusions on this point.
As long as we get to import JX-8P .syx and drag and drop to 127 .fxp slots we should be on safe ground.

Extra things like polyphony, oversampling and other parameters that don't exist on the JX-8P keyboard can probably stay global for now.
Intel Core2 Quad CPU + 4 GIG RAM

Post

Off topic- but speaking of Layzer - I am still hoping for an OBX-a skin for the amazing OBXD :pray: :wink:

On topic - I do look forward to the non beta release of this amazing VST sounds very good and a joy to use. :tu:

Locked

Return to “Instruments”