PDA

View Full Version : Source code for plugins?



sallz0r
08-13-2008, 01:10 AM
Hi,

I've started developing a plugin for vixen for my own custom controller boards that I'm making, however I'm curious about a few things. I've had a look at the parallel port driver that has source code available, but I was wondering if there any any others that have code available? I saw on this thread that others have said that there's no other source code available, but just thought I'd check again. :-)

Also, is Vixen closed-source? Because it was free I somehow got it in my head that it was under some open-source license, but it would appear not. I'm not sure who the owner/maintainer is (ie. who I should be talking to), but I had a few features that I thought would be handy that I'm happy to implement (and release back to the community), just couldn't find the source code. :-)

Anyway, thanks for any help anyone can give.

Cheers!
Michael

Virtus
08-13-2008, 08:37 AM
Michael,
KC is the forum member who writes, owns, and maintains the code. He is always seeking feedback so be sure to post your ideas in the Vixen Change Requests thread. That way the community can post support (or dismay, too, I guess :p) at the proposed change.

A Marchini
08-13-2008, 10:58 AM
Hi,

I've started developing a plugin for vixen for my own custom controller boards that I'm making, however I'm curious about a few things. I've had a look at the parallel port driver that has source code available, but I was wondering if there any any others that have code available? I saw on this thread that others have said that there's no other source code available, but just thought I'd check again. :-)

Also, is Vixen closed-source? Because it was free I somehow got it in my head that it was under some open-source license, but it would appear not. I'm not sure who the owner/maintainer is (ie. who I should be talking to), but I had a few features that I thought would be handy that I'm happy to implement (and release back to the community), just couldn't find the source code. :-)

Anyway, thanks for any help anyone can give.

Cheers!
Michael

There was plenty of source code around for a few of the different plugins. There wouldn't be much point of having a discussion forum about plugin development if we couldn't publish the code.
There are some "howtos" around here somewhere... basically how to setup the plugin project and things like that. I am sure there is code around here too. If not I can set you up.

The main body of the code is closed, but the plugins were open last I checked.

Unless something has changed, and if it has, then I guess its time to remove this forum.

I have enclosed a pre-lim document describing the class structure. The big things to get going are the Initialize and Event.
Event gets passed in to your channel set (I believe only the channels your plug in is assigned) at refresh intervals described by the vixen programming grid.

I think there is some starting code for serial stuff around as well... I will never get to it but I have been trying to create a generic binary FTDI usb interface so that people without parallel ports can still play (after using a usb to digital converter ... like this http://www.ftdichip.com/Products/EvaluationKits/UM245R.htm) with their 595 boards and such.

Anyways,
...hi?
Tony M.

PS.
This thread should be handy, talks about some template code for triggers I think
http://doityourselfchristmas.com/forums/showthread.php?t=1597

P. Short
08-13-2008, 06:41 PM
There is software out there on the net that you can use to de-compile the existing plugins. If you're using the FTDI chips (either serial or parallel) they end up in the simplest case (and maybe the only case, I don't know) looking like a serial port to the plugin code. So you treat it exactly the same way that you would treat an-style RS232 COMn: port.

In any case, that document that Tony wrote is a good starting point.

sallz0r
08-15-2008, 12:47 AM
He is always seeking feedback so be sure to post your ideas in the Vixen Change Requests thread. That way the community can post support (or dismay, too, I guess :p) at the proposed change.

Aah, ok. Yeah, I might just end up doing that -- I just wasn't sure if the software was open at all, since that way I could do it myself -- I hate pestering other people for help/support/features. :-)

Cheers,
Michael

sallz0r
08-15-2008, 12:54 AM
There was plenty of source code around for a few of the different plugins. There wouldn't be much point of having a discussion forum about plugin development if we couldn't publish the code.

Aah, excellent. I had a quick look and couldn't see too much available, but I didn't dig too deep. Now that I know there's stuff around I'll poke through it all more thoroughly. :-)


There are some "howtos" around here somewhere... basically how to setup the plugin project and things like that. I am sure there is code around here too. If not I can set you up.

The main body of the code is closed, but the plugins were open last I checked.

Cool -- I was initially worried when it was only the example parallel port driver that was available, but it looks like I need not worry. :-)

Any idea why Vixen is closed source? I'm not complaining, please don't get me wrong, I just usually associate software that's free and having such a good support community with being open-source.


I have enclosed a pre-lim document describing the class structure. The big things to get going are the Initialize and Event.
Event gets passed in to your channel set (I believe only the channels your plug in is assigned) at refresh intervals described by the vixen programming grid.

Wow -- that's really great! Thanks for that -- it helps having the API around, or just something to know how it all fits together. :-)


Anyways,
...hi?
Tony M.

Eek, I must apologise -- I set this thread to "subscribe", visited when there was one reply, and never got any more emails, so I assumed it wasn't getting replies! Why it didn't clear the "visited" flag, I'm not sure..... anyway, so I apologise for the delay in replying.

sallz0r
08-15-2008, 03:00 AM
I have enclosed a pre-lim document describing the class structure. The big things to get going are the Initialize and Event.
Event gets passed in to your channel set (I believe only the channels your plug in is assigned) at refresh intervals described by the vixen programming grid.

Hrm, quick question about that -- is the Event function called for *every* time slice (ie. every 100ms, or 50ms, etc.) -- and when it is called, is it fully populated with all channels?

Basically, I'm trying to figure out if it's smart about it at all -- ie. not calling it for time slices when nothing changes, or only sending events for channels where something has changed.

Cheers!
Michael

A Marchini
08-18-2008, 01:18 AM
Hrm, quick question about that -- is the Event function called for *every* time slice (ie. every 100ms, or 50ms, etc.) -- and when it is called, is it fully populated with all channels?

Basically, I'm trying to figure out if it's smart about it at all -- ie. not calling it for time slices when nothing changes, or only sending events for channels where something has changed.

Cheers!
Michael

That is a real good question. I am not sure at this moment. I was hoping that some of the other players in the software realm would pipe up at this point.
I think that the list is only populated with the channels that you select for the control,but I also believe that it sends data to the control on the event time, no matter what.

Again I am not too sure. A PM to KC to ask that he weigh in on the site may help here.
He could answer these two questions in about a half second.

KC
08-27-2008, 10:48 AM
Sorry it took so long to reply! Been moving.


Hrm, quick question about that -- is the Event function called for *every* time slice (ie. every 100ms, or 50ms, etc.) -- and when it is called, is it fully populated with all channels?

Basically, I'm trying to figure out if it's smart about it at all -- ie. not calling it for time slices when nothing changes, or only sending events for channels where something has changed.

The Event method is called whenever there is a change in the state of the channel values. With each call, the method receives the data for every channel that's being sent to that plugin.

sallz0r
08-29-2008, 03:46 AM
There was plenty of source code around for a few of the different plugins. There wouldn't be much point of having a discussion forum about plugin development if we couldn't publish the code.

Hrm, is anyone able to point me in the direction of said code for output plugins? I had a dig through the rest of the forum, and have found a few snippets and example chunks of code for some things, but I haven't found anywhere that has the code for any of the actual production plugins that are used in vixen (ie. fully implemented ones, that do stuff from start to end).

Does anyone know if these are available anywhere? The documentation provided by A Marchini is great, as well as the sample things that are floating around, but I just wanted to analyze what some of the "real" plugins did. :-)

Thanks to all!

Cheers,
Michael

sallz0r
08-29-2008, 03:54 AM
Sorry it took so long to reply! Been moving.

No worries - moving's great fun! gives you a chance to clean up and organize stuff. ;-)


The Event method is called whenever there is a change in the state of the channel values. With each call, the method receives the data for every channel that's being sent to that plugin.

so what constitutes a "change of state"? Is that any change of time slice, or only when a channel has changed value between one time slice to another? (I would presume the latter, just wanted to double check).

I'm working on a plugin that more effectively uses the serial bandwidth, to give a high max. channel count -- ie. only sending changed values rather than ALL channels, irrespective of if they've changed. This way, given an average sequence, you can control far more lights than you normally would... I'm guesstimating ~500 channels, at 115200, at 25ms. Hopefully. :-)

Thanks all!
Cheers,
Michael

RavingLunatic
08-29-2008, 09:14 AM
I'm working on a plugin that more effectively uses the serial bandwidth, to give a high max. channel count -- ie. only sending changed values rather than ALL channels, irrespective of if they've changed. This way, given an average sequence, you can control far more lights than you normally would... I'm guesstimating ~500 channels, at 115200, at 25ms. Hopefully.


Not to discourage innovation, but some questions:

1) Wouldn't your idea fail to perform correctly each time you wanted to change more channels than the baud rate could handle? Seems to me that someone trying to use a large channel count of ~500 channels (at 115200 and 25ms) at some point might want to change over 288 at once.

2) To make this work, wouldn't each channel need to be individually addressable? What hardware have you developed to do that? Wouldn't you lose some of the advantage you gain with your new plug-in by having to also send channel addresses also?

sallz0r
08-29-2008, 10:57 AM
Not to discourage innovation, but some questions:

1) Wouldn't your idea fail to perform correctly each time you wanted to change more channels than the baud rate could handle? Seems to me that someone trying to use a large channel count of ~500 channels (at 115200 and 25ms) at some point might want to change over 288 at once.

Yes, exactly. Ideally, it wouldn't matter if they wanted to do that, it would just queue the extra changes. If it can only handle 288 changes per 25ms time slice (in reality, it's only about 240, I think) then any more than that will just be "queued" until the next 25ms time slice. If you're permanently changing more than 250 channels *every* 25ms, then it won't work; at least, not without a great deal of lag. Is that a problem? I don't think so. It doesn't make it any *worse* than (what I assume is) the standard approach at the moment, and instead applies a bit of dumb intelligence to minimize the amount of data that's being transmitted. This should, allow more channels with a fixed amount of bandwidth considering typical usage cases.


2) To make this work, wouldn't each channel need to be individually addressable? What hardware have you developed to do that? Wouldn't you lose some of the advantage you gain with your new plug-in by having to also send channel addresses also?

Yep, which is why it's ~240 channels instead of 288 maximum per time slice. I haven't decided on the exact data format yet, but a bit of simple logic on the micro on the other end will decode the addressing structure, and make optimal use of bandwidth.

Thanks for the questions; I appreciate what you're asking, and if you want more info please ask. At the moment, I'm more concerned about the electrical and environmental aspects of it, as I'm an embedded/digital developer by trade, so that all comes naturally, but the other stuff (like if I'm going to be able to successfully run 115200 over RS485 in my environment) is what concerns me most. We'll soon see! :-)

Cheers all,
Michael

RJ
08-29-2008, 05:35 PM
Since many of us are running 512 channels at 25ms using 250,000 (DMX) over RS485 why would that be a challenge? Unless you are in a abnormally bad enviroment like a power station yard. Of course this would have it's benifits also, No power problems. LOL

RJ

tconley
08-29-2008, 08:35 PM
also coulnt you simply break the display up into several DMX universes each with 256. Wouldnt that resolve the issue.

sallz0r
08-29-2008, 10:26 PM
Since many of us are running 512 channels at 25ms using 250,000 (DMX) over RS485 why would that be a challenge? Unless you are in a abnormally bad enviroment like a power station yard. Of course this would have it's benifits also, No power problems. LOL

RJ

Heh, I didn't realize what other people were running; if that works, then I'm less worried. I was just going to wait and see how high I could push it. :-)

My cause for concern was that I noticed a lot of the others were commonly using 57600; I was thinking there might be some reason for this, or other people have found issues pushing it that high. *shrug* I'll find out soon enough. :-)

sallz0r
08-29-2008, 10:52 PM
also coulnt you simply break the display up into several DMX universes each with 256. Wouldnt that resolve the issue.

Yeap, I could; I was just trying to see how efficiently I could use the available bandwidth. :-) This year I think I've only got ~270 channels, so it's not really an issue for me..... I just overengineer things, and try to make it the fastest/most efficient/best, etc.... :-)

Cheers,
Michael

JonathonReinhart
05-04-2009, 03:41 AM
Hey, hate to dig up terribly old threads, but I'm looking for the same thing. On http://doityourselfchristmas.com/wiki/index.php?title=Vixen_Plugin_Development it refers to the downloads page for the sourcecode to the Parallel12 plugin, for example's sake. But it no longer appears to be on there. Is this sourcecode still available?

I've been tinkering with C# DLL development, and like sallz0r, I would love to see a complete plug-in's code. Is this, or say the renard plugin code available? I guess I could always PM phil to ask him.

Thanks,
Jonathon

cbell
05-04-2009, 08:48 AM
Is this sourcecode still available?


The source can be found at http://www.vixenlights.com/files/

Check this recent thread for more information.

http://www.doityourselfchristmas.com/forums/showthread.php?t=6798

There is an excellent tutorial written by A Marchini in that thread on how to start writing a plugin in either Visual Studio or SharpDevelop.