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).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.
PG8X (inspired by the JX8P): new beta version uploaded
- KVRAF
- 11093 posts since 16 Mar, 2003 from Porto - Portugal
Fernando (FMR)
- KVRAF
- 4534 posts since 17 Jun, 2013 from very close to Paris, France
Yes.AdmiralQuality wrote:21st century problems...BlackWinny wrote: Even the sorting by folders in not enough when we have to manage hundreds or thousands patches which are all accessible simultaneously.
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.
I'm now severely diseased since September 2018.
-
AdmiralQuality AdmiralQuality https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=83902
- Banned
- 6657 posts since 10 Oct, 2005 from Toronto, Canada
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.fmr wrote: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".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.
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!
-
AdmiralQuality AdmiralQuality https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=83902
- Banned
- 6657 posts since 10 Oct, 2005 from Toronto, Canada
Please keep in mind, that unless you are an experienced software developer, your opinion is very humble.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).
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!)
- KVRAF
- 4534 posts since 17 Jun, 2013 from very close to Paris, France
Woaw! What temperedness...AdmiralQuality wrote:Please keep in mind, that unless you are an experienced software developer, your opinion is very humble.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).
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!)
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.
I'm now severely diseased since September 2018.
-
- KVRian
- Topic Starter
- 960 posts since 27 Jun, 2009 from Germany
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
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
- KVRAF
- 4534 posts since 17 Jun, 2013 from very close to Paris, France
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):
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?
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):
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.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.
- - -
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?
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.
I'm now severely diseased since September 2018.
-
AdmiralQuality AdmiralQuality https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=83902
- Banned
- 6657 posts since 10 Oct, 2005 from Toronto, Canada
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"?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.
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.)
Again, this is a completely alien paradigm. You don't load patches FROM a bank. You switch to a patch (program) within the bank.
To load a new patch from the current 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.
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().
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).
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.
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.)
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.
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).
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.
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 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.)
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.)
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...)
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.
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.
Again, that's the opposite of how it usually works. And particularly for the Mac people, who are file extension agnostic and/or oblivious.
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.
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.")
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.
I'm quite honestly confused.
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.)
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.
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.
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
Last edited by AdmiralQuality on Mon May 26, 2014 11:22 pm, edited 1 time in total.
-
AdmiralQuality AdmiralQuality https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=83902
- Banned
- 6657 posts since 10 Oct, 2005 from Toronto, Canada
From the VST 2.4 SDK...
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.
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
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.
-
AdmiralQuality AdmiralQuality https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=83902
- Banned
- 6657 posts since 10 Oct, 2005 from Toronto, Canada
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.
-
AdmiralQuality AdmiralQuality https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=83902
- Banned
- 6657 posts since 10 Oct, 2005 from Toronto, Canada
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):
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.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.
- - -
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?
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.
-
- KVRian
- Topic Starter
- 960 posts since 27 Jun, 2009 from Germany
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
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
-
- KVRian
- Topic Starter
- 960 posts since 27 Jun, 2009 from Germany
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".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):
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.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.
- - -
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?
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.
Using a different symbol in my readout (other than colours) is a good idea, and I will implement something along those lines.
Cheers,
Martin
-
AdmiralQuality AdmiralQuality https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=83902
- Banned
- 6657 posts since 10 Oct, 2005 from Toronto, Canada
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.)martin_l wrote:OK. It seems your problem is that I am using the fxb/fxp format for my functionality.
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.
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).
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.
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.
You mean fxb *format*.
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.
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.
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).
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.
Yes, you're attempting to mash two conflicting paradigms together. Sorry, but again, VST plug-ins (nor AU plug-ins) don't do that.
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.
Have you tried actually using your plug-in across several projects, as a typical users would? You'll run into the problems soon enough.
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
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.
-
AdmiralQuality AdmiralQuality https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=83902
- Banned
- 6657 posts since 10 Oct, 2005 from Toronto, Canada
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.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
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.