Ive tried using the new and somewhat simpler approach to the making of custom symbols within LXBeams. With some, allthough minor, success.
I need to use two pieces of ADJs Mega tribars next week so I drew a simple square and tried to make it behave as these LED-bars in their 7 ch mode.
Seems I got halfway there somehow.
My channel 1 and 2 show up in LXConsole after export not as "red" and "green" but as empty and "Frame". And only the first channel seems to patch at all.
Hard to explain, so I uploaded the keyfile to here: http://distingo.nu/bilder/LXForum/custo ... LED_.lxkey
And here's the device I tried to configure in its 7 ch mode:
http://distingo.nu/bilder/LXForum/custo ... ri_bar.pdf
Guess I'm confused about many things, among them the definition and distinction of an "entry" and a "device".
"Device" seems simple and straightforward but Googles translation (and mine) of "entry" is a word meaning "entrance fee". I assume thats inadequate.
Creating custom symbols
-
Johan Söderberg
- Posts: 294
- Joined: Mon Sep 01, 2008 12:35 pm
- Contact:
This is the second meaning of "entry" from my MacBookPro's (English) dictionary:
2 an item written or printed in a diary, list, ledger, or reference book.
• the action of recording such an item : sophisticated features to help ensure accurate data entry.
In the sense that LX uses "key entry" it simply means an item in the key.
---------------------------------------------------
Below is a diagram of how the key works. Every light that is drawn has properties, channel, color, etc. One of these properties is a reference to an entry in the key.
The key entry, in turn, has a list properties that are common to all lights that reference it. One of these properties is a reference to a symbol that tells how to draw a graphic representation of the light.
To draw itself, the light looks up its key entry and from there finds the symbol which provides the instructions for what it looks like.
Changing either the light's reference to the key entry or changing the key entry's reference to the symbol will alter the appearance of the light. (with the exception of the rare case where the new key entry also points to the same symbol!)
For the most part, if you change a light's keyID to reference a different key entry, the light's info properties such as its channel will remain the same. But, the key entry also determines what info properties a light contains. This changes depending on the kind of key entry. Most kinds of lights have a channel. But, a barndoor does not. A PC or Fresnel will have a spot/flood setting while a fixed focus ERS does not.
Some key entries have a custom symbol. When this is the case, the symbol is stored as one of the key entry's properties. This makes the symbol ID irrelevant because it is not needed to find the instructions for drawing the symbol.
Some kinds of key entries have a table of device addresses. This table is used to expand a base dimmer/address into a list of addresses corresponding to different controllable parameters. A light uses its reference to the key entry to find this table. The light then takes its base dimmer and adds the DMX offset for each address in the table to derive its patch list.
The device addresses table is also used to connect channels that control each output DMX address. This can be done in several ways. Every light that has a device addresses table also has a "Channels" info property. This property can contain a list of channels that control each of the parameters in the table. This simple method would apply if you were using a console that did not support parameters and you had to assign a discrete channel number to each function.
Most modern consoles consolidate different functional parameters into a single channel number. But, there's not really a standard way of doing this. LXSeries uses a schema of sub-channels to refer to various functions. Because of the wide variety of functions available, the sub-channels schema defines some standard functions and leaves numbers open for others.
In LXSeries, a channel that has multiple functions is referred to by a number, a decimal point, and a sub-channel number. Sub-channels 0 to 50 are reserved to be defined by LXSeries. Sub-channels 51 to 99 are undefined and can be used for functions unique to a particular device.
Sub-channel 0 (or the absence of a sub-channel) is always intensity. Sub-channel 1 always refers to the frame of a color changer. Sub-channel 53 might refer to a strobe or macro function. The definition of sub-channel 53 is left open to mean whatever the user wishes.
In the same way that a light uses its reference to a key entry to use a table of device addresses to expand its dimmer into multiple dmx numbers, a light can also use the table to expand its channel into a list of channel.sub-channels.
When setting up the device addresses table, functions can be chosen from a combo box menu. This automatically assigns the correct sub-channel number. If you use the menu to select "Pan", the sub-channel will be set to "2". If you type the name of a function that is not recognized, the sub-channel will be assigned the next available number above 50. For the most part you should accept these assignments and not enter sub-channel numbers manually.
Sub-channels defined by LXSeries often have special connections. Color mixing sub-channels for example are used to determine the color of a light's beam when it is displayed. A color mixing fixture has a "mix type" property that tells LXBeams what sub-channels to expect to use to determine the beam color. A mix type of "rgb" for example, expects to find entries for sub-channels 23, 24 and 25.
---------------------------------------------------
To work as expected your ADJ Mega Tri Bar LED entry should have a color mix type of "rgb". It should also correct the sub-channel numbers.
[/img]
2 an item written or printed in a diary, list, ledger, or reference book.
• the action of recording such an item : sophisticated features to help ensure accurate data entry.
In the sense that LX uses "key entry" it simply means an item in the key.
---------------------------------------------------
Below is a diagram of how the key works. Every light that is drawn has properties, channel, color, etc. One of these properties is a reference to an entry in the key.
The key entry, in turn, has a list properties that are common to all lights that reference it. One of these properties is a reference to a symbol that tells how to draw a graphic representation of the light.
To draw itself, the light looks up its key entry and from there finds the symbol which provides the instructions for what it looks like.
Changing either the light's reference to the key entry or changing the key entry's reference to the symbol will alter the appearance of the light. (with the exception of the rare case where the new key entry also points to the same symbol!)
For the most part, if you change a light's keyID to reference a different key entry, the light's info properties such as its channel will remain the same. But, the key entry also determines what info properties a light contains. This changes depending on the kind of key entry. Most kinds of lights have a channel. But, a barndoor does not. A PC or Fresnel will have a spot/flood setting while a fixed focus ERS does not.
Some key entries have a custom symbol. When this is the case, the symbol is stored as one of the key entry's properties. This makes the symbol ID irrelevant because it is not needed to find the instructions for drawing the symbol.
Some kinds of key entries have a table of device addresses. This table is used to expand a base dimmer/address into a list of addresses corresponding to different controllable parameters. A light uses its reference to the key entry to find this table. The light then takes its base dimmer and adds the DMX offset for each address in the table to derive its patch list.
The device addresses table is also used to connect channels that control each output DMX address. This can be done in several ways. Every light that has a device addresses table also has a "Channels" info property. This property can contain a list of channels that control each of the parameters in the table. This simple method would apply if you were using a console that did not support parameters and you had to assign a discrete channel number to each function.
Most modern consoles consolidate different functional parameters into a single channel number. But, there's not really a standard way of doing this. LXSeries uses a schema of sub-channels to refer to various functions. Because of the wide variety of functions available, the sub-channels schema defines some standard functions and leaves numbers open for others.
In LXSeries, a channel that has multiple functions is referred to by a number, a decimal point, and a sub-channel number. Sub-channels 0 to 50 are reserved to be defined by LXSeries. Sub-channels 51 to 99 are undefined and can be used for functions unique to a particular device.
Sub-channel 0 (or the absence of a sub-channel) is always intensity. Sub-channel 1 always refers to the frame of a color changer. Sub-channel 53 might refer to a strobe or macro function. The definition of sub-channel 53 is left open to mean whatever the user wishes.
In the same way that a light uses its reference to a key entry to use a table of device addresses to expand its dimmer into multiple dmx numbers, a light can also use the table to expand its channel into a list of channel.sub-channels.
When setting up the device addresses table, functions can be chosen from a combo box menu. This automatically assigns the correct sub-channel number. If you use the menu to select "Pan", the sub-channel will be set to "2". If you type the name of a function that is not recognized, the sub-channel will be assigned the next available number above 50. For the most part you should accept these assignments and not enter sub-channel numbers manually.
Sub-channels defined by LXSeries often have special connections. Color mixing sub-channels for example are used to determine the color of a light's beam when it is displayed. A color mixing fixture has a "mix type" property that tells LXBeams what sub-channels to expect to use to determine the beam color. A mix type of "rgb" for example, expects to find entries for sub-channels 23, 24 and 25.
---------------------------------------------------
To work as expected your ADJ Mega Tri Bar LED entry should have a color mix type of "rgb". It should also correct the sub-channel numbers.
[/img]There is one more issue that the ADJ Mega Tri Bar LED key entry brings out. That is the concept of defined values. Defined values in LXBeams are primarily for color scrollers. They provide a table of DMX levels and corresponding colors. When an incoming dmx level is interpreted, the device uses the table to translate from DMX and puts the appropriate value from the table into the light's color field. The defined value entry is chosen as the closest to the incoming dmx level. This works well for color scrollers and also gobo wheels.
When you export channel data to LXConsole, the defined values go along. LXConsole uses defined values in the reverse. That is, it allows you to select a defined value from a menu and then sets the selected channel to the dmx level found in the table. This is very convenient when trying to set some of the odd dmx levels for things like macros found in some channels of moving lights.
This is all well and good until the dmx is sent back to LXBeams. LXBeams sets a light's info field to the value found in the defined values table for the DMX level. In cases like a "macro" field, this has no effect because the (graphic) light doesn't understand what macro means and does not store a value for it. But, if you define a value for a field it does recognize, such as the color mix level for red, green, blue, etc. then the text is entered instead of the percentage of the color!
Because it is useful to have it both ways, the newest build of LXBeams will replace the text of only the color and template fields based on the defined value. Other fields can be used to set text only if it is enclosed in quotes.
Consider the following example. The defined value table for the address corresponding to color mix red has an entry for a level of 50% that reads 'half red'. When a dmx level is received, the defined value is ignored and the light's red mix value is set straight to the incoming dmx percentage. If, instead, the half red is enclosed in quotes, like this: "half red", then the incoming level will cause the mix field to be set to the text 'half red'. The former is the desired outcome as the text 'half red' will be read as zero.
At the moment, there does not appear to be a need to set defined values for any other than the color and template fields. These do not require quotes and will always set info based on incoming levels decoded using the table. Requiring quotes for other fields allows for user control over the behavior.
When you export channel data to LXConsole, the defined values go along. LXConsole uses defined values in the reverse. That is, it allows you to select a defined value from a menu and then sets the selected channel to the dmx level found in the table. This is very convenient when trying to set some of the odd dmx levels for things like macros found in some channels of moving lights.
This is all well and good until the dmx is sent back to LXBeams. LXBeams sets a light's info field to the value found in the defined values table for the DMX level. In cases like a "macro" field, this has no effect because the (graphic) light doesn't understand what macro means and does not store a value for it. But, if you define a value for a field it does recognize, such as the color mix level for red, green, blue, etc. then the text is entered instead of the percentage of the color!
Because it is useful to have it both ways, the newest build of LXBeams will replace the text of only the color and template fields based on the defined value. Other fields can be used to set text only if it is enclosed in quotes.
Consider the following example. The defined value table for the address corresponding to color mix red has an entry for a level of 50% that reads 'half red'. When a dmx level is received, the defined value is ignored and the light's red mix value is set straight to the incoming dmx percentage. If, instead, the half red is enclosed in quotes, like this: "half red", then the incoming level will cause the mix field to be set to the text 'half red'. The former is the desired outcome as the text 'half red' will be read as zero.
At the moment, there does not appear to be a need to set defined values for any other than the color and template fields. These do not require quotes and will always set info based on incoming levels decoded using the table. Requiring quotes for other fields allows for user control over the behavior.
-
Johan Söderberg
- Posts: 294
- Joined: Mon Sep 01, 2008 12:35 pm
- Contact:
Thank you very much for all this information!
Being a filmaker-nerd I think i got the hang of how different posts in different tables relate to each other.
And I ve had some time to give it another try. Finally success!
The mainproblem I had was probably impatience.
It seems that I need to export all changes done to a device and then also close and restart LXBeams/free to get them implemented.
When Ive done so its worked perfectly and Ive uploaded a new and fully functional (at least so it seems in LXConsole, not tested live yet) Symbol and Keyfile for the Mega Tri Bar.
Rightclick and download if you want a copy.
Symbol:
www.distingo.nu/bilder/LXForum/customsy ... .lxsymbols
Key:
www.distingo.nu/bilder/LXForum/customsy ... 0Bar.lxkey
And ADJs info brochure again:
www.distingo.nu/bilder/LXForum/customsy ... ri_bar.pdf
Being a filmaker-nerd I think i got the hang of how different posts in different tables relate to each other.
And I ve had some time to give it another try. Finally success!
The mainproblem I had was probably impatience.
It seems that I need to export all changes done to a device and then also close and restart LXBeams/free to get them implemented.
When Ive done so its worked perfectly and Ive uploaded a new and fully functional (at least so it seems in LXConsole, not tested live yet) Symbol and Keyfile for the Mega Tri Bar.
Rightclick and download if you want a copy.
Symbol:
www.distingo.nu/bilder/LXForum/customsy ... .lxsymbols
Key:
www.distingo.nu/bilder/LXForum/customsy ... 0Bar.lxkey
And ADJs info brochure again:
www.distingo.nu/bilder/LXForum/customsy ... ri_bar.pdf
-
Johan Söderberg
- Posts: 294
- Joined: Mon Sep 01, 2008 12:35 pm
- Contact:
PS
I forgot another useful link:
http://osxdaily.com/2011/07/04/show-lib ... os-x-lion/
Its the teminal command "chflags nohidden ~/Library/"
which shows your user library folder if you run Lion or Mountainlion.
Useful if you want to find the folder: "com.claudeheintzdesign.lxseries"
in your users library for application support.
Thats where keys and symbols are stored.
http://osxdaily.com/2011/07/04/show-lib ... os-x-lion/
Its the teminal command "chflags nohidden ~/Library/"
which shows your user library folder if you run Lion or Mountainlion.
Useful if you want to find the folder: "com.claudeheintzdesign.lxseries"
in your users library for application support.
Thats where keys and symbols are stored.
-
Johan Söderberg
- Posts: 294
- Joined: Mon Sep 01, 2008 12:35 pm
- Contact:
A question
Would it be possible to make it so that LXFree/beams could export and import Light properties to xml, tab or some similar structured format?
A list containing at minimum:
1. A unique field identifying each symbol
2. DMX-adresses
3. "Device info" for each DMXadress. in minimum two (preferrably three) fields: Range from and to plus Name
More fields than the three mentioned above would be required if one wants to add new symbols, with previously unknown symbol IDs and drawing instructions. But if all that could be handled at once with import/export it would be great.
A list containing at minimum:
1. A unique field identifying each symbol
2. DMX-adresses
3. "Device info" for each DMXadress. in minimum two (preferrably three) fields: Range from and to plus Name
More fields than the three mentioned above would be required if one wants to add new symbols, with previously unknown symbol IDs and drawing instructions. But if all that could be handled at once with import/export it would be great.
LXFree will export the information you are looking for in a number of ways.
A key file (Export Key... in the Inspector/Symbols tab popup menu) is in XML format and contains all of the properties and device setup for the key. The drawing instructions for custom symbols are stored in the .lxkey file as well as other library and setup information. It is a complicated format and it is not published anywhere. However, because it is XML, you can learn a lot just by reading through with a text editor. Because it is XML, you can probably extract the parts of interest and ignore the rest.
File->Share->Export Channel Data produces a file either in text or XML format that contains all the channel setup data for specific instances of lights. This information can be used to setup LXConsole. However, again, you can read through and get an idea of what else it could be used for. The latest build adds the ability to export the information for a single channel rather than all the channels. This file has the extension .lxchannel. But, it is an XML based file. (A light must be selected when you choose Export Channel Data for this option to appear.)
Actually, the .lxxplot file format which contains the entire plot including the key (and everything else) is in XML format. There are some MacOS specific parts that are stored as binary data. These are optional and are not necessary for a cross platform implementation to read the file. LXFree for Java preserves these sections but can't really read or do anything with them. So, if you are reading a lxxplot (.lxx) file with a text editor, these will look like big chunks of random characters. But, you can safely ignore them. They contain Mac specific stuff like printer data that is extra to the core light data which you should be able to read.
A key file (Export Key... in the Inspector/Symbols tab popup menu) is in XML format and contains all of the properties and device setup for the key. The drawing instructions for custom symbols are stored in the .lxkey file as well as other library and setup information. It is a complicated format and it is not published anywhere. However, because it is XML, you can learn a lot just by reading through with a text editor. Because it is XML, you can probably extract the parts of interest and ignore the rest.
File->Share->Export Channel Data produces a file either in text or XML format that contains all the channel setup data for specific instances of lights. This information can be used to setup LXConsole. However, again, you can read through and get an idea of what else it could be used for. The latest build adds the ability to export the information for a single channel rather than all the channels. This file has the extension .lxchannel. But, it is an XML based file. (A light must be selected when you choose Export Channel Data for this option to appear.)
Actually, the .lxxplot file format which contains the entire plot including the key (and everything else) is in XML format. There are some MacOS specific parts that are stored as binary data. These are optional and are not necessary for a cross platform implementation to read the file. LXFree for Java preserves these sections but can't really read or do anything with them. So, if you are reading a lxxplot (.lxx) file with a text editor, these will look like big chunks of random characters. But, you can safely ignore them. They contain Mac specific stuff like printer data that is extra to the core light data which you should be able to read.