MUX Vst : What do you need?

[MuTools]

The most important feature for me would be to have the same rectangle selection ability as in the composer view.

The only other thing that I find myself wishing for is an encapsulate feature. Often when I'm playing with a modular fx patch or something, I'll come across one subset of the patch that I think I'd like to reuse in the future. So I save the main patch, delete all the modules except for the subset I'm interested in, then save this new patch and reload the old one. Being able to select a group of modules and have them moved to a new MuX module would be very handy for me, but then I might just have a funny workflow

I also want that functionality. It's on the MUX wishlist.

[liquidsound]

Make some good skin package if you can. There are still lot of users going for the look as well as functionality.
I hear people not using synth like Zebra or Surge because of the way they look

[Juan Mendoza]

Now with this topic i'm curious for those 'essential improvements', i.e. what needs to be done to the existing MUX to make it a useful MUX Vst 1.0. Maybe it's already worthy as it is now?

I dont think there's something really essential, atm MUX has a lot of potential and it'll be well worth in it's current state.

But if you ask wich 2 wishlist items i'd choose to make it better before relase, i'd go for a convenient device -> patch architecture, and further enriching the PEs (i.e: background images or at least background colors, more GUI elements dragable to the PE like filter type selctors etc)
This is also related to what liquidsound wrote above, the better looking, the better!

Following this i'd continue enriching the sound engine with more modules etc. Specially some kind of solution to create flexible modulation routings (or mod matrix), but this all may be a MUX2 topic though.

[pljones]

I dont think there's something really essential, atm MUX has a lot of potential and it'll be well worth in it's current state.

+1

When playing back samples, then an eventual difference between the sample's samplerate and the audio engine's samplerate is taking into account and compensated in real time.

So how do you mean?

For playing audio files. Currently a batch process converts the file, creating a new file, which is then played.

...edit...
Actually, that's in the session, not mux...

[> DiGiT <]

i think whatever you can do to make a BANG of an impression is important since this is the age of disposable software items...

[MuTools]

and further enriching the PEs (i.e: background images or at least background colors, more GUI elements dragable to the PE like filter type selctors etc)

Practical question wrt building a PE:

Coloring a module is especially handy to make a visual link to the tracks.
But maybe it would be better if the color of a module button on the PE is not defined by the module, but is just a customizable color that is stored with the PE. If it would be done like this, then choosing a color for a module does not affect a PE. Would that be better?

[Trancit]

and further enriching the PEs (i.e: background images or at least background colors, more GUI elements dragable to the PE like filter type selctors etc)

Practical question wrt building a PE:

Coloring a module is especially handy to make a visual link to the tracks.
But maybe it would be better if the color of a module button on the PE is not defined by the module, but is just a customizable color that is stored with the PE. If it would be done like this, then choosing a color for a module does not affect a PE. Would that be better?

I don't know, if that would really make a difference...

For my personal taste would be nice to have:

- Backround images or ability to load something like png
- user defineable different knobs (specially different sizes) with their own enviroment, which is quite big to build up a GUI
- not only knobs but sliders and buttons
...

All these things are not possible to implement over night I think, so perhaps it's better to keep something like this for future updates...

[MuTools]

I don't know, if that would really make a difference...

For my personal taste would be nice to have:

- Backround images or ability to load something like png
- user defineable different knobs (specially different sizes) with their own enviroment, which is quite big to build up a GUI
- not only knobs but sliders and buttons
...

All these things are not possible to implement over night I think, so perhaps it's better to keep something like this for future updates...

Indeed. And all these things are also related to supporting "user devices".

[Tricky-Loops]

Can't believe it, I'm getting insane...

So I really can use the MUX VST in my REAPER? That's like a dream come true...

My wish would be that as much as possible synthesis forms were available and that these can be combined.

Do you already know how much it will cost? And when will it be released?

[MuTools]

Can't believe it, I'm getting insane...

So I really can use the MUX VST in my REAPER? That's like a dream come true...

My wish would be that as much as possible synthesis forms were available and that these can be combined.

MUX 1 can do a lot already.
MUX 2, 3, 4... will even do more

Do you already know how much it will cost?

No, TBA.

And when will it be released?

June/July.

[Nielzie]

- not only knobs but sliders and buttons

That! +1! Please!

[highkoo]

A meandering Google search led me back to good ol' KVR, and this thread.
And coincidentally, this baby is due to be released soon!
Kismet!
I think you will add many customers with this VST.

[DHR53]

It's a must have plug for sure... but, will it be released initially for the Mac as well?

(and please fix the midi bug too...) Ha!

[Caps]

A - What is the objective of the VST release?

B- Who is the consumer?

Here is what I think, a MUX VST will not swing many, if just a few existing host users to Mulab. The delight of Mulab is in its: integration, UI, routing capabilities, routing UI and workflow. I would rather the development move away from VST. VST has it limits and its drawbacks. In the future, Mutools needs to develop an API which allows the VST developer to take full advantage of Mulab/MUX gallery of possibilities (seamless integration). An API at this state is nearly impossible unless Mulab is developed from the ground up. This approach at this state is not practical.

*The development of a MUX VST does little for existing Mulab users.

[Tricky-Loops]

A - What is the objective of the VST release?

B- Who is the consumer?

Here is what I think, a MUX VST will not swing many, if just a few existing host users to Mulab. The delight of Mulab is in its: integration, UI, routing capabilities, routing UI and workflow. I would rather the development move away from VST (seamless integration). VST has it limits and its drawbacks. Mutools needs to develop an API which allows the VST developer to take full advantage of Mulab/MUX gallery of possibilities. An API at this state is nearly impossible unless Mulab is developed from the ground up. This approach at this state is not practical.

*The development of a MUX VST does little for existing Mulab users.

I think it's not the purpose to "swing" host users to MULAB, but to make MUX also usable for users of other hosts. People that have MULAB don't need a MUX VST; they've got MUX included. MUX is a great modular synthesizer, and I'm absolutely happy if I can get a VST version of it to use it in my REAPER.