C# wrapper

[tonyvfish]

I see that the header file(s) have been ported to Delphi, just wondering if the same thing is possible for .Net / C#. I can of course translate the header .into c#, but is that enough, or would it need a unmanaged wrapper C that call a managed one ?
TIA

[domportera]

I would love if a proper C#/.NET wrapper was available.

If the GC really is a deal breaker (imo it probably shouldnt be since you can still minimize GC), Bb exists, and the "Zero" version doesn't even have a GC

[tonyvfish]

I wasn't aware of BB, that looks really interesting. As you say the GC can be suppressed or has low latency modes. I built a small DAW using https://github.com/obiwanjacobi/vst.net and did not experience GC issues ?

I've been looking at Avalonia where you can easily build cross platform UIs too. Just wondering if you need the managed stub to make the Clap plugin?

[abique]

Did you consider writing the engine in C/C++/Rust and then run the GUI in a child process which you can write in C#?

[abique]

As a side note, Bitwig Studio is written in Java, and its audio engine in C++.
They both run in different processes.

[baconpaul]

yeah the managed program is sort of a window viewer on the unmanaged audio engine. makes debugging a dream too!

[baconpaul]

(like seriously; you can restart your plugin engine without resetting your entire ui state)

[tonyvfish]

I suppose what I was getting at without looking to deeply at the API is, when the vsthost calls a plugin it's must expect at least one entry point in the plugin dll to be invoked? Does that entry point have to be defined in an unmanaged language?

[tonyvfish]

I've just had a look at the docs and I can see just one entry point, export symbol is required and I also came across this https://sites.google.com/site/robertgiesecke/Home/uploads/unmanagedexports which you create C dll style exports from . Net. Thank you all for your suggestions and advice about managed garbage collected languages. Actually the GC is very sophisticated now, you can suppress it entirely or put it into a low latency mode, so I may give that a go, or as someone else advised use
Bb https://flattened.net/ the unmanaged version of c#, either way you have provided me lots of options, thank you

[domportera]

BEEF could be a really excellent alternative to C# for this kind of thing - quality of life improvements of C# with no JIT/GC and out-of-the-box simple interop with C and C++.

[abique]

There seem to be a new language every month these days.

[abique]

Interesting.

[domportera]

for real. this one has been around for some time now and seems pretty ready for real work. it's a shame it's not supported by any IDEs but it has its own at least. why someone would bother making their own IDE for this is beyond me, but it seems like a worthwhile project

[tonyvfish]

I'm currently working on a basic c# version of a plugin using .Net7 . You can do some great things now regarding interop and GC https://github.com/AaronRobinsonMSFT/DNNE

[domportera]

how is it that you're using this repo? what's your general architecture?

[tonyvfish]

how is it that you're using this repo? what's your general architecture?

Sorry for the late reply, I have currently been using this project as a reference for the types i need to create in C#
The idea is to convert this example plugin by Moss
Moss Example Plugin into C#
The aim is to pass all the CLAP validation that Moss's plugin does

To help me do the basic Marshalling Interop i've used this project
interop asisstant

And to create the entry points in the C# i've used this
ProtoTypeExports

The ideas is the main C# .Net project is invoked from an unmanaged stub dll plugin. This is because DNNE ProtoTypeExports, support export functions and not a single entry point variable structure.
This first C# project does the marshalling and works with pointers etc, almost a pseudo C project. This project will be the C# CLAP plugin framework. A consumer will make reference to this project and will create a plugin discoverable by the C# CLAP plugin framework.
The framework will then delegate its calls in a safe way to the users plugin

In this way the Plugin implementer will we working with interfaces and will not have to concern themselves with pointer or marshalling
I am currently at the stage of passing the CLAP validator test
I need to then do some dog fooding and make a real example plugin.
I will post ASAP

As abique mentioned , this does not necessarily mean a managed language is the correct thing to do a plugin in. It suitability will depend on the purpose and the user control of garbage collection and being aware of efficient operations like Span ans Memory

[baconpaul]

the clap-saw-demo at https://github.com/surge-synthesizer/clap-saw-demo is a pretty robust micro synth which uses the clap api directly and may be a useful next port if you are looking for examples; It supports polymod, note expressions, and so on.

[tonyvfish]

the clap-saw-demo at https://github.com/surge-synthesizer/clap-saw-demo is a pretty robust micro synth which uses the clap api directly and may be a useful next port if you are looking for examples; It supports polymod, note expressions, and so on.

wow thank you Paul

[atsushieno]

You might want to reach people behind NPlug project (https://github.com/xoofx/NPlug , https://elk.zone/g0v.social/@[email protected]/109978124900894558 )

I had very similar arguments to this thread there.