Current state of using C++ code for dynamic plugins?

devvvv

#1

Hey everybody,

I have to develop a custom plugin for VVVV that will have to use some C++ code. I’m really bound to C++ there due to third-party-libraries. I found a couple of posts about using C++ in VVVV plugins but the most recent ones were from 2011. So, basically I just wanted to ask what the current state is, what are my options and are there any examples available demonstrating how to call C++ code from within a VVVV plugin.
Thank you very much in advance!


#2

Go on, do that FLEX thing, we’re all trepidating in anticipation, I’m curious to hear about c++ in v++++ so I’ll grab some pop corn, heckle the husher, force my way past vegetarians with echoes of “don’t you know who I eat”, and wait for the puppet show to unfold. Good luck, broskerone.


#3

@digitalwannabe has been using c++ libs in his contributions, source code is open


#4

C++/CLI is your thing. It mixes the awesome of .NET and the awesome of C++. I found this guide massively useful while developing FBX4V https://manski.net/2011/04/cpp-cli-cheat-sheet/ . Your header file will look like this:

using namespace System::ComponentModel::Composition;
using namespace VVVV::PluginInterfaces::V1;
using namespace VVVV::PluginInterfaces::V2;

namespace VVVV {
    namespace Nodes {
        [PluginInfo(Name = "MyNode", Category = "Category")]
        public ref class MyGreatNode : IPluginEvaluate, IDisposable
        {
        public:
            [Input("MyPin", DefaultString = "yolo")]
            Pin<String^>^ FIOSettings;

            virtual void Evaluate(int SpreadMax);

            [ImportingConstructor()]
            MyGreatNode(IPluginHost^ host) { }

            ~MyGreatNode() { }
        }
    }
}

Note IDiffSpread has some problems with IsChanged so if you want that I suggest using Pin instead and MyPin.Stream.Changed. You can have both native and managed types in a class or whatever basically.


#5

@BlurEffect @velcrome I have used PInvoke so far to make c++ code run in vvvv. You will have to create an unmanaged c++ dll, which exports some methods and a managed dll-your node- to import and call these functions. As @velcrome pointed out you can find all that code on my github, but handle with care, “learned” most of this on stack overflow ;)

Plus: all my plugins share simple types only- (arrays of) strings, ints, floats - these are easy to marshal (copy from unmanaged to managed memory)- gets much harder/uglier for special types/structs…that’s not the only reason why microdee’s option is much sexier and in case of eg flex SHOULD be used… @BlurEffect if you are actually working on flex, hit me up, i’m looking into that too…


#6

i recently used a c++/cli node as microdee shows as a pure wrapper for an unmanaged cpp class. the cli node just holds a pointer of the unmanaged class. this way i can avoid pinvoke and still make use of simd/avx and all these goodies. additionally the unmanaged class itself is no tied to vvvv at all.

was thinking that it should actually be possible to create a plugininterfacecpp to circumvent the .net world completely, but i haven’t had time to dive into that. in the end it think it’s just COM interfaces to v4 delphi

first i’m trying to find the time to post a clean cpp template.


#7

so just moments later here comes an example for a c++ plugin
2d and 3d fluids used as reference to test the GPU version of the node17 visuals against

a standard visual studio c++/cli project:

  • base classes are set to compiled without CLI support for SIMD instructions (extra setting per .cpp)
  • c++/cli classes for the vvvv nodes
  • wrapper classes which hold a pointer to the unmanaged base classes to bridge between managed and unmanaged
  • release mode build: disable security checks, enabled enhanced instruction set (avx2), floating point model fast
  • a c# project for the vvvv plugininterface dependencies, excluded from build, just for pulling the nugets

i ran some test with large arrays and nonlinear access in unmanaged c++ is substantially faster than in c#. and nonlinear already means not looping from 0 to length of array but skipping a few. note that this doesn’t apply once you compile with CLI. and as to be expected using avx to process 8 floats in parallel nearly increases performance by factor 8 on top.

an thoughts and hints on improvement welcome.


#8

FANTASTIC @woei thank you!


#9

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.