Hi
I'm trying to use OSC protocol in a greater way, so i made some test. And i think OSC in Lx console is not working well. I saw some dysfunction in many point. I don't know if i'm not using well the option, but a lot of thing are difficult to understand. The Submaster work well, but only in the way : any programme to Lx, but the OSC out doesn't work well.
When i want to pass by the command line, it's ok if i move only one fader, in case of multiple informations, Lx get some problem.
When i use the option "Send sub/master/manual change", it works. I can have the osc message in max/msp. But i've got nothing when i try with "Echo command line" and "send channel defined in actions", and i got this error message,
udpreceive: OSC Unrecognized type tag b. Unable to process message
when i use "Send all channels when changed".
So like i need the OSC for a new project, i try in D-Light, and it works just well. You can put multiple adresse IP:port, and he sends every thing you do (channel, sub, marster, command line, sequence….) in a very simple and efficient langage, alway the same type: /name/..., so it's very easy to treat. Maybe you should have a look, i think it's open source.
Well i'm sorry for this feed back, i really prefer the Lx console interface and way of thinking, but for this project, if OSC doesn't work, i'll go with D-Light.
If you need more precisions about testing, let me know.
P.S. : Touch OSC connect perfectly, the Lx console remote works well except the "out" button, i alway need to write 6 @ 0 ENTER, and not CH 6 OUT…
OSC
The latest build of LXConsole 3.2.2 has a number of improvements in LXConsole's use of OSC.
First of all the submaster OSC out was limited to sending "/cmd.lxconsole/SUB-n" messages. So, if you defined an action in the OSC actions table to control a submaster with some other message, you would not receive that message via OSC out. With this new version both the /cmd.lxconsole/SUB-n message and a message matching the address of an action command SUB-n in the OSC table are sent. If there seems a need, an option to control these individually can be added to the preferences.
Second, faders that are mapped to commands that bypass the command line can be used at the same time. That includes a single channel@%p, SUB-n, master@%p and manual@%p. Other commands require the interface to update and are slower to execute. This can cause issues when two things are changed simultaneously. The previous version did not correctly bypass the command line for channel@%p messages eg. 1@%p. It did bypass the command line for direct levels eg. 1@50. This is now fixed.
The command line output sends a message "/1/cmdline" message with a string argument. In previous version, this was only sent when a "/key.lxconsole" message was received. In the latest build, the message is sent also when you type in the command line of LXConsole.
Send channels defined in actions will send an OSC message to the address defined in the OSC actions table with a command set as "channel@%p" when the level of "channel" changes. So for example, if you have a command defined in the Setup/OSC table with a message of "/1/fader1" (which is found in the TouchOSC "Simple" layout). And, this command has the action command "10@%p". And, you have the option enabled and OSC Out connected to TouchOSC. Then, when the level of channel 10 changes, either manually or by running a cue, a message will be sent to the OSC address /1/fader1 with a parameter 0.0-1.0 that corresponds to the level of channel 10.
The action of send all channel levels is described in the online help. This sends OSC message(s) with a binary blob representing the state of all non-zero intensity channels and all non-intensity subchannels. This may involve more than one OSC message. The binary blob data type is one of the four primary data types defined in the OSC specification. Its not surprising that Max/MSP does not recognize this type because it would require some byte-wise programming to extract the data from this message. This OSC message is designed to communicate with LXBeams on Mac or iOS. The format of this message, particularly the meaning of zero or negative values, is subject to change in the future.
I've looked at the D:Light documentation. It is in French! (I understand how it feels to read all of this in English) It appears to me that a lot of what is available as outgoing OSC is the same as what is available in LXConsole with different semantics. A lot of outgoing OSC in LXConsole is targeted at TouchOSC and LXBeams both on iPad and OS X. If you can describe a particular OSC message that is not available in LXConsole, perhaps it can be added. The ability to target outgoing OSC to a particular IP/port is already available. you have probably already used this targeting Max/MSP.
The TouchOSC remote file has been updated. It seems that TouchOSC has an option to add "/z" to the end of an OSC address. LXConsole, in return, has the option to strip the suffix "/z" from messages. The key for "out" in LXConsole is "z" for zero. So if TouchOSC sends an "/key.lxconsole/z" message and the "/z" gets stripped, then it doesn't work. So, later versions allow the "x" key to mean the same thing as the "z" key. Laterversions of the TouchOSC LXConsole Remote file send "/key.lxconsole/x" meesages for the "out" button. Also, in the latest version, the label for the worklights button responded to the same message as the button. This resulted in the button label switching from "worklights" to "0" or "1" as the button was pressed. (With both OSC In and Out targeting TouchOSC). Use the "LXConsole->Install Extras-> TouchOSC Remote File" command to place a copy of the updated file in your downloads folder. Then, you can use iTunes to load this updated file onto your device.
First of all the submaster OSC out was limited to sending "/cmd.lxconsole/SUB-n" messages. So, if you defined an action in the OSC actions table to control a submaster with some other message, you would not receive that message via OSC out. With this new version both the /cmd.lxconsole/SUB-n message and a message matching the address of an action command SUB-n in the OSC table are sent. If there seems a need, an option to control these individually can be added to the preferences.
Second, faders that are mapped to commands that bypass the command line can be used at the same time. That includes a single channel@%p, SUB-n, master@%p and manual@%p. Other commands require the interface to update and are slower to execute. This can cause issues when two things are changed simultaneously. The previous version did not correctly bypass the command line for channel@%p messages eg. 1@%p. It did bypass the command line for direct levels eg. 1@50. This is now fixed.
The command line output sends a message "/1/cmdline" message with a string argument. In previous version, this was only sent when a "/key.lxconsole" message was received. In the latest build, the message is sent also when you type in the command line of LXConsole.
Send channels defined in actions will send an OSC message to the address defined in the OSC actions table with a command set as "channel@%p" when the level of "channel" changes. So for example, if you have a command defined in the Setup/OSC table with a message of "/1/fader1" (which is found in the TouchOSC "Simple" layout). And, this command has the action command "10@%p". And, you have the option enabled and OSC Out connected to TouchOSC. Then, when the level of channel 10 changes, either manually or by running a cue, a message will be sent to the OSC address /1/fader1 with a parameter 0.0-1.0 that corresponds to the level of channel 10.
The action of send all channel levels is described in the online help. This sends OSC message(s) with a binary blob representing the state of all non-zero intensity channels and all non-intensity subchannels. This may involve more than one OSC message. The binary blob data type is one of the four primary data types defined in the OSC specification. Its not surprising that Max/MSP does not recognize this type because it would require some byte-wise programming to extract the data from this message. This OSC message is designed to communicate with LXBeams on Mac or iOS. The format of this message, particularly the meaning of zero or negative values, is subject to change in the future.
I've looked at the D:Light documentation. It is in French! (I understand how it feels to read all of this in English) It appears to me that a lot of what is available as outgoing OSC is the same as what is available in LXConsole with different semantics. A lot of outgoing OSC in LXConsole is targeted at TouchOSC and LXBeams both on iPad and OS X. If you can describe a particular OSC message that is not available in LXConsole, perhaps it can be added. The ability to target outgoing OSC to a particular IP/port is already available. you have probably already used this targeting Max/MSP.
The TouchOSC remote file has been updated. It seems that TouchOSC has an option to add "/z" to the end of an OSC address. LXConsole, in return, has the option to strip the suffix "/z" from messages. The key for "out" in LXConsole is "z" for zero. So if TouchOSC sends an "/key.lxconsole/z" message and the "/z" gets stripped, then it doesn't work. So, later versions allow the "x" key to mean the same thing as the "z" key. Laterversions of the TouchOSC LXConsole Remote file send "/key.lxconsole/x" meesages for the "out" button. Also, in the latest version, the label for the worklights button responded to the same message as the button. This resulted in the button label switching from "worklights" to "0" or "1" as the button was pressed. (With both OSC In and Out targeting TouchOSC). Use the "LXConsole->Install Extras-> TouchOSC Remote File" command to place a copy of the updated file in your downloads folder. Then, you can use iTunes to load this updated file onto your device.