Is the Vixen UI extensible via the plugin (K.C.?)

[A Marchini]

Not being a .NET guru, I was curious, if a plugin could be made that can alter the main grid values, or hook the UI so they could be modified in real time.

Why? Well, I'm thinking the mutli-color LED thing, and not wanting to bother K.C. with a rewrite of the user interface, perhaps a plugin could be called while editing the main grid that could set the values of a group of 3 contiguous channels, thereby setting a color value in the standard grid.
It would be kludgy but it would work easier...

I haven't looked at the RGB plugin, I suppose I should. Just to see how colors are handled with it.

There could be other applications, where extending the UI without direct intervention of K.C. would be helpful to his time.

Tony M.

 

[KC]

The standard editor isn't terribly extensible at this point. New editors can be written, but that's also a lot of work for whoever does it. You can derive a new editor from the existing editors, but I'm sure that would introduce its own headaches and problems and probably wouldn't be worth it in the end.

The RGBLED add-in is a step towards what you want, it has a RGB calculator and color picker and lets you do gradients.

Other than all of that, an add-in has access to the sequence data.

 

[A Marchini]

The standard editor isn't terribly extensible at this point. New editors can be written, but that's also a lot of work for whoever does it. You can derive a new editor from the existing editors, but I'm sure that would introduce its own headaches and problems and probably wouldn't be worth it in the end.

The RGBLED add-in is a step towards what you want, it has a RGB calculator and color picker and lets you do gradients.

Other than all of that, an add-in has access to the sequence data.

Yeah, guess I actually should have looked at that plug-in. That is what I was talking about I guess.
Silly me... brain damage is a terrible thing.
T.m.


P.S. Is there a document of the ad ins spec?

 

[KC]

Crap, I don't know if there's anything left over from 1.1 to document that. I'll try to type up something this weekend to cover it, just in case.

 

[DynamoBen]

There could be other applications, where extending the UI without direct intervention of K.C. would be helpful to his time.

This is going to be more of an issue as we move forward. Between color mixing systems like the pixel and moving lights we will need live control, and multiple attribute control from a single "channel". However this all requires the ability to patch channels and dimmers. To be honest I thought this was years out but with the pixel its coming quicker than expected. :shock:

In the case of the pixel each pixel could be represented by one "channel"; within each channel are three attributes (red, blue, green). The user could select a color not unlike the RGB-LED add-in but this all would be integrated into the timeline/channel display.

 

[A Marchini]

There could be other applications, where extending the UI without direct intervention of K.C. would be helpful to his time.

This is going to be more of an issue as we move forward. Between color mixing systems like the pixel and moving lights we will need live control, and multiple attribute control from a single "channel". However this all requires the ability to patch channels and dimmers. To be honest I thought this was years out but with the pixel its coming quicker than expected. :shock:

In the case of the pixel each pixel could be represented by one "channel"; within each channel are three attributes (red, blue, green). The user could select a color not unlike the RGB-LED add-in but this all would be integrated into the timeline/channel display.

I wonder if we can get there from here. If the max range of a singled array element in the vixen channel was extended from byte range of 256 values to a 32 bit value, then we would have all kinds of extra encoding for plugins to do their individual magic (even though the ability of vixen to display the output wouldn't be up to the task).

I suppose what I was thinking of extensibilty would be for the grid control (whatever they are called in this programming parlance) to call into a routine of the plugin (some external call), the plugin could interpret the cell information (passed to it) and return a record of values for that cell which could override vixens (color, intensity...height?).
If the plugin function is Null, vixen works like it always did. If it isn't then the plugin can modify based on its own specific needs (color intensity).

So the low 3 bytes of the 32 bit value could be interpreted as a color value.

The plugin could re-interpret the information any way it wants, since it is in charge of controlling the end device.
So if you had a controller with built in twinkle then an encoding in the vixen cell could be created (perhaps in the high byte) that would just be, Twinkle start command.
This saves the CPU or vixen from creating this special effect in its own code. The plugin/controller would be in charge of this.

The question is if such a hook can exist dynamically, with other hooks (perhaps a linked list) and if the grid display can link them all in real time without crushing the visual output.

If the user had multiple plugins at one time (595, Renard and DMX simultaneously) then the rastering through the indivual plugins, could be an issue.

Granted they could be cached.

Anyways, that was what I was thinking.

Tony M.

P.S.
Alternatively, just creating a mapping would work. Even though it seriously takes the dynamic element out of it. It is the old concept of a pallet set, which would allow the byte to output 3 color information but only in 256 variations.