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

[EvilDragon]

Yes, it will, but that's why there are Undo functions in DAWs.

[ENV1]

Its moot to go on about the preference thing so lets talk about the preset system instead.

I don't know what you mean by dynamically. The answer I'm looking for is a number. Either one, or many.

Dynamically means dynamically, as in changing on the fly depending on what Bank/RAM/ROM/CARD you select on the synths UI. Exactly as i described. The number is always the same but the presets are not.

So, say I make a change to a plug-in program, it sounds good, I save the project (or my host auto-saves at that point), and the power goes off or the machine crashes before I can "Write" it (whatever that means). What will I hear when I reload the project later on? My edited program? Or whatever was last written to (who knows) where that particular plug-in stores its bank data?

OK, one thing at a time. To 'Write' the preset means that you are committing it to WorkRAM. Once you have done that your preset is safe for the session, i.e. you can switch to another preset and back without losing your edits. On the hardware this would mean that you have committed the preset to NVRAM, which means you can turn off the machine without destroying your edits. On a computer this is of course not the case since the emulations NVRAM is only virtual, i.e. merely existing in your computers RAM. That is why the emulation requires you to additionally save the machines memory to disk in order to be able to recall everything after a shutdown/restart.

As for the other question, when you save the project the edits of the active preset will be saved whether you wrote it to WorkRAM or not. The host will also always save the entire bank, so any other presets that you did write will be properly restored as well. Since all of the data is stored in the project file it doesnt matter which computer you are opening it on. Your presets will all be there.

I am really having difficulty believing that their products behave as you describe. Do they have a free demo I can try? Is there one particular product I should demo to test this or do all the Korg plug-ins do it?

Believe it or not, it is how it is.

If you want demos you have to sign up with KORG. Unless theyve changed it you cant get them without an account.

I would start with the Mono/Poly.

[AdmiralQuality]

Its moot to go on about the preference thing so lets talk about the preset system instead.

I don't know what you mean by dynamically. The answer I'm looking for is a number. Either one, or many.

Dynamically means dynamically, as in changing on the fly depending on what Bank/RAM/ROM/CARD you select on the synths UI. Exactly as i described. The number is always the same but the presets are not.

That's outside the system we're talking about. There's nothing non-compliant with the VST spec about doing that. (As long as you call updateDisplay() so the host can update its program list for the bank.)

So, say I make a change to a plug-in program, it sounds good, I save the project (or my host auto-saves at that point), and the power goes off or the machine crashes before I can "Write" it (whatever that means). What will I hear when I reload the project later on? My edited program? Or whatever was last written to (who knows) where that particular plug-in stores its bank data?

OK, one thing at a time. To 'Write' the preset means that you are committing it to WorkRAM.

WorkRAM? That's some imaginary term that has nothing to do with VST or even computer science.

Once you have done that your preset is safe for the session,

Right there is where I get off this ride. "Oh, MAY I use this program setting in this session, oh bitchy, attention demanding plug-in?"

i.e. you can switch to another preset and back without losing your edits.

"Oh, may I?"

On the hardware this would mean that you have committed the preset to NVRAM, which means you can turn off the machine without destroying your edits. On a computer this is of course not the case since the emulations NVRAM is only virtual, i.e. merely existing in your computers RAM. That is why the emulation requires you to additionally save the machines memory to disk in order to be able to recall everything after a shutdown/restart.

There IS NO HARDWARE. What's next, modelling the power supply? It's entirely unhelpful within the VST/AU/DAW paradigm.

As for the other question, when you save the project the edits of the active preset will be saved whether you wrote it to WorkRAM or not. The host will also always save the entire bank, so any other presets that you did write will be properly restored as well. Since all of the data is stored in the project file it doesnt matter which computer you are opening it on. Your presets will all be there.

I am really having difficulty believing that their products behave as you describe. Do they have a free demo I can try? Is there one particular product I should demo to test this or do all the Korg plug-ins do it?

Believe it or not, it is how it is.

If you want demos you have to sign up with KORG. Unless theyve changed it you cant get them without an account.

I would start with the Mono/Poly.

Wish I could but I can't see anything offering me demos. (If it's behind the sign-up please let me know, but I don't see anything indicating I should expect demo downloads if I sign up. So I'd rather not bother.)

Any other free or demoable plug-ins that behave this way I can look at? I already revealed that Tyrell isn't behaving the way Martin was assuming it was. (It's bank is only one program in size. Which means the host can't switch to another program. And when the plug-in switches internally, that's just changing the settings of that single program from a bank that's completely opaque and inaccessible from the host.)

[EvilDragon]

The free Synth1 behaves just like Korg plugins (IF you go to Opt and check the "Select program from host" checkbox).

[AdmiralQuality]

The free Synth1 behaves just like Korg plugins (IF you go to Opt and check the "Select program from host" checkbox).

Ugh. I tried it once a long time ago and found it lacking in a number of ways. (Maybe that behavior was even one of them, all I remember was my takeaway impression of it.)

Really? That's it?

[EvilDragon]

LinPlug Albino 3 and Spectral work the same way. Probably all of their plugins as well.

[AdmiralQuality]

So yes, Synth 1 has this problem too. (I do not see this as a feature. It's just wrong.)

And when I write a new program name, the host's display doesn't update, only the name displayed in the plug-in. (Because they're obviously not calling updateDisplay()). Even if I increment to the next patch, then decrement back down, the host never sees the new program name. (It did finally show after saving and reloading the project.)

Ah! Even worse! (Exactly as I predicted, too.) I instantiated two instances of Synth1. Both were on patch 1. On the second instance, I edited the patch, and wrote it with a new name to the non-volatile bank. Played them, and instance 1 sounded different than my edited instance 2. THEN... I saved and reloaded that project, and guess what? Now both instances both play and display the same sound as was in my original 2nd edit. I lost the settings that were part of the project I saved. This is just one of many what-if scenarios I can come up with that makes this whole thing strike me as a really bad idea.

Wouldn't it just make a lot more sense to let the patch be volatile, the way VST intended, and provide a function button to RESTORE the patch to the preset bank? Same amount of work (for both the developer and the user) except without the possibility of accidentally losing a patch by forgetting that this plugin has a different workflow than most others. That's what I would do. (In fact, it's a feature I've been planning to add.)

But to model this unfortunate and limiting aspect of hardware synths, I don't see as helpful at all. Again, there is no need to protect the program memory positions in the project, as they don't stomp on the plug-in binary, which will always instantiate the same (or in the case of plug-ins that let you redefine the preset bank(s), as you defined them). You will never permanently lose a default patch through editing. However you will often lose editing, through accidentally changing to another patch (and who knows what other situations, like the one I encountered above).

[BlackWinny]

just a differing perspective here:
If I use the patch browser to switch to the next or previous patch in the bank, I fully expect that if I change back, I will lose the changes which were saved in the project. I have never seen any different.

Both types exist.

SynthEdit plugins for example are 'keepers', i.e. you can edit a preset, switch to another, then back, and your edits will still be there.

KORG plugins on the other hand are 'restorers', i.e. they restore the original preset when you switch to another preset and back.

There are many more examples for both types.


Martin apparently wants to make it similar to how the KORGs work, i.e. you make your edits, write them to WorkRAM, then you save the bank to disk to make the changes permanent/recallable. Conceptually thats pretty much the same system that you find in the hardware world.

Then Korg plug-ins are wrong. (Or again, are trying to model behaviors of the original instruments that just have no place in the DAW paradigm.)

Do you happen to know how many programs the host sees in the bank for the Korg plug-ins? Is it just one like with Tyrell?

Yes sir.

Urs Heckman, father of Zebra, Diva, TyrellN6, and all those number one products... is wrong.

Even Korg itself is wrong.

And you, sir (sorry, Sir), you... you are right.

U-He and Korg have understood anything of how to program synths and you, Professor, have lessons to give to Urs Heckman, Korg, Ichiro Toda, LinPlug, etc.

[layzer]

this is really more complicated than it has to be:

from the host:
open/save fxp and fxb

from the plugin:
save/load .pgp .pgb .syx

do away with the "write" function all together.... instead, make it so when
you open/load a preset it replaces the one in the current preset slot of the current bank.

edits to the patch or bank are temporary until you save them

K.I.S.S

[ENV1]

That's outside the system we're talking about.

Then why did you ask?

WorkRAM? That's some imaginary term that has nothing to do with VST or even computer science.

So? Its a term i use because the machines virtual NVRAM is obviously not really non-volatile. If you prefer to use a different term, be my guest.


Out now because the discussion is beginning to get a little too futile for my taste.

[Spitfire31]

…To 'Write' the preset means that you are committing it to WorkRAM. Once you have done that your preset is safe for the session, i.e. you can switch to another preset and back without losing your edits. On the hardware this would mean that you have committed the preset to NVRAM, which means you can turn off the machine without destroying your edits. On a computer this is of course not the case since the emulations NVRAM is only virtual, i.e. merely existing in your computers RAM. That is why the emulation requires you to additionally save the machines memory to disk in order to be able to recall everything after a shutdown/restart.

But this is daft. Why would I feel good about a convoluted storing process that's only required for ancient hardware?

I'm on last year's computer and I'd like an emulation to reflect that kind of environment. I don't feel a need for jumping through emulated hoops because of non-existant hardware limitations.

A more immediate concern, though: has any Mac user succeded in loading the sysex files from Martin's Dropbox?

Unfortunately, I can't find the time to be a from-scratch programmer – at the most I'm a tweaker. I'd really appreciate a smattering of sounds to evaluate the playability of PG8X…

Kind regards,

Joachim

[ENV1]

But this is daft. Why would I feel good about a convoluted storing process that's only required for ancient hardware?

You always have to save to disk. With every plugin that has ever been made. And its not surprising either, after all how else if not through saving to disk was the data gonna be retained? The alternative was to lose everything as soon as you shut down the plugin.


No, KORGs way of preset handling has much worse things to worry about than the fact that you have to use a write button and then save to disk. I have written a lengthy post about its pitfalls some time ago here. Its specifically about the M1 but of course it applies to the others too. Bring a snack and soda.

[Spitfire31]

But this is daft. Why would I feel good about a convoluted storing process that's only required for ancient hardware?

You always have to save to disk. With every plugin that has ever been made.

Granted. But with most plugins, I don't have to remember to perform two separate saving actions, do I? First, Write (two clicks) and then Save as.

Or did I misunderstand something?

/Joachim

[ENV1]

But this is daft. Why would I feel good about a convoluted storing process that's only required for ancient hardware?

You always have to save to disk. With every plugin that has ever been made.

Granted. But with most plugins, I don't have to remember to perform two separate saving actions, do I? First, Write (two clicks) and then Save as.

Or did I misunderstand something?

/Joachim

No thats pretty much correct.

The most common/widespread method is to simply save, either via the plugins built in preset manager or the hosts preset manager.

KORG differs mainly because its emulation of hardware, in the case of M1 and WS even emulation of entire operating systems.

[electro]

You might want to take a cue from the PPG 3.V browser. Its folder tree based and can see everything for import .syx, .fxp, .wav etc.