Zen features requests

[TabSel]

that was it. Works now.

which Zen output is affected by volume control? all?

Feature Suggestion: provide small vu meters/signal indicators for EACH output of the current active plugin, with an additional indication of which plugin output is output to the host through a Zen output.

So the user knows, how many outputs a plugin has, on which plugin output is a signal (might be different per preset) and how much outputs Zen is configured to have currently and which plugin outputs are send to the host thorugh which Zen output.

Later may be provide dynamic I/O config (VST3 that hosts VST2? ), simple dynamic routing of plugin outputs through Zen outputs by drag'n drop... what not... saved with a preset...

(same for inputs, and MIDI I/Os)

ahh, I know, this could grow endlessly...



Is there a technical way for Zen to provide the name of the current plugin to the host, so when you insert Zen in a FX slot in the host, it doesn't show "Zen", but the current plugin name?

Or is it technically possible to offer the host a factory preset list, which will allways contain ONE factory preset, namely the plugin name in Zen concatenated with the preset name. This way, you'd have an Information within your Host, that Zen is in a fx/vsti slot and which plugin/preset is currently loaded in this Zen instance?

[Big Tick]

Well I guess I will have to think everything over (regarding I/O management) when I get to the stage of adding "meta-presets" (e.g, combinations) in Zen.

Is there a technical way for Zen to provide the name of the current plugin to the host, so when you insert Zen in a FX slot in the host, it doesn't show "Zen", but the current plugin name?

Yes, but most hosts don't expect this name to change, and thus will only query it at startup - so it is better to display "Zen", rather than a wrong plugin name.

Or is it technically possible to offer the host a factory preset list, which will allways contain ONE factory preset, namely the plugin name in Zen concatenated with the preset name.

Yes - but unfortunately, VST standard limits the returned preset names to 24 characters (something that, by the way, a lot of plugins don't respect). This means I can't add the plugin name to the preset name. Still, I guess I could make this optional, so that it could be disabled for hosts that insist on the 24 characters limit.

[TabSel]

...regarding I/O management) when I get to the stage of adding "meta-presets" (e.g, combinations) in Zen.

Hear hear, here comes the Zen Sound Hub with morphing between presets/sounds of any plugins *g*

[woodslanding]

I don't know how Automap or Jbridge work, but if they change the FXID in any way, then there is no way Zen can know that *its* Absynth presets can be loaded in *your* automaped/jbridged Absynth.

Well, could we have a mechanism to TELL it they can??? Not everything needs to happen 'automatically'!!!

if it finds duplicates with some of your local presets, the local presets are removed and replaced by the public ones. Any tags you have set for these local presets are kept, so the only difference for you is that the preset color changes from green to grey.

,,,,AND ALL MY EDITS ARE LOST!!???

Please tell me by the word DUPLICATES, you mean 'identical data' not 'identical name'!?

I you are going to replace my carefully edited local versions of presets with the originals, I'll clear my database, turn off the download feature and start fresh.

If not, great. But it would be really nice to allow the user to rename local presets from within Zen, to reduce confusion. Especially since so many VSTs don't have a built-in means of renaming presets.

Thanks,
-eric

[Big Tick]

Well, could we have a mechanism to TELL it they can??? Not everything needs to happen 'automatically'!!!

True. So maybe a way to override the FXID match requirement... Still, I can see complaints about crashes when trying to send a Rhino preset to Zebra.

Please tell me by the word DUPLICATES, you mean 'identical data' not 'identical name'!?

It's identical name AND data (or, more accurately, CRC32 of the preset data). So your local edits won't be lost.

But it would be really nice to allow the user to rename local presets from within Zen, to reduce confusion. Especially since so many VSTs don't have a built-in means of renaming presets.

I hear you. Which VST's don't allow to rename presets ?

[moss]

Thanks for the great tool!

I am looking currently into it as a replacement for the KORE librarian. One feature I wanted to see in KORE for a long time is the ability to select the Category via Midi CC so I could select a category from my master keyboard. It would be sufficient to use 1 CC so the value 0 would select Bass, value 1 Bell, etc. This way I could assign it to individual buttons or scroll through the categories with a knob. Make it MIDI assignable by right click like with the 8 modification buttons. BTW it would also be nice to have midi learn for the patch selection (not only via the properties file).

Are you planning to document the sound format of Zen? I would not like to end up in a dead road again like with KORE.

[moss]

Uh I forgot:

- Resizability of the window would be nice to have.

[Big Tick]

Are you planning to document the sound format of Zen? I would not like to end up in a dead road again like with KORE.

Yes, this is a very legitimate concern. Preset metadata is managed in a SQLite database (zen.s3db), you can actually open it with an SQL editor and check it out. This I have no problem making public.

Then there is the issue of actual preset data. Preset data is stored in a file, and contains an encrypted version of the preset fxp. The encryption is necessary because Zen can play commercial presets. This means, I might have to change a few things so that free presets are stored as fxp, and commercial presets are stored in their encrypted form.

'Tick

[moss]

Thanks for that quick reply!

Preset metadata is managed in a SQLite database (zen.s3db), you can actually open it with an SQL editor and check it out. This I have no problem making public.

Ah, that looks nice.

Then there is the issue of actual preset data. Preset data is stored in a file, and contains an encrypted version of the preset fxp. The encryption is necessary because Zen can play commercial presets. This means, I might have to change a few things so that free presets are stored as fxp, and commercial presets are stored in their encrypted form.

Hmm, at least the sounds I import locally should not be encrypted. Furthermore I am not quite sure if encryption is a good idea at all. If someone wants to rip the sounds he can still store it from the plugin (I guess also the encrpytion key is somewhere static in the code). I would find it more interesting to fully open up the format so that even other developers can jump on it.

And finally another wish:

If you click on next/previous sound (also via midi) and no sound is selected nothing happens. It would be nice if the first(next) and last(previous) gets selected.

[Big Tick]

Hmm, at least the sounds I import locally should not be encrypted.

Actually, they are not. Locally imported presets are stored as fxp files, which is another public format.

Furthermore I am not quite sure if encryption is a good idea at all. If someone wants to rip the sounds he can still store it from the plugin

No they can't - Zen doesn't allow to open the plugin window when the selected preset is a commercial one - at least, not until you purchase it.

(I guess also the encryption key is somewhere static in the code).

No it's not. The first time you run Zen it generates a dynamic set of private/public keys. These are the ones used for encrypting the files.

I would find it more interesting to fully open up the format so that even other developers can jump on it.

Here is what I'm thinking of: I will store non-commercial presets just like locally imported ones. With this, the format will be fully open: you get your metadata from the sqlite database, and presets are stored as <preset ID>.fxp.
And yes, it would make a lot of sense to use the Zen DB storage for developers who want to add a preset browser to their plugins.

If you click on next/previous sound (also via midi) and no sound is selected nothing happens. It would be nice if the first(next) and last(previous) gets selected.

Noted

[moss]

Awesome, thanks for the detailed answers!

Can't wait for the next version...

[Panphobia]

Wow, just found zen, if it is half as good as it looks then I will be very happy. Too awesome to be free!

[sjm]

I'd love an (additional) import button that basically just updates the currently selected patch with the current synth data (assuming the synth matches the selected preset).

Here's why:
I played some nice chords using a Synth1 patch of my own, and wanted to search for a suitable preset for a bass sound in Zen. I clicked on a Synth1 preset tagged as a bass, but when playing along, everything sounds very wrong. I open up Synth1 to discover that the preset is configured to transpose everything by 6 semitones. I have no idea why you'd want to do this, but I certainly would like all presets to be tuned to one another. So I set the "Key Shift" parameter to 0.

But if I now import the new Synth1 preset into Zen:
+ Zen adds a new preset called "Initial sound" because Zen only loads the preset data in Synth1, but not the name of the patch.
+ Because I can't just update the preset (AFAICT), I need to remove the previous patch, assign the correct tags to my new patch rename the patch accordingly etc. which seems superfluous in this case.

I'd love a 1 click solution for this, and surely this has its uses for preset designers who might want to make minimal tweaks to their existing presets to update them.


I've discovered quite a few Synth1 patches transposed in this way, and other presets are simply too loud in some synths and therefore clip (SQ8L is particularly problematic in this respect). I'd love to be able to fix and presets so that they're no longer transposed awkwardly or clip. Otherwise I'm leaving the presets untouched, so I really don't want to add a new patch (especially not one called "Initial sound").


If there is a simple way to do this, and I'm just being dense, do let me know (how to do it, not that I'm dense)

[Big Tick]

Hi,

There is something wrong with the new preset being called "Initial sound". Did you check if you have the same behavior with other synths ?

What I would have expected is:
- Zen prompting that there is already a preset with the same name, but different data, and asking if you want to import anyway.
- then, it would simply be a matter of adding a 3rd option in the prompt: "replace existing".

'Tick

[sjm]

The funny thing in Synth1 is that my presets all show the correct name, but the presets I downloaded in Zen always show "Initial sound".

I assume it's a Synth1 thing, as Synth1 manages it's own banks, and my sounds are also present in the banks I have set Synth1 up to use.


Edit: In SQ8L it gets the preset name right, so it's definitely Synth1 being weird.