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

[martin_l]

This is simply not true. There are examples of VST's (Arturia, Tyrell, Synth1, SQ8L), which do need a 'commit' in order to write changes to the bank. They, however, do not indicate whether a patch is "dirty".

Using a different symbol in my readout (other than colours) is a good idea, and I will implement something along those lines.

Cheers,
Martin

The default, built-in bank, sure. But Martin has already stated that he doesn't know where to save data to make a writeable version of the built-in bank, so I'm assuming that's not what his Write function is for.

But any of these examples will absolutely behave like I described. Edit a patch in program position 2. Don't do anything (like Write it) and switch to program position 1. Edit that patch. Now save your project. Close your host (or project). Reload the project. BOTH programs 1 and 2 will be the ones you edited, and it will come up with program 1 currently selected.

Now load a fresh instance of the plug-in. Now programs 1 and 2 will be whatever is in the built-in "preset" bank.

Simply not true. Just try TyrellN6 in Reaper. You need to save your patch to be remembered. If you just change a parameter on the GUI, change the programme and then go back to the old programme, the changes are lost. And also when you save the project and load it again, they are lost, if you changed the programme inbetween.

The current patch is saved with the project, but as soon as you change the programme and go back, it reverts to whatever is in the bank, which is used in the project. The same happens with Arturia products.

[AdmiralQuality]

This is simply not true. There are examples of VST's (Arturia, Tyrell, Synth1, SQ8L), which do need a 'commit' in order to write changes to the bank. They, however, do not indicate whether a patch is "dirty".

Using a different symbol in my readout (other than colours) is a good idea, and I will implement something along those lines.

Cheers,
Martin

The default, built-in bank, sure. But Martin has already stated that he doesn't know where to save data to make a writeable version of the built-in bank, so I'm assuming that's not what his Write function is for.

But any of these examples will absolutely behave like I described. Edit a patch in program position 2. Don't do anything (like Write it) and switch to program position 1. Edit that patch. Now save your project. Close your host (or project). Reload the project. BOTH programs 1 and 2 will be the ones you edited, and it will come up with program 1 currently selected.

Now load a fresh instance of the plug-in. Now programs 1 and 2 will be whatever is in the built-in "preset" bank.

Simply not true. Just try TyrellN6 in Reaper. You need to save your patch to be remembered. If you just change a parameter on the GUI, change the programme and then go back to the old programme, the changes are lost. And also when you save the project and load it again, they are lost, if you changed the programme inbetween.

The current patch is saved with the project, but as soon as you change the programme and go back, it reverts to whatever is in the bank, which is used in the project. The same happens with Arturia products.

It may well do that, but it's non-standard behavior and is wrong. You're supposed to be able to trust the host's save function to get you back to the exact, complete state you're at at any time.

[AdmiralQuality]

Ah, just tried Tyrell. Here's a thing. Tyrell only has a single program "slot". (It's numPrograms parameter at instantiation-time is 1.) The rest of the "bank" is imaginary, entirely outside the VST system, and can do whatever it wants.

The host, not seeing any of this bank, cannot select a program from the bank. So the host doesn't have the ability to change programs within this bank that it cannot "see".

However, if I edit that single program, and save my project state, it comes back with that edit intact, NOT as the content of what's in the bank. (Which again, is not a VST bank. And therefore is not accessible to the host's .fxb saving function, as the host thinks the bank is only one program in size.)

And I just verified... PG8X has many programs in its VST bank.

There's your disconnect. Either stick with the VST system, or do it like Tyrell and make the host entirely unaware there's a bank at all.

[martin_l]

That is the least of the problems. I merely think it's confusing for users, particularly on the Mac side. (As is using the file extension to determine what function the Open/Save dialog is about to perform. Mac users aren't even seeing anything other than the first extension in your list -- which is a bug I have with Poly-Ana as well, I'll let you know if I figure out what I'm doing wrong there.)

I already said that the next version will have a popup menu to select what to save, so the necessity of seeing the file extension will be gone.

If you are making a plug-in that violates the plug-in spec then prepare for a LOT of never ending complaints. These aren't your (or my) decisions to make.

I don't see how I am violating the specs more than the other plugins I mentioned. And I don't think the comments in the VST2.4 SDK are so clear as to dictate what a plugin can or must not do.

What do you mean .fxb banks? A bank is a bank. .fxb is merely the format VST hosts use to save banks on the plug-ins' behalf.

No, in real life a bank is not a bank. Look at those plugins which do implement their own preset system.
At least in Reaper, I see a bank (i.e. list of presets) in the host, which I can fill by saving presets through the host's menu, and I see a different list of presets in the plugin through their own preset management system.
Again, look at Arturia, Tyrell, etc. as examples.

And what do you mean about "function calls which tell the host about the banks used by the plugin"? There is only the numPrograms and numParams parameters to AudioEffect() when the plug-in is instantiated. There is no number of banks in a VST, it's always 1.

OK, here I am on a different level, as I am using the wdl/iplug framework, which does provide these functions, which then are mapped onto the corresponding VST2/3 or AU functions.

The host has no bank. A plug-ins state is stored in the plug-ins data area, not in the host. (This is why you need to allocate space for it.) When the host wants it, it gets it through getChunk() or successive getParameter() calls, depending on whether your plug-in is chunk or parameter based (determined by calling programsAreChunks() in your effect constructor).

Yes, but when the host saves a project, it will ask the plugins for their states (with the flags for preset/bank) and saves these chunks of data somewhere in the project. And when the host opens a project, it loads the plugins and then restores the state and the bank.

Yes, you're attempting to mash two conflicting paradigms together. Sorry, but again, VST plug-ins (nor AU plug-ins) don't do that.

Again, many plugins do that, only that they use a system which is separate from both VST and AU standard.
If this is the preferred way, I can also separate my preset system from the host and the VST/AU standards.
I just don't see any real advantage in that.

Have you tried actually using your plug-in across several projects, as a typical users would? You'll run into the problems soon enough.

What exactly is going wrong? This is surely a bug which I would like to fix, as it obviously should be working between different projects.

Sorry, but this just isn't something you're allowed to do. (Sure you can do it, but it will be considered "broken" by users who know what to expect.)

So, would you consider Tyrell and friends as "broken plugins"?


Cheers,
Martin

[AdmiralQuality]

And here's just one of the bad behaviors Tyrells system makes, that doesn't happen in complaint VST plug-ins.

So I edited a patch (# 7, HS Chordula) and saved my project. Closed Reaper, reopened it, and reloaded the project. No problem, my edits were still there.

UNTIL... I switched to another program. Then when I switched back to my edited patch, it was gone, replaced by the preset.

That's not supposed to be how it works.

The reasoning (in my eyes) is this. There's zero danger of losing a preset patch, because every new instance of the plug-in will come up with the original presets intact. So it's far more valuable to protect an edit, than the original data. Say I wanted to switch between two sounds in my song. I spend an hour making the perfect patch, then switch to the next one to work on it. When I go back to the first one I edited, my edits are gone. This is not the behavior users of VST and AU plug-ins have been trained to expect. (And again, you've added a step to the users' workflow that never used to be required.)

So, sorry, but Tyrell is a really bad example.

[AdmiralQuality]

That is the least of the problems. I merely think it's confusing for users, particularly on the Mac side. (As is using the file extension to determine what function the Open/Save dialog is about to perform. Mac users aren't even seeing anything other than the first extension in your list -- which is a bug I have with Poly-Ana as well, I'll let you know if I figure out what I'm doing wrong there.)

I already said that the next version will have a popup menu to select what to save, so the necessity of seeing the file extension will be gone.

You accused me of thinking something. I was merely making it clear how I actually felt. Sorry to have to repeat myself, but you were putting words in my mouth.

If you are making a plug-in that violates the plug-in spec then prepare for a LOT of never ending complaints. These aren't your (or my) decisions to make.

I don't see how I am violating the specs more than the other plugins I mentioned. And I don't think the comments in the VST2.4 SDK are so clear as to dictate what a plugin can or must not do.

Fine. There's a limit to how much free consultancy I'm willing to do here. Be as stubborn as you want about it. But you heard it here first. You're doing it wrong.

What do you mean .fxb banks? A bank is a bank. .fxb is merely the format VST hosts use to save banks on the plug-ins' behalf.

No, in real life a bank is not a bank. Look at those plugins which do implement their own preset system.
At least in Reaper, I see a bank (i.e. list of presets) in the host, which I can fill by saving presets through the host's menu, and I see a different list of presets in the plugin through their own preset management system.
Again, look at Arturia, Tyrell, etc. as examples.

You don't see a bank in Tyrell in Reaper (or any other host). LOOK!

And what do you mean about "function calls which tell the host about the banks used by the plugin"? There is only the numPrograms and numParams parameters to AudioEffect() when the plug-in is instantiated. There is no number of banks in a VST, it's always 1.

OK, here I am on a different level, as I am using the wdl/iplug framework, which does provide these functions, which then are mapped onto the corresponding VST2/3 or AU functions.

The host has no bank. A plug-ins state is stored in the plug-ins data area, not in the host. (This is why you need to allocate space for it.) When the host wants it, it gets it through getChunk() or successive getParameter() calls, depending on whether your plug-in is chunk or parameter based (determined by calling programsAreChunks() in your effect constructor).

Yes, but when the host saves a project, it will ask the plugins for their states (with the flags for preset/bank) and saves these chunks of data somewhere in the project. And when the host opens a project, it loads the plugins and then restores the state and the bank.

Tyrell's bank is invisible to the host. The host cannot restore it because it doesn't know it's there. It only restores the current program (which has also bypassed the VST system concept of current program, which of course always has to be 1, the bank being only one program element in size).

Yes, you're attempting to mash two conflicting paradigms together. Sorry, but again, VST plug-ins (nor AU plug-ins) don't do that.

Again, many plugins do that, only that they use a system which is separate from both VST and AU standard.
If this is the preferred way, I can also separate my preset system from the host and the VST/AU standards.
I just don't see any real advantage in that.

Not pissing off users who expect the normal behavior would be advantage #1 here.

Have you tried actually using your plug-in across several projects, as a typical users would? You'll run into the problems soon enough.

What exactly is going wrong? This is surely a bug which I would like to fix, as it obviously should be working between different projects.

You keep avoiding my question. Do you actually *use* this stuff?

Sorry, but this just isn't something you're allowed to do. (Sure you can do it, but it will be considered "broken" by users who know what to expect.)

So, would you consider Tyrell and friends as "broken plugins"?

Absolutely! See my posts above.

[Z3R0T0N1N]

just a differing perspective here:
If I open a project w/ a VSTi in it, on which I have edited and used an existing patch that resides in a bank (be it .FXB or some other proprietary type), and I then 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. The only time I have ever seen my changes preserved is if I have saved the patch or the bank separately from the project first, before I saved the project. This is the behaviour I expect in every host I have used for any length of time - Orion, FL studio, Cubase, Reaper, Podium, Energy XT... and with every VSTi I can think of.
In fact, if it wasn't the case, I would wonder what would become of the original bank if I then tried to use it in another project or host? Every project would have to make a new instance of the bank, or in the case of multi-bank browsing systems (XILS or Arturia for example) all the banks. And then if I wanted two instances of the synth, then the host would have to make another instance of the same original bank...
Anyway, I'm not a systems programmer, I'm a lowly web developer, so I'm sure there would be technical ways around this stuff that smart people would be able to figure out (read "you guys") but honestly if I was going to be confused by patch/bank behaviour, it would definitely be this scenario...

[AdmiralQuality]

just a differing perspective here:
If I open a project w/ a VSTi in it, on which I have edited and used an existing patch that resides in a bank (be it .FXB or some other proprietary type), and I then 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. The only time I have ever seen my changes preserved is if I have saved the patch or the bank separately from the project first, before I saved the project. This is the behaviour I expect in every host I have used for any length of time - Orion, FL studio, Cubase, Reaper, Podium, Energy XT... and with every VSTi I can think of.
In fact, if it wasn't the case, I would wonder what would become of the original bank if I then tried to use it in another project or host? Every project would have to make a new instance of the bank, or in the case of multi-bank browsing systems (XILS or Arturia for example) all the banks. And then if I wanted two instances of the synth, then the host would have to make another instance of the same original bank...
Anyway, I'm not a systems programmer, I'm a lowly web developer, so I'm sure there would be technical ways around this stuff that smart people would be able to figure out (read "you guys") but honestly if I was going to be confused by patch/bank behaviour, it would definitely be this scenario...

You're confused. Trust me, I'm describing the way it normally works. The way Steinberg's own SDK examples work.

What would happen in your example is the "original" bank (preset is a better word here than original) stays the same as it always was in successive instances of the plug-in.

Again, there's not supposed to be a "save" step required in the plug-in to get your edits to persist. They are supposed to persist, always. (And if you want the original bank back, just delete the plug-in and re-instantiate it. Presto, the default, hard-wired presets are back.)

And again, yes, it does make sense to be able to overwrite these (usually) hard-wired presets. So that new instances will come up with what you want in them by default, rather than what the developer hard-coded into them. THAT is the reason for having a save function in the plug-in itself. But that doesn't affect the state of the current project. It affects the state future instances of the plug-in will launch into.

A plug-in is not supposed to lose the state of one program just because you switched to another (and failed to perform some proprietary, non-standard step, before doing so). Any plug-in that does is forcing a workflow on the user that's easy to forget, and that potentially can lose a lot of work. Again, the built-in programs aren't precious because all you need to do to get them back is launch a fresh instance. The edits you're currently doing ARE precious though. That would be my assumption of why both AU and VST hosts work that way. (It's different in hardware, which is where this "commit changes" paradigm comes from, because there is only that one, single instance of the program and bank memory. It's not reestablished from disk every time you wish a new synth into existence as you can't do that in reality like you can with plug-ins.)

Ask Urs. He'll verify what I'm saying. Or any other experienced developer here. (I wouldn't have thought this to be a controversial topic. But I can see how, if you used Tyrell as a model, you might get confused as to the normal state of things.)

Just look at the original, SynthEdit based PG8X. It did it the normal way (I think anyway, it's been a while since I used it). Edits persist in the project. You don't have to do anything to save them (other than save the host project, of course).

[ENV1]

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.

[AdmiralQuality]

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?

[ENV1]

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

There is no right or wrong in this matter, only preference. I myself for example definitely prefer restorers over keepers because when i work on a preset and lose my way i can go back to whatever i started from by simply pressing forward and back. With a keeper i would either have to load a preset or a bank or even shut down the whole plugin and restart it, and in my opinion thats just way more effort than necessary. Other people of course prefer the exact opposite, i.e. that their edits be kept no matter what. Either preference is understandable, thus neither is wrong or right.

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?

No, the KORGs expose presets dynamically to the host. (Except for the MS-20 and Polysix, which only support banks of 32.) Mono/Poly for instance has 127 presets per bank and 4 banks. So when you select Bank A via the UI the host will list the 127 presets of Bank A. When you select any preset of Bank B the host will display the contents of Bank B, and so forth. The M1 only exposes 99 presets at a time but it works in the same dynamic manner. The WAVESTATION exposes 50 presets to the host, likewise depending on what RAM/ROM/CARD you select on the UI.

[AdmiralQuality]

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

There is no right or wrong in this matter, only preference. I myself for example definitely prefer restorers over keepers because when i work on a preset and lose my way i can go back to whatever i started from by simply pressing forward and back. With a keeper i would either have to load a preset or a bank or even shut down the whole plugin and restart it, and in my opinion thats just way more effort than necessary. Other people of course prefer the exact opposite, i.e. that their edits be kept no matter what. Either preference is understandable, thus neither is wrong or right.

Forward and back?

In my workflow, it's project snapshots every few minutes (with serialized filenames so I never stomp on old data).

What would you do if you were working with 10 instances of the same plug-in in a project? (Not an outrageous example at all.) And sorry, but I don't see (in the occasional, relatively rare emergency) deleting a plugin and reinstatiating it as a huge pain in the ass. 5 to 10 seconds.

I want each instance of a plug-in to have its own, unique state, that doesn't go stomping on other instances. (We haven't even touched on how that behavior should work. If I Write to a program slot in one plug-in, should all the other instances of it instantly change their state as well? Doesn't that greatly limit me? Now I have to manage the bank contents across all instances of the plug-in, in ALL PROJECTS I will EVER work on, on that machine. No?)

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?

No, the KORGs expose presets dynamically to the host. (Except for the MS-20 and Polysix, which only support banks of 32.) Mono/Poly for instance has 127 presets per bank and 4 banks. So when you select Bank A via the UI the host will list the 127 presets of Bank A. When you select any preset of Bank B the host will display the contents of Bank B, and so forth. The M1 only exposes 99 presets at a time but it works in the same dynamic manner. The WAVESTATION exposes 50 presets to the host, likewise depending on what RAM/ROM/CARD you select on the UI.

I don't know what you mean by dynamically. The answer I'm looking for is a number. Either one, or many. I guess it's many. (The switching banks thing is neither here nor there. You call updateDisplay() and the host re-asks the plug-in for all the program names so it can display them correctly.)

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?

And if I move a project to another machine that doesn't have that same plug-in data folder (wherever it is) where the plug-in keeps its bank data, what will I hear? The project HAS to contain the state of ALL programs in the plug-ins, not just the current ones, as it's entirely possible to use more than one program across a project in a single instance of the plug-in. (By the host calling setProgram() on the plug-in, which most hosts can automate.) (EDIT, before someone corrects me: With one common exception, samplers. Which have data so large it's not practical to store it in the project. Nor is it practical to switch sampler programs in mid-song, due to the typically long load times. But those at least prompt you to find the patch-file/folder if it's not found in the location that was stored with the project.)

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?

And don't just think about synthesizers. Consider effects as well. (They're virtually the same except for an arbitrary flag describing whether they were intended as an generator/instrument or processor/effect.)

[AdmiralQuality]

The Korg plug-ins don't seem to have demos of any kind? Who even buys this stuff without being able to try it first? Craziness...

[EvilDragon]

Regarding Korg's plugins, if you don't save a patch on which you did some edits, the plugin data chunk WILL get saved within the DAW project file (if you save the project, of course). So the project will load with that particular edit of the sound intact.

[AdmiralQuality]

Regarding Korg's plugins, if you don't save a patch on which you did some edits, the plugin data chunk WILL get saved within the DAW project file (if you save the project, of course). So the project will load with that particular edit of the sound intact.

Good.

But if I happen to switch to another program, then go back to the one originally selected in the project, it will now be stomped on by the contents of the preset bank? And I'm never more than one wrong click away from completely losing an edit at any time?