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

AdmiralQuality wrote: Well then you're reinventing the wheel. What is a file load dialog if not a browser of the file system?

If you want to organize your patches, you can do it in folders and files on your storage volumes.
OK, if it's a system call function, and that easy to implement, great. I wonder why there are not more plug-ins implementing this - I see a lot that lack those simple functions of "Save", "Save As" and "Load" (and navigation arrows that call the next or previous patch would be helpful too).
Fernando (FMR)

Post

AdmiralQuality wrote:
BlackWinny wrote: Even the sorting by folders in not enough when we have to manage hundreds or thousands patches which are all accessible simultaneously.
21st century problems... ;)
Yes.

That's why as long as there is no better way I prefer to use banks (and that doesn't prevent me to use also independent patches).

Not necessarily purchased banks, but above all my banks, that I create by gathering patches in function of how I feel their possible use... and even simply in order to create a bank for a song where I use five or six or ten patches of the same synth. If I want later to re-work this song, I have just to load the bank I've created when using the synth for that composition.

There are many applications to the banks as long as there are no other ways to manage directly the qualification (and the affectation also) of the patches that we have... or that we create for our own style or for one particular song.

In my humble opinion the system of tags is the most flexible to make all what we could imagine in the use of patches. And it would be probably quite easy to implement with the internal functions of every compiler to manage little and simple database formats as DBF of even CSV (which in addition are full compatible for OSX as well as for Windows).
Last edited by BlackWinny on Mon May 26, 2014 6:00 pm, edited 2 times in total.
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

fmr wrote:
AdmiralQuality wrote: Well then you're reinventing the wheel. What is a file load dialog if not a browser of the file system?

If you want to organize your patches, you can do it in folders and files on your storage volumes.
OK, if it's a system call function, and that easy to implement, great. I wonder why there are not more plug-ins implementing this - I see a lot that lack those simple functions of "Save", "Save As" and "Load".
Well, again, that wasn't a function VSTs were expected to provide. It was the hosts' job to save programs and banks, as well as the current state of all programs in every plugin in the project, along with the project.

And as PAK pointed out above, it's only because of Steinberg's intentional omission of this feature in their post-VST3 hosts that it's even needed. (And yes, it's needed for cross compatibility between AU and VST versions of the same plug-in as well. But I imagine many of the plug-ins you're thinking of that don't have their own program/bank save and load features don't come in both varieties anyway.)

Any fully functional VST 2.4 host (i.e. all the rest of them other than Steinberg's intentionally obsolteted ones) provides this functionality already. And even better, many allow you to save entire chains of plug-ins as track templates. That's actually how I'm far more likely to save a "patch" (as I don't consider a patch to be the settings of just one single plugin, rather the settings of every other plugin it interacts with as well).

And really, does anybody need ten thousand JX-8P sounds? A mildly experienced synthesist should be able to come up with any sound they want far quicker than perusing a massive patch library will find them what they're looking for. If this was reality, you'd have a stack of RAM cartridges next to your JX-8P the size of a bus!

Post

BlackWinny wrote: In my humble opinion the system of tags is the most flexible to make all what we could imagine in the use of patches. And it would be probably quite easy to implement with the internal functions of every compiler to manage little and simple database formats as DBF of even CSV (which in addition are full compatible for OSX as well as for Windows).
Please keep in mind, that unless you are an experienced software developer, your opinion is very humble.

Tags are the answer? So what happens if I label a bass sound #juicy and you search for #wet?

And as for common database formats, that doesn't mean there are common database SCHEMA. It's all entirely arbitrary, up to the developers themselves to implement, if at all. (I'm a big fan of simplicity. Again, if I want to search massive amounts of patches I'll use long filenames to "tag" them and file search ability to pick out the ones I want.)

Now, drag and drop of plug-in program settings would be nice. Both between plug-in instances, and to and from the file Exlporer/Finder/Whatever. However that's one of the areas where functionality isn't guaranteed. (Hosts can intercept the drop before your plug-in ever gets to see it.) So, as functionality that's not guaranteed to work across all hosts, it's dangerous ground to tread. You'll just end up pissing users off who have hosts that don't support it. (Speaking of which, try typing program names with spaces into a plug-in in Reaper and watching the transport start and stop. Not to mention trying to use the clipboard hotkeys. I love Reaper, but that behavior infuriates me!)

Post

AdmiralQuality wrote:
BlackWinny wrote: In my humble opinion the system of tags is the most flexible to make all what we could imagine in the use of patches. And it would be probably quite easy to implement with the internal functions of every compiler to manage little and simple database formats as DBF of even CSV (which in addition are full compatible for OSX as well as for Windows).
Please keep in mind, that unless you are an experienced software developer, your opinion is very humble.

Tags are the answer? So what happens if I label a bass sound #juicy and you search for #wet?

And as for common database formats, that doesn't mean there are common database SCHEMA. It's all entirely arbitrary, up to the developers themselves to implement, if at all. (I'm a big fan of simplicity. Again, if I want to search massive amounts of patches I'll use long filenames to "tag" them and file search ability to pick out the ones I want.)

Now, drag and drop of plug-in program settings would be nice. Both between plug-in instances, and to and from the file Exlporer/Finder/Whatever. However that's one of the areas where functionality isn't guaranteed. (Hosts can intercept the drop before your plug-in ever gets to see it.) So, as functionality that's not guaranteed to work across all hosts, it's dangerous ground to tread. You'll just end up pissing users off who have hosts that don't support it. (Speaking of which, try typing program names with spaces into a plug-in in Reaper and watching the transport start and stop. Not to mention trying to use the clipboard hotkeys. I love Reaper, but that behavior infuriates me!)
Woaw! What temperedness...
Image
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

After the discussion here on the sense or nonsense of plugin-internal LOAD's and SAVE's, and the confusion about what PG8X does (or should be doing), I thought I better give a short overview of what I intended to do and how the PG8X is supposed to work:

The PG8X has one active patch plus a bank of 128 patches. The active patch is associated with a programme number, which indicates which programme was loaded into the active patch.

To load a new patch from the current bank, you can either use the host's ways of choosing a patch, or clicking on the programme number, which will then display a popup menu. Both ways should be equivalent. (Some hosts, e.g. reaper, allow to have patches 'outside' the bank, which will not be visible through he plugin's menu).

When you change a parameter, it will affect the active patch, but not any of the patches in the bank. The fact that a patch has changed from the originally loaded programme is indicated by the programme number turning yellow.

In order to write the changes to the bank you need to use the WRITE button. Left-clicking the WRITE Button will turn the Programme number red, which indicates that you can select the target programme by clicking on the programme number. Once a number is selected, that patch is written to that programme. Right-clicking saves the patch into the current position in the bank.

The same can also be achieved with the host's menu and should have the same effect. I added this, as I got several comments about me old plugin requesting this functionality as apparently some hosts did not offer that (don't know which they were...)


LOAD and SAVE buttons:

The LOAD button allows to read files of various types: fxb/fxp and sysex. In the VST version, the reading of fxb/fxp should be identical to reading the file through the host's menu (in fact, the same function is called internally). In the AU version (and upcoming standalone) versions, it allows to import fxb/fxp files, which otherwise might not be supported by the host.

Currently supported SysEx files are single JX8P patches (which simply are loaded into the active patch, WITHOUT being saved to any programme in the bank -- sorry, strange JX8P sysex implementation...), or a JX8P bank, which contains a sequence of patches, followed by an instruction to write the patch into the bank.

JX10/MKS70 Sysex files are not yet supported, but I am planning to support them as well (at least the TONE component of them).

The SAVE button currently supports writing fxb and fxp files. Currently this is decided based on the chosen file extension. In the next version there will be a popup menu for choosing the format). For fxb and fxp, this will, again, be identical to the host's function (again, same function call), and is basically only present to provide fxb/fxp support in hosts (Steinberg) which do not support it, or in the AU version.

A note on loading several SysEx banks into one bank: JX8P SysEx banks usually only contain 32 programmes, which will be loaded into the programmes 1-32. The programme popup menu also has the item "Rotate Banks", which will copy those to 33-64, 33-64 to 65-96, and so on. Doing this after importing a SysEx bank, will free up the slots 1-32, so the next bank can be loaded.


Starting up and saving a project:

The plugin does provide both the loaded bank AND the active patch to the host when a project is closed. Hence, on loading the project again, both the bank which was loaded, but also the state of the active patch are restored. Currently it does NOT restore the colour of the programme number correctly! So, this should be fully consistent with what is expected from a VST plugin.

The plugin does not have a default bank, as that would only be loaded in new projects anyway. I could implement such default bank, but I am not sure where that should be stored.


This summarizes the behaviour the PG8X is intended to have. If anything does not work as explained, it is a bug, so please let me know.

One more note: As I still might introduce some changes to the set of parameters, fxb and fxp might not yet be compatible between versions.
Once I release the final version, I will, of course, freeze the file format, or make sure that older files can be imported.


Cheers,
Martin

Post

All that seems nice, at least for me.

Martin, may I do a little suggestion for the musicians having troubles of the vision of colors? (they are more frequent than we think, I have already one in my own children):
martin_l wrote: - - -
The fact that a patch has changed from the originally loaded programme is indicated by the programme number turning yellow.
- - -
In order to write the changes to the bank you need to use the WRITE button. Left-clicking the WRITE Button will turn the Programme number red, which indicates that you can select the target programme by clicking on the programme number.
- - -
When the number turns yellow, I suggest you to also add a suffix [D] (and with the square brackets to be clearly visible) to the number displayed.
Simply [D] as "Dirty".

And when the number turns red, I suggest you to also add a suffix [W] (and with the square brackets to be clearly visible) to the number displayed.
Simply [W] as "Writing".

And when the number turns back to its default color, I suggest you to also remove this suffix, simply, to the number displayed.

It's not a big changement. But it will actually please all those having daltonism and all kinds of troubles with the colors.

Ok?
Image
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:After the discussion here on the sense or nonsense of plugin-internal LOAD's and SAVE's, and the confusion about what PG8X does (or should be doing), I thought I better give a short overview of what I intended to do and how the PG8X is supposed to work:

The PG8X has one active patch plus a bank of 128 patches. The active patch is associated with a programme number, which indicates which programme was loaded into the active patch.
You've already lost me. How does the program number (merely it's positional location in the bank) indicate "which programme was loaded into the active patch"?

The way VSTs are supposed to work is there's a bank of n programs. And there is a current program (I guess what you're calling "active patch") that is selected, and is the one you're hearing and editing. And yes, the program number indicates which "slot" that's happening in.

AU is a bit different. There are n presets, which can be loaded *into* the single, programmable position.

(The VST paradigm is by far better, as it allows you to edit more than one program in the bank. So you can switch between them during a performance, for example. Just like classic programmable synths of old.)

Frameworks that allow for development of both types of plug-in need to reconcile these two different behaviors, somehow. Usually it's just let the VST be as it's the more functional of the two, but when it's in AU form, you can only edit program #1, and selecting other preset programs will copy that program to the active #1 position. (Really there is only one active position. The presets are purely read-only in an AU. Though of course the plug-in vendor can choose to offer their own system for changing the preset data.)

To load a new patch from the current bank,
Again, this is a completely alien paradigm. You don't load patches FROM a bank. You switch to a patch (program) within the bank.

When the VST host wants to change to a different program in the bank, it calls setProgram() with the number of the program "slot" it wants the plug-in to switch to passed as the single parameter.

you can either use the host's ways of choosing a patch, or clicking on the programme number, which will then display a popup menu. Both ways should be equivalent. (Some hosts, e.g. reaper, allow to have patches 'outside' the bank, which will not be visible through he plugin's menu).
Yet they're clearly not equivalent as they don't behave the same. Again, when the host wants to change to a different program, it will call setProgram() with the program number it wants the plug-in to switch to. I can't see your code, obviously, but my spider senses tell me that when a user selects a program number from the menu, or uses the + and - buttons, that you do something other than calling that same setProgram().

I'm not sure what you mean about patches "outside the bank". (Perhaps it's a Reaper feature I haven't used?) But if it's not in the plug-in's program list, then the plug-in isn't aware of it and it's none of your concern.

When you change a parameter, it will affect the active patch, but not any of the patches in the bank. The fact that a patch has changed from the originally loaded programme is indicated by the programme number turning yellow.
That is where your problem is. The bank in a VST is inherently volatile. All edits stomp onto it, immediately. (The host is free to implement an undo feature on its own if it likes. Or goodluck writing your own. It's just not a behavior the spec allowed for.)

Are you implying that there are TWO banks? A preset bank and an active bank? Like I said, writing into your presets makes sense. (So you can launch new instances later and see the presets you want in there, rather than just what the product was hard-coded with.) But having two volatile banks breaks the VST paradigm. Sorry, this isn't my idea, it's how all VSTs work (at least the ones that work).

In order to write the changes to the bank you need to use the WRITE button. Left-clicking the WRITE Button will turn the Programme number red, which indicates that you can select the target programme by clicking on the programme number. Once a number is selected, that patch is written to that programme. Right-clicking saves the patch into the current position in the bank.
Again, that's not how a VST should work and if it's necessary to do this, then users of every other product are going to 1. have an extra step in their workflow that they're required to do for just your product. And 2. probably forget that and lose their work that they assumed the host stored with their project.

The entire bank, not just the currently active program, is saved and recalled by the host in its project files. This way you always know you will get the state back that you were in, without having to go through each and every plug-in and do individual saving operations like what I'm afraid you're suggesting here. (Though honestly I don't know if I'm understanding you correctly.)

The same can also be achieved with the host's menu and should have the same effect. I added this, as I got several comments about me old plugin requesting this functionality as apparently some hosts did not offer that (don't know which they were...)
There's a few hosts that don't let you edit the program name field, I think. Most do. And as far as I know they all let you choose which program you have selected. Again, it's not something a VST is required to do. (See the examples in the SDK.)

LOAD and SAVE buttons:

The LOAD button allows to read files of various types: fxb/fxp and sysex. In the VST version, the reading of fxb/fxp should be identical to reading the file through the host's menu (in fact, the same function is called internally). In the AU version (and upcoming standalone) versions, it allows to import fxb/fxp files, which otherwise might not be supported by the host.
What function is that, Martin? When the host saves a .fxp or .fxb the plug-in has no idea how the host does it. The host sucks the relevant data out of the plug-in, either as a chunk or through individual getParameter() calls. Plug-ins don't typically know about the .fxp/.fxb system, and the SDK doesn't document it at all.

Currently supported SysEx files are single JX8P patches (which simply are loaded into the active patch, WITHOUT being saved to any programme in the bank -- sorry, strange JX8P sysex implementation...), or a JX8P bank, which contains a sequence of patches, followed by an instruction to write the patch into the bank.

JX10/MKS70 Sysex files are not yet supported, but I am planning to support them as well (at least the TONE component of them).

The SAVE button currently supports writing fxb and fxp files. Currently this is decided based on the chosen file extension. In the next version there will be a popup menu for choosing the format). For fxb and fxp, this will, again, be identical to the host's function (again, same function call), and is basically only present to provide fxb/fxp support in hosts (Steinberg) which do not support it, or in the AU version.
Again, that's the opposite of how it usually works. And particularly for the Mac people, who are file extension agnostic and/or oblivious.

A note on loading several SysEx banks into one bank: JX8P SysEx banks usually only contain 32 programmes, which will be loaded into the programmes 1-32. The programme popup menu also has the item "Rotate Banks", which will copy those to 33-64, 33-64 to 65-96, and so on. Doing this after importing a SysEx bank, will free up the slots 1-32, so the next bank can be loaded.


Starting up and saving a project:

The plugin does provide both the loaded bank AND the active patch to the host when a project is closed. Hence, on loading the project again, both the bank which was loaded, but also the state of the active patch are restored. Currently it does NOT restore the colour of the programme number correctly! So, this should be fully consistent with what is expected from a VST plugin.
This seems to conflict with what you said above. ("When you change a parameter, it will affect the active patch, but not any of the patches in the bank.")

I'm quite honestly confused.

The plugin does not have a default bank, as that would only be loaded in new projects anyway. I could implement such default bank, but I am not sure where that should be stored.
New projects, or any time you instantiate a new instance of your plug-in (i.e. all the time!) As to the storage locations, we've had lots of discussions about that on the DSP board. (It's constantly changing. Particularly in Apple-land where our privileges to write anywhere are hemmoraging rapidly. It seems ~/Music/Whatever/ is still a safe place to put your data, that's what I'm using as the Library is no longer writable to in "sandboxed" hosts like Logic.)


This summarizes the behaviour the PG8X is intended to have. If anything does not work as explained, it is a bug, so please let me know.

One more note: As I still might introduce some changes to the set of parameters, fxb and fxp might not yet be compatible between versions.
Once I release the final version, I will, of course, freeze the file format, or make sure that older files can be imported.


Cheers,
Martin
If I can't understand this, being someone who does this all day and sells VST and AU products (that nobody complains about the program/bank system not working in) then I'm sure regular users are going to be even more confused. I can definitely see the source of confusion, given the difference in how AU and VST handle programs. But it should be the framework's job to sort that out. I use Symbiosis, which solves it for me without me having to do anything special to the VST.
Last edited by AdmiralQuality on Mon May 26, 2014 11:22 pm, edited 1 time in total.

Post

From the VST 2.4 SDK...

Code: Select all

virtual VstInt32 getProgram () { return curProgram; }					///< Return the index to the current program
virtual void setProgram (VstInt32 program) { curProgram = program; }	///< Set the current program to \e program
Note that there's no mention of "copy" or anything like that. You set to a program "position", and anything you do there is volatile, immediately writing over the original program that was in that slot when you switched to it. (Which was the point you started editing from when you switched to it.)

You will also see the concept there (in the variable name) of "current program".

And remember updateDisplay(), which informs the host you've done something to the program name, so it can ask for it again.

Post

Oh and by the way, the "documentation" for VST is those comments in the SDK code files themselves. They're often quite funny, written in this garbled Germanglish, but they do help.

Post

BlackWinny wrote:All that seems nice, at least for me.

Martin, may I do a little suggestion for the musicians having troubles of the vision of colors? (they are more frequent than we think, I have already one in my own children):
martin_l wrote: - - -
The fact that a patch has changed from the originally loaded programme is indicated by the programme number turning yellow.
- - -
In order to write the changes to the bank you need to use the WRITE button. Left-clicking the WRITE Button will turn the Programme number red, which indicates that you can select the target programme by clicking on the programme number.
- - -
When the number turns yellow, I suggest you to also add a suffix [D] (and with the square brackets to be clearly visible) to the number displayed.
Simply [D] as "Dirty".

And when the number turns red, I suggest you to also add a suffix [W] (and with the square brackets to be clearly visible) to the number displayed.
Simply [W] as "Writing".

And when the number turns back to its default color, I suggest you to also remove this suffix, simply, to the number displayed.

It's not a big changement. But it will actually please all those having daltonism and all kinds of troubles with the colors.

Ok?
Image

This is not something VST plug-ins are allowed to do. (It would interfere with correct playback of automation, just for one example off the top of my head.) The state is the state. There's no "commit" for editing. All changes immediately go into the bank position where your current program is.

Post

OK. It seems your problem is that I am using the fxb/fxp format for my functionality.

The concept of having an active patch into which you can load a patch from a bank, and which you can save back to the bank is not alien at all (maybe alien to the original VST idea).

Other plugins do that as well. Examples are Arturia Mini and Modular, U-He Tyrell, Synth1, SQ8L and probably many others. The difference is, that these ignore the fxb banks. You need to use their own file format to save and load banks. They do restore their complete state (active patch and bank) when a project is loaded again.

The PG8X does the same thing, the only difference is that I use the fxb bank system to store and load banks.
If this causes confusion, I can simply change the file extension of the bank files and remove the function calls which tell the host about the banks used by the plugin, as the other plugins do.

I personally find it more confusing when you really have two co-existing systems, where presets you safe within the plugin do not show up in the host's bank, and vice versa.

My idea was to combine the best of the two worlds. I don't like the idea of volatile banks, where every variation of the patch (e.g. through Midi Learn) is automatically stored. This might be the VST idea, but it is not how hardware synth worked. In the JX8P you needed to write the patch back to the memory.

The architecture was probably more close to the AU idea, only that you can write into the bank.

So far, the only problems which occurred were simply due to bugs and inconsistencies arising from bugs.
If more users complain about inconsistencies or confusion, I can simply do it as the above mentioned plugins and simply ignore the VST system in favour of my own file format (which probably, apart from the extensions, still would be fxb/fxp, as it is simply a dump of the chunks used for internal storage). Personally, I do not see any advantage in doing that, but I am open to discussion.


Cheers,
Martin

Post

AdmiralQuality wrote:
BlackWinny wrote:All that seems nice, at least for me.

Martin, may I do a little suggestion for the musicians having troubles of the vision of colors? (they are more frequent than we think, I have already one in my own children):
martin_l wrote: - - -
The fact that a patch has changed from the originally loaded programme is indicated by the programme number turning yellow.
- - -
In order to write the changes to the bank you need to use the WRITE button. Left-clicking the WRITE Button will turn the Programme number red, which indicates that you can select the target programme by clicking on the programme number.
- - -
When the number turns yellow, I suggest you to also add a suffix [D] (and with the square brackets to be clearly visible) to the number displayed.
Simply [D] as "Dirty".

And when the number turns red, I suggest you to also add a suffix [W] (and with the square brackets to be clearly visible) to the number displayed.
Simply [W] as "Writing".

And when the number turns back to its default color, I suggest you to also remove this suffix, simply, to the number displayed.

It's not a big changement. But it will actually please all those having daltonism and all kinds of troubles with the colors.

Ok?
Image

This is not something VST plug-ins are allowed to do. (It would interfere with correct playback of automation, just for one example off the top of my head.) The state is the state. There's no "commit" for editing. All changes immediately go into the bank position where your current program is.
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

Post

martin_l wrote:OK. It seems your problem is that I am using the fxb/fxp format for my functionality.
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.)

The concept of having an active patch into which you can load a patch from a bank, and which you can save back to the bank is not alien at all (maybe alien to the original VST idea).
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.

Other plugins do that as well. Examples are Arturia Mini and Modular, U-He Tyrell, Synth1, SQ8L and probably many others. The difference is, that these ignore the fxb banks. You need to use their own file format to save and load banks. They do restore their complete state (active patch and bank) when a project is loaded again.
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.

The PG8X does the same thing, the only difference is that I use the fxb bank system to store and load banks.
If this causes confusion, I can simply change the file extension of the bank files and remove the function calls which tell the host about the banks used by the plugin, as the other plugins do.
You mean fxb *format*.

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.

I personally find it more confusing when you really have two co-existing systems, where presets you safe within the plugin do not show up in the host's bank, and vice versa.
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).

My idea was to combine the best of the two worlds. I don't like the idea of volatile banks, where every variation of the patch (e.g. through Midi Learn) is automatically stored. This might be the VST idea, but it is not how hardware synth worked. In the JX8P you needed to write the patch back to the memory.
Yes, you're attempting to mash two conflicting paradigms together. Sorry, but again, VST plug-ins (nor AU plug-ins) don't do that.

The architecture was probably more close to the AU idea, only that you can write into the bank.

So far, the only problems which occurred were simply due to bugs and inconsistencies arising from bugs.
If more users complain about inconsistencies or confusion, I can simply do it as the above mentioned plugins and simply ignore the VST system in favour of my own file format (which probably, apart from the extensions, still would be fxb/fxp, as it is simply a dump of the chunks used for internal storage). Personally, I do not see any advantage in doing that, but I am open to discussion.


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

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.)
Last edited by AdmiralQuality on Tue May 27, 2014 12:16 am, edited 1 time in total.

Post

martin_l wrote: 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.

Locked

Return to “Instruments”