Mulab under the hood

[skarabee]

So why introduce another layer of 3rd party software (wrapper)? And what to say about selling a soft wich requires a wrapper?

Most plugins you use today use some sort of plugin abstraction then wrappers to individual plugin formats. JUCE, iPlug2, these sorts of things, they all do it. This is perfectly normal stuff that has been done for decades really. You're nitpicking for no good reason. Wrappers are not rocket science, and are not a performance hazard. Repeat this a thousand times.

What term in "3rd party software" didn't you catch? Nothing to do with internal software layers. The fact to rely on another external guy's work and piece of software to sell your stuff is at least risky. I experienced it.
Read before answer. Repeat this a thousand times.

[syntonica]

Believe me: VST3 is future, all major PC DAWs implement it and studying VST3 support now is a future-proof investment for a DAW and plugin maker, no matter how many months will took for having a VST3-enabled MuTools out.

Apparently Jo doesn't possess the required knowledge to implement VST3 support and he's not willing to learn. Shame on you, Jo!

P.S. Learning is good for the brain

Apparently, nobody (except maybe Yvan?) possesses the required knowledge to implement VST3 support since SB had to hand-hold NI through the process.

There. That's the real joke.

I vote for keeping some sort of plugin support, whether VST2, VST3, or CLAP, or some combination thereof. There are some things that are too difficult to ultimately impossible (mostly due to lack of knowledge) to build in MUX. This includes especially things like reverbs (setting up delay networks with proper timings takes mad skills or luck better used on winning the lottery!) and synths (physical modeling, e.g.). They can be done, but not without a huge loss in quality and/or time, hair, sanity, etc.

[robert_p]

Apparently, nobody (except maybe Yvan?) possesses the required knowledge to implement VST3 support since SB had to hand-hold NI through the process.

There. That's the real joke.

That's wonderful! "Don't buy counterfeit VST3 products - only the touch of Steinberg's magic hand guarantees full compatibility"

[mutools]

I vote for keeping some sort of plugin support, whether VST2, VST3, or CLAP, or some combination thereof. There are some things that are too difficult to ultimately impossible (mostly due to lack of knowledge) to build in MUX. This includes especially things like reverbs (setting up delay networks with proper timings takes mad skills or luck better used on winning the lottery!) and synths (physical modeling, e.g.). They can be done, but not without a huge loss in quality and/or time, hair, sanity, etc.

I agree. The wild idea/question of a pure MuLab-only sound system has been swept off the table. You guys convinced me that support for external plugins is too essential.

[fde101]

VST3 is future, all major PC DAWs implement it and studying VST3 support now is a future-proof investment

The license agreement that developers must agree to in order to gain access to the VST3 plugin format allows Steinburg to pull the rug out from under them without needing any particular cause or reason and with only 6 months notice, which is not much if the developer needs to scramble to find some alternative.

That short notice does require Steinberg to release a newer version of VST under a separate license, but they could easily change that license to make it even worse than the current one, perhaps charging for its use or placing restrictions that would make it impossible for some developers to continue.

A developer who relies on VST3 for their product line (particularly a dedicated plugin developer who makes their livelihood from it) is placing themselves at extreme risk from the whims of one company who has already made several attempts to squash the older version of their own format in various ways.

VST3 is not and never will be a "safe" investment unless the terms of that license agreement change. If I were in a position to be developing plugins I would never sign that agreement and would look to alternative formats (such as CLAP and AU) instead.

[syntonica]

VST3 is future, all major PC DAWs implement it and studying VST3 support now is a future-proof investment

The license agreement that developers must agree to in order to gain access to the VST3 plugin format allows Steinburg to pull the rug out from under them without needing any particular cause or reason and with only 6 months notice, which is not much if the developer needs to scramble to find some alternative.

That short notice does require Steinberg to release a newer version of VST under a separate license, but they could easily change that license to make it even worse than the current one, perhaps charging for its use or placing restrictions that would make it impossible for some developers to continue.

A developer who relies on VST3 for their product line (particularly a dedicated plugin developer who makes their livelihood from it) is placing themselves at extreme risk from the whims of one company who has already made several attempts to squash the older version of their own format in various ways.

VST3 is not and never will be a "safe" investment unless the terms of that license agreement change. If I were in a position to be developing plugins I would never sign that agreement and would look to alternative formats (such as CLAP and AU) instead.

VST3 is essentially designed for tight integration into Cubase and nothing else. As a general standard, it's next to useless. As a programmer, I'd strongly recommend basing your plugins in CLAP, even if it's never accepted as a common standard. It's ease of "wrapability" makes it a good lingua franca of the plugin world.

[SparkySpark]

A bit late to the game, but here are my few cents:
1. As already been confirmed - please continue to allow VSTs etc.
2. I would hope for a wrapper that works as an invisible container. In other words, no UI change whatsoever, but the user can throw anything at it: CLAP, VST2, VST3, AU, ... If there is such a thing - and I believe there are a few - then I'd gladly pay extra money to have it seamlessly integrated in MuLab. As a HUGE bonus, Jo would never have to worry about APIs anymore, and save loads of dev time.
3. I personally don't see the need for VST3 (but I know others want it for various reasons).
4. I agree with Jo's original statement that "everything's already there". Some of the MUXes I've made are super useful, and would be quite useful in other environments (and likely to others). For instance, with rather little effort, I created an awesome multi-delay with features I have yet to see amongst delay units at KVR. So, what I think is that MuLab should enable EXPORT of these gems into VSTs/CLAP. That way, we could all start to give away (or perhaps sell) instruments and fx made with MuLab, as well as nifty additions to, say, common third-party reverb units missing EQ filters. I understand not everything could be exportable for technical reasons, but some surely would. I think this would increase MuLab sales greatly, since we would then have a new very powerful SynthEdit or so, for free (apart from the MuLab license ofc). I guess it would also be more fun for Jo to continue the MUX track, if interest for developing and sharing MUXes increases again.

That's all from me this time!

[sl23]

2. I think you're dreaming on that one! But I would like to add that I hope as much as you that this could happen.

4. would be great, but I think this should be a chargeable extra, not included for free. That's likely to be a lot of work to get that up and running!

[pljones]

4. would be great, but I think this should be a chargeable extra, not included for free. That's likely to be a lot of work to get that up and running!

Agreed - a "Made in MuLab" logo being mandatory, too, with a link. "Enable developer features" could be an extra, maybe even with multiple levels ("up to 10 exports for $xxx", etc).

I'd hope the export would just be to a locked-down instance of MuLab as a container for the project - so not too hard to develop or maintain.

[sl23]

Good idea!

[SparkySpark]

2. I think you're dreaming on that one! But I would like to add that I hope as much as you that this could happen.

Thanks. Not necessarily: the idea is that the devs behind a current wrapper, like KV Element, is put on each rack slot (but invisible to the end user). That way, if one drags a VST2 or a MUX to the rack, the wrapper is not engaged. If, on the other hand, one drags a Waves, VST3, Melodyne perhaps, clap or so, the wrapper takes care of it. If the API is somewhat easily used, then Jo would only need to implement that one, and only once. Hopefully, the wrapper is in itself updated, so that no work would be needed for "VST4" or what have you.

Of course, for the original dev, this opens up possibilities, since all DAW devs today need to write all this uninteresting code.

And then we all pay, say, 10 euros extra, money that goes to the wrapper dev, and everyone's happy.

[SparkySpark]

4. would be great, but I think this should be a chargeable extra, not included for free. That's likely to be a lot of work to get that up and running!

Agreed - a "Made in MuLab" logo being mandatory, too, with a link. "Enable developer features" could be an extra, maybe even with multiple levels ("up to 10 exports for $xxx", etc).

I'd hope the export would just be to a locked-down instance of MuLab as a container for the project - so not too hard to develop or maintain.

Well, I'm more thinking a marketplace solution, with vsts made in MuLab. Added to an easily integrated software sales solution, where 50 percent goes to MuTools.

Of course, the MuTools logo should be there, with direct links and all

I think this could lead to much higher interest in the MUX standard, and increase sales of MuLab licenses (in addition to the sold items).

And I agree with pljones that programmatically speaking this might be doable. Since MuLab 9, I assume the code is already there and just needs some shaving off.

[Michael L]

I'd hope the export would just be to a locked-down instance of MuLab as a container for the project - so not too hard to develop or maintain.

Also, the plugin can benefit from features of the MuLab container. For example, if I did a midi scripting plugin, it would be integrated with existing modules, e.g. step sequencer or note action map, so MuLab would value-add to be a more complete solution and thus competitive.

[hey212]

About external plugin support:

Basically there are 2 main reasons why the wild thought of 'what about making MuLab pure MUX based' passed my mind:

1. The fact that there are too often techncial probs with VST plugins.
   That not only leads to user & dev frustration, it also takes an important amount of dev time and slows down the development of MuLab and its integrated modular sound system itself.
   VST3 does not give a good impression. Its SDK is far more complicated (overly complicated) compared to VST2 and i'm afraid it will cause even more support overhead.
   As a solo dev i really have to be careful with the total amount of work on MuLab.
   If the total amount of work would exceed my capabilities, MuLab would suffer from it, and nobody would win from that.
   On top of that tech aspect, Steinberg has also generated a trust issue with its VST licensing decissions the past years.
   .
2. VST plugins do not allow the same deep integration between all musical parts of MuLab.
   And it is that deep integration that is one of the main goals & strengths of MuLab. Right?
   A uniform system is more easy to use and to develop.

At the other hand i fully acknowledge the benefits of external plugin support and i'm concerned that ceasing it would downgrade MuLab for many users.

So after reflecting more on this topic, i think it's relevant to have a deeper look at CLAP and see if it can function as a good compromise. If CLAP proves to be a good and solid system, then a VST3-as-CLAP wrapper would be a very welcome solution. That way external plugin support would be further guaranteed, also VST3, but the amount of necessary dev time can be limited to VST2 (already exists) and CLAP only. And such development path would also not exclude future options, eg. when there would come a good and gentle VST4.

How does that sound to you?

Curious for your opinions.

Again: No decission taken yet at all.
Day after day i'm learning from your input and updating my view.

Thanks!

You should add CLAP support and remove direct VST 2.4 support. This would accomplish both, seemingly opposed objectives.

1) It would reduce the amount external plugin related code you have to maintain as a single dev, and simplify the interface from MuLab's perspective as you could factor the code with the knowledge that you never have to support another format other than CLAP.

2) It would give you external plugin support for all major formats FOR FREE, through the CLAP-VST2, CLAP-VST3, CLAP-AU, CLAP-ETC wrappers.

[mutools]

2) It would give you external plugin support for all major formats FOR FREE, through the CLAP-VST2, CLAP-VST3, CLAP-AU, CLAP-ETC wrappers.

I was thinking similarly but the issue is that there is no VST3-to-CLAP wrapper atm.