hi
(using lx beams 3.2.1)
today I was tryiong toi dig deeper into setting up devices and I came to the point where I wanted to write channel ranges in the devicevalues tab. While doing this I noticed some kind of bug: when clicking "+" it added empty entries and when trying to write something e g level or "color" (frame address) it jumped back to the "shutter" address. Basically it did not work at all. But I guess this can be fixed.
Then I am wondering if this info would be stored with the key entry or only with the document, meaning do I have to export the key afterwards in order to be abl eto use this information in another plot?
and, will it be accessible in the channels control window in LXconsole and how? Because some of these ranges e g lamp on/off need to be clearly and easlily accessible there.
Cheers!
/uli
device setup
device setup ff
Hi again,
now just to double check I went to lx console and had a look at the channel setup there, found out that I could do the values there as well. But, the channel info did not appear to have been transfered to console by the setup lxconsole script at all.
E g I had patched a MAC 500 in lx beams on ch 101 , with the normal dmx setup from the moving key. What appears in the channel control window when I select ch 101 is some dmx setup but a very different one.
And when chose inport "mac 500" form the menu there the dmx layout looks very different from the one I get from the same entry in lx beams. Does this mean that the apps use different libraries?
cheers, Uli
now just to double check I went to lx console and had a look at the channel setup there, found out that I could do the values there as well. But, the channel info did not appear to have been transfered to console by the setup lxconsole script at all.
E g I had patched a MAC 500 in lx beams on ch 101 , with the normal dmx setup from the moving key. What appears in the channel control window when I select ch 101 is some dmx setup but a very different one.
And when chose inport "mac 500" form the menu there the dmx layout looks very different from the one I get from the same entry in lx beams. Does this mean that the apps use different libraries?
cheers, Uli
The bug you observed in the defined values panel was fixed in one of the later 3.2.x versions. This includes the current latest build, 3.3.0 (which will become the new release version soon).
Any defined values are part of the key entry and apply to all fixtures of that type. So, if you had changers with two different scrolls of color, you would need two separate key entries. And, this makes sense because the plot would want to indicate which scroll a particular changer should have so they could be placed properly. So, you would either use a slightly different symbol or the default mark field of the key entry to indicate this.
The same principal applies to the device addresses assigned to a key entry. It is possible (although probably not a good idea!) that you might have the same model of fixture set to different DMX control modes. Each DMX mode requires a separate key entry.
The configuration of key entries and thus device addresses and defined values is stored in the key, which is in turn stored in the plot file. You can export and import keys and thus use them in more than one plot. (If a key is stored in your username/Library/Application Support/com.claudeheintzdesign.lxseries/keys folder, it will appear in the menu when you select load key from the popup in the Inspector's symbols tab.)
The built-in libraries are separate in LXConsole and LXBeams and are un-editable. If you were to try to edit them, it will break the code-signing and the application will probably not work. But, there are folders in the username/Library/Application Support/com.claudeheintzdesign.lxseries folder where you can store your own library files.
When you used the script to setup LXConsole for your Mac500, what you probably saw was that the names of the sub-channels were different, abbreviated versions of the names in LXBeams. This is also fixed in the latest build. What you don't see, except in LXBeams device address table and LXConsole's channel setup sheet are the actual sub-channel numbers. Those sub-channels were transfered correctly, it is just how they appeared to you was different. The export of the sub-channel names from LXBeams is now fixed.
But, at this moment, a number of the the built-in channel setups in LXConsole still use the abbreviated form of the sub-channel names. That is one thing that probably should be fixed before LXConsole 3.3.0 is officially released.
The channel setups built into LXConsole are entirely separate from the keys that are built into LXBeams. It does makes *sense* that they should match
But, there is no version issue that causes the difference.
There is one additional difference between how device addresses are presented in LXBeams and the channel setup in LXConsole. That is that the device address table in LXBeams normally follows the order of the DMX addresses that have been specified by the fixture manufacturer. In LXConsole, the sub channels are always displayed in functional order, regardless of how the patch will be entered. At first glance, you could panic and assume that the DMX order is wrong in LXConsole. But, if you examine the patch, you will find that the addresses have been assigned correctly.
Any defined values are part of the key entry and apply to all fixtures of that type. So, if you had changers with two different scrolls of color, you would need two separate key entries. And, this makes sense because the plot would want to indicate which scroll a particular changer should have so they could be placed properly. So, you would either use a slightly different symbol or the default mark field of the key entry to indicate this.
The same principal applies to the device addresses assigned to a key entry. It is possible (although probably not a good idea!) that you might have the same model of fixture set to different DMX control modes. Each DMX mode requires a separate key entry.
The configuration of key entries and thus device addresses and defined values is stored in the key, which is in turn stored in the plot file. You can export and import keys and thus use them in more than one plot. (If a key is stored in your username/Library/Application Support/com.claudeheintzdesign.lxseries/keys folder, it will appear in the menu when you select load key from the popup in the Inspector's symbols tab.)
The built-in libraries are separate in LXConsole and LXBeams and are un-editable. If you were to try to edit them, it will break the code-signing and the application will probably not work. But, there are folders in the username/Library/Application Support/com.claudeheintzdesign.lxseries folder where you can store your own library files.
When you used the script to setup LXConsole for your Mac500, what you probably saw was that the names of the sub-channels were different, abbreviated versions of the names in LXBeams. This is also fixed in the latest build. What you don't see, except in LXBeams device address table and LXConsole's channel setup sheet are the actual sub-channel numbers. Those sub-channels were transfered correctly, it is just how they appeared to you was different. The export of the sub-channel names from LXBeams is now fixed.
But, at this moment, a number of the the built-in channel setups in LXConsole still use the abbreviated form of the sub-channel names. That is one thing that probably should be fixed before LXConsole 3.3.0 is officially released.
The channel setups built into LXConsole are entirely separate from the keys that are built into LXBeams. It does makes *sense* that they should match
But, there is no version issue that causes the difference.There is one additional difference between how device addresses are presented in LXBeams and the channel setup in LXConsole. That is that the device address table in LXBeams normally follows the order of the DMX addresses that have been specified by the fixture manufacturer. In LXConsole, the sub channels are always displayed in functional order, regardless of how the patch will be entered. At first glance, you could panic and assume that the DMX order is wrong in LXConsole. But, if you examine the patch, you will find that the addresses have been assigned correctly.
floor positions
Hi Claude
thank you very much for this great app and for the excellent support you are giving. I am on my way exploring this and in such a situation there are always a lot of questions arising.
But, finally , I got it all working.
One thing though that I cannot do is mounting a fixture e g mac 250 on the floor get it properly orientated. I did this by lying out a bar at the height 0 but it seems that the lamps are still hanging and any rotation that I can do in plan view does not affect the pan tilt values. I make lxconsole send a script to beams and there I can see that the lamps behave as if they were hanging whereas they are rotated 180 dgr around the x axis in reality. Is there any way to tell lxbeams this?
With a conventional light it`s far easier because i only need to focus the beam manually, then it`s done no matter if the lamp is upside down or not.
Cheers!!!
thank you very much for this great app and for the excellent support you are giving. I am on my way exploring this and in such a situation there are always a lot of questions arising.
But, finally , I got it all working.
One thing though that I cannot do is mounting a fixture e g mac 250 on the floor get it properly orientated. I did this by lying out a bar at the height 0 but it seems that the lamps are still hanging and any rotation that I can do in plan view does not affect the pan tilt values. I make lxconsole send a script to beams and there I can see that the lamps behave as if they were hanging whereas they are rotated 180 dgr around the x axis in reality. Is there any way to tell lxbeams this?
With a conventional light it`s far easier because i only need to focus the beam manually, then it`s done no matter if the lamp is upside down or not.
Cheers!!!
There are a number of pieces which play into answering your question.
First, in the main plan view, beams are displayed when they intersect the beam plane. This may not be a problem for you if you've solved seeing conventional fixed lights' beams that are located on the floor. But, it may be necessary to raise the beam plane above the height of the lights in order to see upward directed beams.
Second, each light is mapped to a position based on individual 3D offsets. This allows for things like differences between yoke sizes and for over-hung and under-hung lights on the same position. The default z offset (height) is set to below the position. Unless you change this, lights hanging on a 0 height position will be mapped to below the floor.
Third, and perhaps the most complex, is that for pan and tilt of an automated fixture to work correctly, the 3D orientation of the light in space must be specified. The "zero" orientation of a fixture is parallel to the floor and pointing toward the top of the screen. It takes rotation about three axes to specify how a fixture is oriented away from this "zero" position. This specification is done in the device parameters field in a semi-colon separated list. Fortunately, you can double-click "parameters" in the first column of the Inspector's info table to edit each individually in a user friendly way.
Setup pan is rotation about a vertical axis. A value of zero is pointing toward the top of the screen. A value of 180 is pointing toward the bottom of the screen.
Setup tilt x and setup tilt y are rotations about the respective horizontal axes.
Imagine a rod running from left to right through the center of the light. If the light starts out pointing straight down and you rotate the light about that rod 180 degrees, you will end up with the light pointing straight up. And, if the pan reference was pointing to the top of the screen, it will end up pointing towards the bottom now that the light is upside down. That's the effect of a value of 180 for setup tilt x.
Setup tilt y works the same way except the rod runs top to bottom rather than side to side. So, a value of 180 for setup tilt y is very similar to the above example. The light ends up pointing up instead of down. But, the pan reference remains pointing to the top of the screen.
These rotations are performed in order and the effect is cumulative. Taken together, they make it possible to specify any orientation of the fixture in 3D space.
First, in the main plan view, beams are displayed when they intersect the beam plane. This may not be a problem for you if you've solved seeing conventional fixed lights' beams that are located on the floor. But, it may be necessary to raise the beam plane above the height of the lights in order to see upward directed beams.
Second, each light is mapped to a position based on individual 3D offsets. This allows for things like differences between yoke sizes and for over-hung and under-hung lights on the same position. The default z offset (height) is set to below the position. Unless you change this, lights hanging on a 0 height position will be mapped to below the floor.
Third, and perhaps the most complex, is that for pan and tilt of an automated fixture to work correctly, the 3D orientation of the light in space must be specified. The "zero" orientation of a fixture is parallel to the floor and pointing toward the top of the screen. It takes rotation about three axes to specify how a fixture is oriented away from this "zero" position. This specification is done in the device parameters field in a semi-colon separated list. Fortunately, you can double-click "parameters" in the first column of the Inspector's info table to edit each individually in a user friendly way.
Setup pan is rotation about a vertical axis. A value of zero is pointing toward the top of the screen. A value of 180 is pointing toward the bottom of the screen.
Setup tilt x and setup tilt y are rotations about the respective horizontal axes.
Imagine a rod running from left to right through the center of the light. If the light starts out pointing straight down and you rotate the light about that rod 180 degrees, you will end up with the light pointing straight up. And, if the pan reference was pointing to the top of the screen, it will end up pointing towards the bottom now that the light is upside down. That's the effect of a value of 180 for setup tilt x.
Setup tilt y works the same way except the rod runs top to bottom rather than side to side. So, a value of 180 for setup tilt y is very similar to the above example. The light ends up pointing up instead of down. But, the pan reference remains pointing to the top of the screen.
These rotations are performed in order and the effect is cumulative. Taken together, they make it possible to specify any orientation of the fixture in 3D space.
