Plugin SDK V4

[c0nnex]

Hi,

I had a look at the Plugin SDK V4.

While I like the new possibilities, i really dislike the decision to go for dynamic instead of interface.
Using dynamics makes development a very lengthy and hard process, since there is no way to check the code before actually executing the plugin.

What's wrong about providing the interface in a separate assembly, that can be referenced (Copy Local=false) by the plugin?
Interface changes often? No problem, just number them (IVoiceAttackSDK2) or version them ( Version CurrentSDKVersion; .... Version VA_GetSupportedSDKVersion() .... )
Maybe even make the SDK-Interface pensource on GtHub, that way it's easy to write documentation for it...

Also I was wondering if it is safe to keep a reference to vaProxy and call ExecuteCommand asynchronously.
My users requested, that the application can trigger VA-Commands. So plugin is communicating with my app in a separate thread and would need to raise ExecuteCommand on several events. Possible?

-Ulrich

[Gary]

What's wrong about providing the interface in a separate assembly, that can be referenced (Copy Local=false) by the plugin?

I agree that development is a little bit more lengthy.  I started with an interface (short and sweet) and I decided that I didn't want to do that as it requires a separate dll (for me and you).  This may change later, however.  The good news is there are few properties/methods in vaProxy.

Also I was wondering if it is safe to keep a reference to vaProxy and call ExecuteCommand asynchronously.
My users requested, that the application can trigger VA-Commands. So plugin is communicating with my app in a separate thread and would need to raise ExecuteCommand on several events. Possible?

There is an error in the documentation (you have pointed this out just now).  ExecuteCommand should really look like this:

ExecuteCommand(String CommandName, optional Boolean WaitForReturn)

The default for WaitForReturn is false.  Setting the value to true will cause the function to wait until the command completes.  I'll update the doc now.

You're going to have to experiment with what's available.  I've created a plugin that loops on init, constantly executing commands in VA, at the same time it is consistently receiving commands through invoke which then set variables, call commands and then write to the log.  It seems safe

[c0nnex]

What's wrong about providing the interface in a separate assembly, that can be referenced (Copy Local=false) by the plugin?

I started with that and I decided that I don't want to do that as it requires a separate dll (for me and you).  This could change later, however.

If you fear managing another dll , just provide the source of the interface file to the sdk and keep it in your main exe ...

Also I was wondering if it is safe to keep a reference to vaProxy and call ExecuteCommand asynchronously.
My users requested, that the application can trigger VA-Commands. So plugin is communicating with my app in a separate thread and would need to raise ExecuteCommand on several events. Possible?

There is an error in the documentation (you have pointed this out just now).  ExecuteCommand should really look like this:

ExecuteCommand(String CommandName, optional Boolean WaitForReturn)

The default for WaitForReturn is false.  Setting the value to true will cause the function to wait until the command completes.  I'll update the doc now.

hehe nice, but does not answer my question

1) VA_Init1 -> I start a new thread  , giving vaProxy as argument to that thread, who stores it for later use.
2) Thread is waiting for a signal from outside VA (eg. a named waithandle  signaled).
3) If signal received, thread issues vaProxy (stored value) -> ExecuteCommand(...)

is it safe to store that reference to vaProxy and use it in that other thread? Or might it happen that vaProxy becomes invalid?

[Gary]

1) VA_Init1 -> I start a new thread  , giving vaProxy as argument to that thread, who stores it for later use.
2) Thread is waiting for a signal from outside VA (eg. a named waithandle  signaled).
3) If signal received, thread issues vaProxy (stored value) -> ExecuteCommand(...)

I'm thinking it will be fine, as the init mentioned in my previous message holds on to a reference to vaProxy indefinitely (running in a thread).

[c0nnex]

seems to work fine, however I found a major drawback with the vaProxy.

To ease the use of my plugin, users where giving names of values to query from my app in the decimals-Dictionary.
The plugin then just looped through all the dictionary-keys and knew which values to query.

That's not possible anymore now

I tried if i can mix V4 and V3 , but that does not work. (V4 VA_Init1 , V3 VA_Invoke1) :

VA hard crashes with NullReferenceException after an obviously caught
AmbiguousMatchException: if plugin provides both V3 & V4 VA_Invoke1
TargetParameterCountException: If plugin provides V3 VA_Invoke1 but V4 VA_Init1

That's what you get for not using interfaces 

I will have to think of a new way to pass on the values to my plugin (and making it more complicated to use). Checking all possible values is not an option ( over 15,000 )...

[Gary]

I could send the vaProxy down as part of the state dictionary in v3, v2 and v1 .  That should allow you to keep that method you are using and give you the benefit of having a vaProxy.  You would just need to typecast it as dynamic.  I'll know for sure later as I'll be away until later this afternoon.

[Antaniserse]

seems to work fine, however I found a major drawback with the vaProxy.

To ease the use of my plugin, users where giving names of values to query from my app in the decimals-Dictionary.
The plugin then just looped through all the dictionary-keys and knew which values to query.

That's not possible anymore now
[...]
I will have to think of a new way to pass on the values to my plugin (and making it more complicated to use). Checking all possible values is not an option ( over 15,000 )...

I have something similar in mine, where the user could provide an unknown number of small int values, and the plugin would simply get all from the dictionary, without needing to know the names... one simple workaround, which may or may not work in your case, depending on the way you process these, is to have the user put your variable names into a single VA text variable

Code: [Select]

Set Text [DecimalQuery] to "Var1;Var2;Var13;Var25"
And the parse the string in your plugin code to obtain the keys for Get/SetDecimal()

[c0nnex]

I have something similar in mine, where the user could provide an unknown number of small int values, and the plugin would simply get all from the dictionary, without needing to know the names... one simple workaround, which may or may not work in your case, depending on the way you process these, is to have the user put your variable names into a single VA text variable

Code: [Select]

Set Text [DecimalQuery] to "Var1;Var2;Var13;Var25"
And the parse the string into your plugin code to obtain the keys for GetDecimal()

Thought about that as well, but opens up too many sources for failures .. (the var names are quite complicated and contain special chars (:,!,,) . Need to keep stuff simple, i have no time to support "wrongly typed command-sequences in VA")
Also i don't want to change geneal mimic of the plugin. No joy to get the s#|+storm if the users have to reprogram all their stuff (<- learned not to do any major changes the very hard way ..)

For now I will go for 2 Plugins:

One using V4 which does just the way App->VA (ExecuteCommand)
One using V3 which does all the VA->App stuff, to be able to use Dictionaries still

[c0nnex]

Work fine so far ...

Only problem is that I cannot give the sequence of the plugins to make sure V4 is loaded before V3 and unloaded after V3.

[Gary]

There's no guarantee of execution order for plugins.

Why don't you let me update the v3 interface with the proxy and see if that works?  I should have something in order by this evening if all goes as planned.

[c0nnex]

Hehe no stress...

If you update to pass on the vaProxy i'll check it out for sure and strip down my plugin again.

[Gary]

I popped a new build out in the, 'unofficial' bin:  http://www.voiceattack.com/unofficial

To access the proxy obect:

dynamic dx = state["VA_PROXY"];

The proxy is only available in the invoke and init.


Sorry for the short reply... I've got errands to run

[Gary]

Went ahead and made a beta package out of the change:  http://www.voiceattack.com/beta

[c0nnex]

Works like a charm.
Thanks!

[Hollywood_315]

Started working on a plugin recently and now updated my WIP for the v4 / vaProxy thing.
I must say it works like a charm so far: much cleaner and more flexible 2-way interaction.
Thumbs up!