What wrapper do you use?

[Dr.Dave]

I can c++ and code plugins but I'm stuck how to get started.

JUCE lacks decent tutorials and you need to pay if you want to release your plugins without sharing your code.

There's a whole bunch of you doing this stuff without JUCE. How do you do it?

(A wrapper with some tutorials would be useful)

[Ivan_C]

Personally I have a licence of JUCE. I think there are not tons of open source equivalents to do all the wrapping stuff. The most popular is WDL-OL.

https://github.com/olilarkin/wdl-ol

Otherwise, you will find a lot of people doing more or less proprietary / closed source wrappers, or people keeping the thing for themselves and using it in all their own releases.

[Tale]

+1 for WDL[-OL]/IPlug.

[Miles1981]

I'm using wdl-ol. But There are real tutorials apart from really simple ones. The examples help you for usual audio effects though.

[Squidsneeze]

Of course we use our own written wrappers. This took some time, but coding is fun! And the more you know about the plugin formats, the more advantages you'll have with bugfixing. Also you're able to easily add another plugin wrapper (e.g. MAS, direct x, dsp based formats) without being dependent from another developer.

There are also things some libraries may not be able to handle. AFAIK JUCE for example can't handle plugin-shells.

[Platinum Samples]

Our Accent engine hosts 3rd party plug-ins using JUCE and Waves plug-Ins (which use a shell) work fine.

Rail

[Squidsneeze]

Our Accent engine hosts 3rd party plug-ins using JUCE and Waves plug-Ins (which use a shell) work fine.

Rail

I don't know about JUCE shell capabilities with hosting plugins, but it can't handle it when creating plugins

[JCJR]

What are the advantages of a shell approach?

Does the user see any advantage to a shell, other than possibly less complexity somehow?

When I was in process of retiring a few years ago, did some last-minute work trying to better-support shelled plugins in a couple of hosts. Can't recall many details about it.

I'm not prejudiced against shelled plugins. Just at the time was wondering "Why in the world would they want to do that?" and never got around to seriously asking anyone about it. Was wondering maybe a shell makes copy protection somehow better/more bulletproof to implement? Am too ignorant to know if even that would be a reasonable guess.

[Squidsneeze]

What are the advantages of a shell approach?

The shell concept was just an example of what libraries might not be able to handle. I bet there are more things, but I noticed this one with JUCE years ago.

Anyway, some advantages of a plugin shell could be easy resource sharing and inter plugin communication. I know this can be done in other ways too, but this one is the fastest to implement - especially during development and testing.
Also sometimes it is more "logical" to me to bundle plugins which belong together, like a sender & receiver or a special mono & stereo version. Like e.g. in AAX/RTAS where the plugin can describe several i/o stem formats - so technically these are shells too

The other way is to question "what is wrong with using a plugin-shell?". I mean, it is very easy to implement on plugin & host side. There are no functional restrictions compared to plugins in different files. So I think it's simply a matter of taste and preferences.

[Dr.Dave]

Thanks for the replies! Much appreciated

Any recommendations of tutorials/getting started with WDL-OL?

[JCJR]

What are the advantages of a shell approach?

The shell concept was just an example of what libraries might not be able to handle. I bet there are more things, but I noticed this one with JUCE years ago.

Anyway, some advantages of a plugin shell could be easy resource sharing and inter plugin communication. I know this can be done in other ways too, but this one is the fastest to implement - especially during development and testing.
Also sometimes it is more "logical" to me to bundle plugins which belong together, like a sender & receiver or a special mono & stereo version. Like e.g. in AAX/RTAS where the plugin can describe several i/o stem formats - so technically these are shells too

The other way is to question "what is wrong with using a plugin-shell?". I mean, it is very easy to implement on plugin & host side. There are no functional restrictions compared to plugins in different files. So I think it's simply a matter of taste and preferences.

Thanks for the explanations, SS.

I can't say anything is wrong with shelled plugins. Am typically prejudiced toward, "keep it simple" and shelled seemed less simple, at least from the hosting side. Maybe it is easy. Haven't studied in sufficient detail.

The old host code I was trying to last-minute improve before retirement, had certain methods of storing lists of which plugins to display in pop-menus, vs what plugins to ignore. Where to find each plugin on-disk in the "allow" list and related trivia. Which had worked "OK" for some years. Enumeration methods based on VST 2.x. It looked like the enumeration would have had to be improved, and the format of stored "allowed" and "ignore" lists re-written to play nicely with shells such as Waves. So far as I recall about the matter, which isn't much. Think I recall that some failings were improved merely by building-in support for JBridge, but dunno if that involved (or improved) support for shells.

At the time I just wasn't in a good frame of mind to take on a heavy re-write of the hosting.

[Tale]

Any recommendations of tutorials/getting started with WDL-OL?

http://www.martin-finke.de/blog/tags/ma ... ugins.html