Forum

C# Plugin Interface 2.0 Suggestions

vvvv beta general
#1

I dont know the source of the Plugin Interface in detail, because I am very new in developing plugins for vvvv via C# but there are some things I recognized, that may be improved. I dont know how hard they are to be realized, but I just want to list some things.

  • Values of Pin Inputs can be passed via Return Value and not as out reference (would save a lot of lines of code an variable declaration) Instead of {CODE(ln=>2)}double tValue;^ {CODE(ln=>2)}FInputPin.GetValue(OnDevice, out tValue);^ you can pass it like this {CODE(ln=>2)}double tValue = FInputPin.GetValue(OnDevice)^

  • Another thing is how to make the edges typesafe without developing a lot of new interfaces for each new edge type the user want to use. Instead of declaring the type of an input via {CODE(ln=>2)}private IValueIn FSomeInput^ and creating the input via the Host method **{CODE(ln=>2)}FHost.CreateValueInput(…^**I would suggest to use Generics for the type safety for an edge, maybe like {CODE(ln=>2)}private INodeIn FSomeInput^ in combination with the creation **{CODE(ln=>2)}FHost.CreateInput<“double”>(… (" excluded)^**This would reduce the amount of needed interfaces and in addition, the users can define their own edge types on the fly without creating a new interface. I know the parameter list depends on the edgetype, but it should just be a first hint, in which direction it could go.

  • Another thing I recognized was the creation of the EnumInputs, actually they are no enums, they are arrays of strings. This is always risky, because of the fact, that you have to compare strings all the time in you plugin, and this is always a risk for spelling mistakes, so why not passing a real enum and use Reflections for reading the enum values to create the input strings. Of course, we would have to handle how the selected enum value could be passed to the user in the evaluate loop.

As I said, I got no detailed background knowledge about the Plugin Interface framework, because I didnt got the time for a detailed view. All these things just should be suggestions to give you guys my view on the items, that might be improved.

Sometimes, a foreign eye on the code might see things, that a developer, who wrote the code cant see, I made those experiences on my own a lot of times.

CYA

#2

hi chrismo,

joreg can probably tell you more about this, but still, here are my two cents…

passing via return value:
this could of course easily be done. reason why it is how it is might be the tiny little performance increase by passing it by reference?
moving a double (64bit) needs two calls instead of the one call moving only the reference to it…but i must admit, i don’t think one would notice any difference in performance.

generics:
i’d love to use generics! there is a reason however, why they can’t be used:
the plugin runs in a managed environment, vvvv not. the communication between vvvv and the plugin is done via COM and to my knowledge there is no way to tell COM how to handle generic interfaces.

enum pins:
i’m always using the GetOrd(int slice, int ord) method provided by the enum pins. this way i don’t need to compare strings and can compare integers.

#3

joreg told me already, that the return value is already in the pipeline for the 2.0 version.

it is a pitty, if we it is not possible by design to use generics.

even if you use GetOrd (I used it too) enums are still better for the visual aspect of the code, it is much more readable than integers.

but thx for your comments, lets collect suggesstions…

#4

Here are a “few” more suggestions :)

Color/Tranform Pins to have getvaluepointer, as the structs got the proper layout we could simply do a Marshal.Copy which would increase performances a lot (metionned that one i think)

Allow gui plugins to add/delete pins on the fly (so we could have nice scripting editors like shader ones).

Change the value in subtype. Can’t be a bang and toggle as same time, so replace by an enum (Number,Toggle,Bang)

Replace the isfilename bool by an enum in string subtype (so we could have String,Filename,Directory…)

Dynamically register a plugin in vvvv via the host (would be great for code generators), or force the host to rescan for externals.

#5

Ok, quick one from the chat with joreg yesterday. Don’t know if some are worth fixing in the v1. And couples extra.

1/Abstract classes implementing IPlugin should not appear in the node list.
(t.IsAbstract from type class does the check).

2/Class inheriting from abstract plugin but which doesn’t implement it explicitely are not shown:

public abstract class CoolAbstractNode : IPlugin

public class CoolNodeButIWontAppearInTheList : CoolAbstractNode

public class CoolNodeAppearInTheList : CoolAbstractNode,IPlugin

As we inherit from a plugin, we implement the interface (t.IsAssignableFrom does the job on this one).

3/Empty strings appear as null in vvvv, so:

string s1,s2;
FStringPin1.GetSlice(0, out s1);
FStringPin2.GetSlice(0, out s2);

string smerge = s1 + s2;

will crash if either one of those is empty in the ui.

string s1,s2;
FStringPin1.GetSlice(0, out s1);
FStringPin2.GetSlice(0, out s2);

s1=s1 != null ? s1 : String.Empty;
s2=s2 != null ? s2 : String.Empty;

string smerge = s1 + s2;

works, just a bit annoying to remember to add that each time i have a string pin :)

4/Any OutputPin interface to have SliceCount property Read/Write. Avoids to store a local variable for every pin i want to keep track.

#6

An other sugestion : i want mesh input! please…

© vvvv group