DiyLightAnimation

RJ,

It was answered more than once in Chat, I even stopped everyone jumping in and replying here as there was no need, I only replied so it was clear to any readers.

There has been too much crap (you know me straight talking) floating around and various people of been asked to either tone it down or stop it completely, ultimately we are all here for the promotion of Christmas lights.

As i said "the more the merrier"

Certainly anyone who did it seriously over the last six months has already learnt a lot of lessons and at times the enthusiasm to share some of those lessons may have been a bit over the top

Cheers Mate
Phil

These first three (fantom)channels would control the string like the String mode but the next 150 channels would control it as individual nodes. This way you could use them both ways. When the first three (fantom) channels are off then the 150 channels work as nodes and if you turn on the first 3 (fantom) channels then the string then is controlled as a string.

Wonder what the thoughts on this idea is? 

RJ

Really quite CCR like and straight forward.

Good luck - the one thing that has got me wondering is what is the magic IC in the pixels that allows you to run the string at 12V.

One thing you are spot on with is we will all have to take on the concepts around extreme channel count sequencing, i have 10,576 channels allocated in Vixen this year.

Phil

The iDMX sends the entire 512 channels...what is he talking about?

As per additional posts, i actually knew what i was talking about, the original firmware for the Tiger controllers followed the Microchip App note just a little to closely and looked for all 512 slots, this has since been resolved to be compliant to the DMX standard of supporting 1Hz to 800+Hz DMX refresh rates.

Cheers
Phil

I have looked DMX protocol in detail some a time ago and is extremely simple, no feedback, no error correction, just streaming frames of bits into the wire, I did a quick view for E1.31 and doesn’t looks it adds too much complexity.

At the beginning I thought implementing the protocol on the application, but the beauty of Vixen is all extra stuff which has around it, like the scheduler and a lot of other stuff.

Unless my application give all the other stuff, doesn’t make sense spend time to create something that exists already in Vixen since I can focus my time/effort on the front end and let Vixen drive the show.

When the app is completed and the queue of users requests is down to a reasonable level , I could focus on “possible” stage 2, which could be add protocol support.

But…, If Vixen doesn’t get updated for long time to support new protocols and RJ wants to use E1.31 then we have a need and priorities could change.

About RGB lights, I’m totally a newbie, but from what I have in mind, the handing of RGBs will be really transparent to the users in the application, the application will handle devices like the Aether and manage the 3 RGB channels independently internally, so in theory you could even choose the mixing of white you would like to see.

Cas.

Cas

Sorry, should read more, as dmc pointed out this is a front end to vixen. That is great then, no need to handle the underlying protocol support.

I would agree with your statements about "all the other stuff"

Vixen can handle the output of 4k-8k channels without any dramas but there is no way that you can work with that many in the interface and especially if they are RGB channels. I could personally have up to 8k channels this year.

So Vixen is too painful to use for large RGB counts and LSP can handle the sequencing but gets very slow to use once the counts go into this region.

What you are doing sounds like a great way to potentially sidestep some of these issues whilst still using vixen's output performance.

Vixen already supports E1.31 so no worries there.

I have long been a fan of the concept of object based sequencing and would love to actually have a play with what you are doing and see how it may work for very large RGB displays.

For any RGB object you should be able to select a start colour and end colour and even a middle colour then say change from start to end going through the middle colour if defined, setting the midpoint offset would be usefull as well. for say an RGB arch this could be colour at each end etc. For a RGB megatree, a starting point would be vertical string start colour, rotation direction, end string colour. or colour 1 to 2 and speed of change plus rotation speed. For pixel level this would also then include vertical fades. think of it as a matrix wrapped around a tree.

None of this is even vaguely easy in vixen.

I remain a fan of Vixen but it is impossible to do meaningful sequencing with large channel counts

Cheers
Phil

Rob,

thanks for picking this back up, i just ran out of time the last while and this dropped right of the radar.

the enclosure and all is still here, right beside me, just sheer lack of time finalizing my controllers and the firmware for them.

I will still finish my board as soon as i find time.

Cheers
Phil

David,

final got an account set up, this may be a little hard to co-ordinate with time differences, i'm available most evenings from 6pm to 1am Australian Eastern Time. over to you

thanks
Phil

Ryan

Short answer - no.

This gets more bizaar.................

Vixen has been sitting here for hours sending DMX via the Lynx Dongle to my controller yet i can't get LSP to work.

Cheers
Phil

Thought i would post this one here,

I've had LSP since the original beta release but never actually used it in anger last year.

Now with the current 1.5 release offering so much I can't seem to get DMX output working.

Windows 7 x64 with the correct FTDI drivers installed for the Lynx Dongle on COM3. Vixen outputs without issue.

I have set the output up in LSP to go to COM3 but nothing seems to be output.

Now i'm sure it's the dumb user, so can someone give me some clues?

Cheers
Phil