Zen features requests

Official support for: bigtickaudio.com
Locked New Topic
RELATED
PRODUCTS

Post

I'm sure somebody must've suggested this before but I couldn't find anything while scanning through this thread.

When I'm making selections as to which sound/plugin etc. in the main window to narrow down on presets, it seems I can only ever select one item per list.
What I would like is a way to e.g. select multiple plugins, or all except for one.

My problem is this: I have full versions of plugins installed as well as demos for evaluation. for testing out the demos I added them to Zen to get a great overview about what they can do, but when making music I'd like to hide the plugins that are Demos and only show those that I bought. Selecting multiple per list would solve my problem.

-- Peter

Post

The reason you can't is because of a usability choice: when you select multiple tags, Zen filters using a "AND" logic. If you click on "Bass", you have, say, 6000 presets. If you click on "Mono", this will show you the monophonic basses, not the presets that are either bass, or mono.

Following the same logic, selecting "Rhino" and "Zebra" would obviously return 0 presets, since there are no presets belonging to both synths. The same logic applies to the authors tags.


You can, however, use right-click on a synth tag to remove it from the search (e.g, search for presets that don't belong to this plugin). So, right-click on all your demo synths will do the trick.

Remember, though, that a lot of demos don't allow to load or retrieve presets, so their behavior with Zen is likely to be erratic.

'Tick

Post

Thanks. Will definitely try out the right-ckick trick!

No worries, my Zen supported plugins that are demos are Zebra and ACE so far. AFAIK their only limitations are in audio output. I'll keep it in mind for future demos though.

Post

got Zen crahing after successfully dragging some plugins to it and clicking on the default empty preset entry for it. Trillian for example.

What can I do to help you improve on hosting stability?

Some Qs:

- What about VSTi's with multiple stereo outs? Does Zen itself have multiple stereo outs and route the VSTis outs through them back to the host?

- What about VSTis that send MIDI out? Does Zen itself have MIDI out and route the VSTis MIDI out through them back to the host?

- Zen standalone seems to loose its MIDI config? I always have to reselect the right MIDI port. Is there are way for the standalone to have multiple MIDI ports active? And specify the ASIO out channels?

- Would it be possible to integrate the Plugin GUI directly into the Zen interface, like reaper does in its channel fx window? - If not, what abou a "TOGGLE VSTi gui" option

- What about a "Zen Server" option, where Zen is a server which manages multiple instances of itself, like Vienne Ensemble Pro does. So you could setup your Zen Server Rack and connect various instances of Zen in a host, without Zen unloading its setup, when the host is quit.


Your Roadmap looks promising :-))

Post

TabSel wrote:got Zen crahing after successfully dragging some plugins to it and clicking on the default empty preset entry for it. Trillian for example.

What can I do to help you improve on hosting stability?
Convince Spectrasonics to give me a Trillian NFR ? :)

Some plugins crash when sending them a preset, while the plugin UI is closed. This is typically a plugin bug, there's nothing I can do about it.
What about VSTi's with multiple stereo outs? Does Zen itself have multiple stereo outs and route the VSTis outs through them back to the host?
Yes - just change this in zen.properties:

Code: Select all

zen.numInputs: 2
zen.numOutputs: 2
What about VSTis that send MIDI out? Does Zen itself have MIDI out and route the VSTis MIDI out through them back to the host?
Zen passes through everything sent from the plugin, so midi automation should also make its way to the host. I haven't tested it, though.
Zen standalone seems to loose its MIDI config? I always have to reselect the right MIDI port. Is there are way for the standalone to have multiple MIDI ports active? And specify the ASIO out channels?
I would say, don't bother with the standalone - I don't plan to support it anyway, it was (just like the Rhino standalone) just used for test purposes. You'd better off using savihost if you need a standalone version.
Would it be possible to integrate the Plugin GUI directly into the Zen interface, like reaper does in its channel fx window? - If not, what abou a "TOGGLE VSTi gui" option
I don't think it would work - the size of plugins UI just wouldn't fit in the Zen UI. As for the "Toggle GUI" button, you don't like the double-click ? There is an option for automatically opening the plugin window whenever a preset is selected, if you prefer. It's in zen.properties, zen.automaticallyOpenPluginsEditor.
What about a "Zen Server" option, where Zen is a server which manages multiple instances of itself, like Vienne Ensemble Pro does. So you could setup your Zen Server Rack and connect various instances of Zen in a host, without Zen unloading its setup, when the host is quit.
What would the benefits be ?

Post

Trilian doesn't Crash in other hosts when send a preset while GUI is closed...
You could add an Option in Properties to Open GUIs automatically before a preset is send to a plug.

Zen Gui could resize/extend itself in Order for the Plug to fit. Or being user resizable with scrollbars. I Know this isn't a vst2.x Feature, but it seems doable nevertheless.
It would Be a Way to prevent window Clutter. At least, Default Plug GUI Position should Be right or beneath Zen, and Window Position remembered upon closing/opening GUI.

Doubleclick a Zen preset is Perfect for opening the GUI, but a double click on a zen preset while the GUI is Open should Close it again. A toggle functionality, to prevent Mouse travel.

Benefits of a Zen Sound Hub:
The user would no more instantiate VSTis directly, but instantiate multiple Zens in his instrument (and later fx) racks/slots.
He would no more have to deal with multiple GUI windows, or seeking tracks and their instrument/fx slots, but instead, has ONE Zen Interface in which he browses through all instantiated plugs in His project in a Central Spot. No Need to Interrupt workflow, mousing around.

Each Zen instance could Be given tags for Browsing/finding/navigating to the right Instrument/fx... All Controlled by MIDI...

Trying another Arrangement with the Same Sounds/fx does Not mean closing the project, creating a new one and Setting Zen up again. Instead, Close the project, with Zen Server preserves state, creating a new One and simply instantiate Zen and connect to the right Client...

Just an Idea... I can perfectly Imagine something like a Sound Hub. It would be a global Preset/Sound Management System across all DAWs.

Post

I see....

couldn't the same results be achieved (minus the part about preserving state when closing project) if all Zen instances shared the same UI ?

Post

About Trillian, if you want to test the "preset with UI closed" thing, you need to:
-load Trillian.
-make sure your DAW doesn't open Trillian window automatically.
-from the DAW, load a fxp (if you have such functionality) and send it to Trillian.

It's hard to test it with most DAW's because they either open the plugin window automatically, or don't provide an interface for sending a fxp to the plugin.

And, it is not enough to close the window before sending the preset. The bug with M1 is exactly this, it crashes when sending a single preset, when the editor window has never been opened before.

Post

Big Tick wrote:I see....

couldn't the same results be achieved (minus the part about preserving state when closing project) if all Zen instances shared the same UI ?
Of course. Preserving State is only necessary when Zen manages Sampler VSTis which itself load huge libraries. Without preserving State, you could Save Zen's State within a fxp and load it back in another project.

Post

Big Tick wrote:About Trillian, if you want to test the "preset with UI closed" thing, you need to:
-load Trillian.
-make sure your DAW doesn't open Trillian window automatically.
-from the DAW, load a fxp (if you have such functionality) and send it to Trillian.

It's hard to test it with most DAW's because they either open the plugin window automatically, or don't provide an interface for sending a fxp to the plugin.

And, it is not enough to close the window before sending the preset. The bug with M1 is exactly this, it crashes when sending a single preset, when the editor window has never been opened before.
I See, i'll check if I'm able to check it ;)

Meanwhile, Why doesn't Zen open the GUI automatically, if it was never opened
Before the preset is send to the plug? ;) property option maybe?

Post

Meanwhile, Why doesn't Zen open the GUI automatically, if it was never opened
Before the preset is send to the plug? Wink property option maybe?
This is what the option zen.automaticallyOpenPluginsEditor is for.

Post

Big Tick wrote:
Meanwhile, Why doesn't Zen open the GUI automatically, if it was never opened
Before the preset is send to the plug? Wink property option maybe?
This is what the option zen.automaticallyOpenPluginsEditor is for.
Ah, as like I'd written Zen myself ;)

Thank you!

Post

Big Tick wrote:
Meanwhile, Why doesn't Zen open the GUI automatically, if it was never opened
Before the preset is send to the plug? Wink property option maybe?
This is what the option zen.automaticallyOpenPluginsEditor is for.
quick update: I set this to true, started Zen, clicked on Trilian and then on the single empty default preset for Trilian.

The GUI opens, and as soon as it is open, Zen crashes.



edit: tried VSTHost. loaded Trilian, opened the GUI, set it up, saved a program (fxp). Restartet VSTHost, loaded Trilian (GUI is not opened), loaded the program: no crash. Opened the GUI, fxp correctly loaded...

Post

ok, thanks for the test. There isn't much I can do without Trillian, unfortunately.

Post

Thinking about it, this may be an issue related to the number of I/O. How many inputs/outputs does Trillian have ? If it's more than 2/2, you might want to change the defaults in zen.properties, so that the Zen I/O matches the Trillian ones.

Locked

Return to “Big Tick”