Just hoping for some info (and maybe a nice discussion)
I'm about to design for a project, containing a large amount of LED-Tiles. 27 Tiles, each with four seperate RGB-facets (4*3=12 channels per panel).
They want me to create some images, and some effects on it (banners, color-waves, sparkling sky)
I was just wondering how to incorporate this in my show on a Pearl.
the tiles don't have a seperate dimmer function, so dimming should be done by fading RGB.
Here are my options:
*) patch 4*27=108 generic RGB fixtures (easy programming, but I need about 23 moving lights as well)
*) create a single fixture that holds 4*RGB (only 27 fixtures, but programming is a pain in the ass
*) get a media-server like pixeldrive and controll it with a pearl
Here are the questions:
*)Will it fit on a pearl, is the 120moving-light-limit still there, or can I go to 240 using the avo-key?
*)should I patch HTP or LTP RGB-fixtures?
*)will a pearl handle the massive amount of data created by led (WHIII's DP2000 can only handle 2 of 4 universes when controlling led)
*)should I just get a media-server??
thanx in advance
Large amounts of LED on pearl
Moderator: Moderators
Looks like you are facing the same problem I am with Pulsar ChromaPanels. Damn you Pulsar!
I think whichever way you go, you will have a nightmare programming.
After much experimenting I went with personalities containing RGB as HTP channels. The main reason for HTP was it gave the ability to merge colours from chases etc. I then store commonly used colours as HTP palettes for 'easier' programming, but it is still a big headache!
Another reason for going with single RGB in a personality is that you can make use of shape gen, which might make all the difference.
I'm sure the Pearl can handle it if you can!
(AFAIK there is no restriction as to intelligents/dimmers re the 240 handles, but I may be wrong.)
Incidentally the implementation of dimmer channels was an interesting topic at Plasa this year. There seems to be a 50/50 split as to whether it is desk manufacturer responsibility (ie. virtual dimmer) or fixture manufacturer responsibility. Understandable, but very annoying. I have been campaingning for Pulsar to implement this for over a year now and spent an hour of heavy discussion at the show but seemed to get nowhere.
One of their main counter-arguments was that noone else had told them this was a problem. At their request I started a poll on Blueroom forum which with one exception (oddly) was 100% in favour of dimmer channel implementation.
I would be interested to hear from anyone else experiencing the problem.
I think whichever way you go, you will have a nightmare programming.
After much experimenting I went with personalities containing RGB as HTP channels. The main reason for HTP was it gave the ability to merge colours from chases etc. I then store commonly used colours as HTP palettes for 'easier' programming, but it is still a big headache!
Another reason for going with single RGB in a personality is that you can make use of shape gen, which might make all the difference.
I'm sure the Pearl can handle it if you can!
(AFAIK there is no restriction as to intelligents/dimmers re the 240 handles, but I may be wrong.)
Incidentally the implementation of dimmer channels was an interesting topic at Plasa this year. There seems to be a 50/50 split as to whether it is desk manufacturer responsibility (ie. virtual dimmer) or fixture manufacturer responsibility. Understandable, but very annoying. I have been campaingning for Pulsar to implement this for over a year now and spent an hour of heavy discussion at the show but seemed to get nowhere.
One of their main counter-arguments was that noone else had told them this was a problem. At their request I started a poll on Blueroom forum which with one exception (oddly) was 100% in favour of dimmer channel implementation.
I would be interested to hear from anyone else experiencing the problem.
thanx for your advice.. so you are saying the pearl can handle 240RGB cells if necessary??
I'm leaning towards a grandMA with integrated videoserver, or a pixeldrive system, but I've never used either of them. I'd like to use my pearl because I know it pretty well. (except the advanced timing in chases, is there a crash course for that?)
About the dimmer-channel:
if you're going to use it for video only (mediaservers) I can understand why people wouldn't need a dimmer channel, the mediaserver does it all. But from a moving-light-operators-perspective I really like having a dimmer channel. It makes fading in and out easier and it gives the ability to run intensity chases/shapes. extra channel-count is pretty awkward though.. it gives the need of 33% more DMX-channels (4 instead of 3) which could be why they are reluctant to implement it.
I'm leaning towards a grandMA with integrated videoserver, or a pixeldrive system, but I've never used either of them. I'd like to use my pearl because I know it pretty well. (except the advanced timing in chases, is there a crash course for that?)
About the dimmer-channel:
if you're going to use it for video only (mediaservers) I can understand why people wouldn't need a dimmer channel, the mediaserver does it all. But from a moving-light-operators-perspective I really like having a dimmer channel. It makes fading in and out easier and it gives the ability to run intensity chases/shapes. extra channel-count is pretty awkward though.. it gives the need of 33% more DMX-channels (4 instead of 3) which could be why they are reluctant to implement it.
I need Olie to confirm the 240 fixtures thing.
Can you use Pixeldrive to control other fixtures? I assumed it was only for Pixelline? It is a wierd way of working - thinking in shapes/rotating them etc. but should still be controllable from the Pearl I think. There may also be a possibility of some custom software, maybe already written. I know Avo did something similar for writing messages on grids of Pars or along those lines. Of course this might not be free!
Re: dimmer channel:
Actually I thought the most important reason for having the extra channel was the ability to use palettes properly, both whilst operating & for quicker programming. Originally Pulsar could not implement this because the chips used in the controller would not support that many channels. Now new chips are being (or about to be) used which can support, but they say they do not have the time to re-write. My proposal was for the extra 12 channels to be tagged on the end (no reason to have them in a particular order) with another dip-switch option for the new 'full' mode to allow backwards compatibility etc.
Can you use Pixeldrive to control other fixtures? I assumed it was only for Pixelline? It is a wierd way of working - thinking in shapes/rotating them etc. but should still be controllable from the Pearl I think. There may also be a possibility of some custom software, maybe already written. I know Avo did something similar for writing messages on grids of Pars or along those lines. Of course this might not be free!
Re: dimmer channel:
Actually I thought the most important reason for having the extra channel was the ability to use palettes properly, both whilst operating & for quicker programming. Originally Pulsar could not implement this because the chips used in the controller would not support that many channels. Now new chips are being (or about to be) used which can support, but they say they do not have the time to re-write. My proposal was for the extra 12 channels to be tagged on the end (no reason to have them in a particular order) with another dip-switch option for the new 'full' mode to allow backwards compatibility etc.
You would have no problem if you used LTP.
The 400 HTP channel limit is there because there has to be one and when it was decided on, they thought that no one would ever want to use more than 400 HTP channels. How things change.
(I only remove posts if they are not relevant to the topics of this forum. I will move posts if they are off the threads subject. I might have moved it so have a look at other threads.)
The 400 HTP channel limit is there because there has to be one and when it was decided on, they thought that no one would ever want to use more than 400 HTP channels. How things change.
(I only remove posts if they are not relevant to the topics of this forum. I will move posts if they are off the threads subject. I might have moved it so have a look at other threads.)
Avolites Software Team
-
AtmosphErik
- Posts: 18
- Joined: 20 Oct 2004, 12:24
dimmer on LED-fixtures....?
Hell Yes!!! we want dimmer-function on LED-fixtures. Working with fixtures that won't fade-out when you pull down the fader is a bitch, and be sure to tell Pulsar I said so, Nic...
Seriously, though, I feel this is the manufacturer's responsibility. A fixture working on a commonly accepted controlsystem (such as DMX) should be able to be controlled by any desk using that standard. Furthermore, it should respond to any desk in roughly the same way (and of course a Hog has a lot more functions than a ScanCommander, but the fixture doesn't care, does it...It just wants to be told what to do next)
Claiming you don't need an overall dimming function (HTP-dimmer) because no-one has asked for one yet seems a bit naive to me. There is no excuse for all your LED-lights staying "on" in what's supposed to be a black-out, if you've had days to program your show, but when you run a show on-the-fly it would be nice if the stage actually gets dark the moment you slam down your grand master (busted shutters on a StudioColor notwithstanding...)
Having said that, desk manufacturers obviously have a responsibility to make sure the personality files for fixtures are okay... Therefore, implementing a virtual dimmer in a personality for a fixture that doesn't have a HTP dimmerfunction (yet) would seem like a good way of going about things to me...
Seriously, though, I feel this is the manufacturer's responsibility. A fixture working on a commonly accepted controlsystem (such as DMX) should be able to be controlled by any desk using that standard. Furthermore, it should respond to any desk in roughly the same way (and of course a Hog has a lot more functions than a ScanCommander, but the fixture doesn't care, does it...It just wants to be told what to do next)
Claiming you don't need an overall dimming function (HTP-dimmer) because no-one has asked for one yet seems a bit naive to me. There is no excuse for all your LED-lights staying "on" in what's supposed to be a black-out, if you've had days to program your show, but when you run a show on-the-fly it would be nice if the stage actually gets dark the moment you slam down your grand master (busted shutters on a StudioColor notwithstanding...)
Having said that, desk manufacturers obviously have a responsibility to make sure the personality files for fixtures are okay... Therefore, implementing a virtual dimmer in a personality for a fixture that doesn't have a HTP dimmerfunction (yet) would seem like a good way of going about things to me...
Thanks for that!
I do realise the 'grey' area that is whose responsibility it is. That is to say that these fixtures are unique in not actually requiring a dimmer.
To be fair to Pulsar they did understand what I was saying and the reasons (I think!) but ultimately said time was the problem. They were most concerned about the pressure from competition (should Plasa have been renamed 'the LED Show'?
) But one could equally argue that not implementing this function would mean people might choose a product that did support it instead.
I should point out that there are various dimming functions in the ChromaZone which have been added and changed thru' to the current software version. But these are all 'overall' masters - ie. All (up to 12) individual outputs, or built-in chases. It is the addition of dimming for each of the individual channels that is important for flexibility/palettes and efficient programming.
As I pointed out, their main 'professional' competitor (JTE) had implemented this and were on an almost adjacent stand!
I am interested to see whether a virtual dimmer is workable in the Pearl, but I am concerned it will be too much to process.
I do realise the 'grey' area that is whose responsibility it is. That is to say that these fixtures are unique in not actually requiring a dimmer.
To be fair to Pulsar they did understand what I was saying and the reasons (I think!) but ultimately said time was the problem. They were most concerned about the pressure from competition (should Plasa have been renamed 'the LED Show'?
) But one could equally argue that not implementing this function would mean people might choose a product that did support it instead.
I should point out that there are various dimming functions in the ChromaZone which have been added and changed thru' to the current software version. But these are all 'overall' masters - ie. All (up to 12) individual outputs, or built-in chases. It is the addition of dimming for each of the individual channels that is important for flexibility/palettes and efficient programming.
As I pointed out, their main 'professional' competitor (JTE) had implemented this and were on an almost adjacent stand!
I am interested to see whether a virtual dimmer is workable in the Pearl, but I am concerned it will be too much to process.
-
light-o-matic
- Posts: 15
- Joined: 20 Dec 2005, 15:33
I came on this forum to ask about the LED dimming situation and now reading through I see a lot of other people have the same problem. There are so many RGB fixtures that do not have a separate dimmer channel, the cat is out of the bag now. It makes perfect sense to add a personality feature that makes an attribute (dimmer) into an inhibitive master over other attributes (R, G, and B channels).
That also mitigates the problem with the 400 limit on HTP channels since instead of using up 3 HTP channels per fixture you use 3 LTP channels and just 1 HTP.
That also mitigates the problem with the 400 limit on HTP channels since instead of using up 3 HTP channels per fixture you use 3 LTP channels and just 1 HTP.
Who is online
Users browsing this forum: No registered users and 28 guests