DiyLightAnimation
Hardware => Other Projects => Topic started by: thshadow on January 03, 2010,
-
Anyone interested in seeing if we can do this...
-
Okay I have some programming experience on a Mac. I haven't really taken a good look at Vixen or the other Windows based program. Both should run fine on Parallels or Boot Camp for a Mac so there may be no real need for this. However it would be kindda cool to have a native based application to do the same thing. There are programs native to mac which could make the mixing of music, etc a much easier process. I have written programs here to control AV equipment using serial commands without issue as well as the same with RPC. From what I am gathering the Lynx use DMX or some variant of it so if we can figure how to send standard DMX commands out of a Mac like you would Rs232 or similar then Bingo this should be a piece of cake.. maybe ;)
Anyone interested in giving this a shot or at least brainstorming some more on it. One of the larger software companies for DMX control makes an iPhone app for such... so figure behind the scenes it couldn't be too hard in Cocoa to get this going.
Anyway open to thoughts on this... or is this a better left alone area given the easy of Parallels on a Mac.
- Mike
-
I still live in the world of much legacy G4/G5 Mac equipment, so no Boot Camp or Parallels (nor Snow Leopard) for me.
And I've read on other boards that some people have problems running Vixen under Boot Camp or Parallels (others, not so much).
While my personal preference for a sequencing tool that runs on OSX probably outweighs my ability to ascertain whether it would be beneficial to invest time in developing such an animal, I'm here to help in any way I can.
\dmc
-
I also am in a spot with an older mac (powerbook g4) that I can still use and could possibly take some time learning some programming for a mac, however any software that would be produced would probably need to be "universal" I'm guessing. I have no access to an intel mac.
The usb drivers for the dongle have a mac version I can install and test when I get a dongle built.
-
All you need is a rope, about 4 foot long will do. A 3lb rock and a lake. If you don't have a nearby lake, a cliff will do!
Tie rope around Mac, then throw rock...... problem solved!
Just sorta kidding, >:D
I'm a PC
-
Ok for those of you using non-Intel based macs how do you drive your displays now? Universal wouldn't necessarily be that much of a problem... I originally was thinking more towards like a mac mini idea due to form factor and size; cost, etc... but I can easily see how a G4/G5 pre-Intel could very well fit the bill as well.
I saw another program listed on one of the forums somewhere in which the program sends DMX control commands via a web interface. It works on a mac so that might could be used as a translator behind the scenes and then just develop a pretty front end... I need to really spend some time on the DMX stuff; once I get a better understanding of how that works then I can be more useful on the mac development side of stuff.
Anyway leave the discussion open for a bit and see who else is interested.... while I figure out DMX a bit more.
-
Hi Mike,
I use a mac mini (normally at work, sometimes at home) and have problems with it over heating and shutting down. Just a concern if you were going to buy one to use as a show computer. Besides that we are all in favor of more software options to control our lights.
Cheers
Rick R.
-
Mike... for sure I'll watch this and see where it goes. I'd love to see something for Universal.
John
-
Ok let me keep researching DMX... but in the meantime... are all our Universal people on Leopard? or are we talking a universal the goes back farther than that Tiger, or ....?
- Mike
-
I'd start with leopard. ;D
-
Ok let me keep researching DMX... but in the meantime... are all our Universal people on Leopard? or are we talking a universal the goes back farther than that Tiger, or ....?
I'd prefer Tiger, but that's just me.
\dmc
-
I'm also on Tiger but plan to upgrade to leopard eventually when disk prices drop a bit more.
-
^ same same
-
Anyone want to start brainstorming on this idea?
Where can you learn about the DMX language?
As I said before I am willing to help out with this on my legacy(g4) powerbook, beta testing, writing code, designing graphics, whatever needs done.
-
Well I am looking into that... DMX seems to be something of a modified serial command in essence utilized only in AV equipment.... what I am wondering if sending some type of serial command to the USB port how the dongle converts that into a DMX command; if it actually modifies the structure of the command like a translation or if it just changes it in terms of timing and sequencing... not sure exactly how to express that notion correctly... for me I am looking to find DMX resources or see if I can figure out how Vixen deals with sending out a command to the USB port... if I can understand how Vixen deals with the USB to DMX process then I can understand how to send commands to the port like Vixen... however still waiting on a few parts to arrive to build my dongle so I can actually see more about how that process works... By trying to send serial commands and seeing what comes out the other side... it will give me a better idea of what the command structure must look like in terms of sending it in the first place. However right now it is like flying blind without a dongle...
-
Okay I may have found a starting point:
http://www.usbdmx.com/downloads/protocol.pdf
This seems to describe the protocol used for the USB to DMX commands and seems to relate to the same drivers we use for the Dongle. DMX commands seem to be in the format of channel and then light level.... with a @ in between the two...
The pdf above seems to describe how you send a serial command and I am assuming either the driver or the dongle converts that to Ch @ level commands... again this is also guess because of not yet having a dongle or a LE to try this on... yet
I have found a sample bit of code which is this:
Create the project:
1) Open Xcode
2) Press 'Command + shift + n' This will open the new project dialog
3) Select 'Cocoa Application' under "Mac OS X -> Applications" Press Next
4) Call the app what you want. I'm calling mine "Arduino Controller"
Add your class:
5) Once the project is created, Press 'Command + n'
6) Select the Objective-C Class option from the Classes option under the Mac OS X section
7) Call it MainController. Then press finish
Add the code:
8) Open MainController.h
9) After the '}' & before the '@end' add the code:
-(IBAction)ledOn:(id)sender;
-(IBAction)ledOff:(id)sender;
10) Open MainController.m
11) After the code ''@implementation MainController" & before the '@end' add the code:
-(IBAction)ledOn:(id)sender{
popen("echo i > /dev/tty.usbserial-A6006hmi", "r");
}
-(IBAction)ledOff:(id)sender{
popen("echo o > /dev/tty.usbserial-A6006hmi", "r");
}
Finishing The Coding:
12) Press 'Command + b' & press save all
13) Double click on MainWindow.xib. It is located under Resources
14) Interface Builder will open
This comes from http://www.instructables.com/id/Controlling-an-Arduino-with-Cocoa/step2/Coding-the-app/
The area that will need to be changed is popen commands to deal specifically with the driver we need.. which requires a bit more research... well an actual hardware...
Anyway this is a very good start... now just need to add to it... but at this point requires me to wait on the hardware to put it together and get a feel for how changing the commands changes the output.
- Mike
-
The Dongle in the case of PC's looks like a old serial com port. The software sends a packet out that is formated and has all the values for all 512 channels every time somethign changes. The dongle makes the DMX using this information to tell it what the values should be. If you have no changes you do not send an update and the dongle keeps sending out the last set of values.
RJ
-
Okay RJ,
That makes sense... So let me see if I am getting this right...
We would format the command as if we are sending a traditional serial command to a PC serial port (yes I understand it is Mac but the same concept applies). So the only question left then is what does the format of the command look like that the dongle is expecting, ie how does format the command... I would guess it takes something close to ch1,ch2,ch3 with each of the ch# being replaced with the actually light level of that channel and the , being replaced with a delimiter marking next value..
However that format varies greatly based on device... one of the most common some of equip uses here is the %20 or %0D for space or end of command.. so given that I would take a random guess the serial command the dongle is looking for is close to 04 12 15 22 ...... %0D thus setting channel 1 to light level 4, ch 2 to light lv 12, ch 3 to lv 15 and ch 4 to lvl 22... and such all the way to 512 which then follows end of command %0D
Is that a close guess... or am I way off...
- Mike
-
Depends on the device. The enttec clones like the lynx use the Enttec Pro protocol.
RJ
-
Mike,
You can read/download the protocol format for the Enttec Pro device from following link:
http://www.enttec.com/docs/dmx_usb_pro_api_spec.pdf (http://www.enttec.com/docs/dmx_usb_pro_api_spec.pdf)
I believe the Lynx dongle emulates only a subset of the Enttec Pro device, specifically the message type 6 found in page 5 of the specification document section "8.Output Only Send DMX Packet Request (Label=6).
Since the Lynx dongle uses a FTDI usb chip to communicate with the host computer, you can access it 2 ways; 1) Through a standard serial port that is virtually created by the FTDI drivers, 2) Directly through the FTDI API. You can find more info in the FTDI website such as API documentation, code samples, windows drivers, etc...
http://www.ftdichip.com/ (http://www.ftdichip.com/)
Visit the 'Drivers', 'Documents', 'Resources' and 'Projects' links in their web menu.
Some code samples for the Enttec Pro dongle can be found if you search the internet. Enttec site might also have some code examples.
As an example please look at this thread (old but good read anyway):
http://processing.org/discourse/yabb2/YaBB.pl?board=os_libraries_tools;action=display;num=1128939792 (http://processing.org/discourse/yabb2/YaBB.pl?board=os_libraries_tools;action=display;num=1128939792)
Note: The code example in the thread above is missing the START CODE byte
In summary:
1. Install FTDI drivers
2. Plug Lynx dongle in to USB port
3. Establish link between your computer program and dongle (FTDI drivers or virtual serial port)
4. From your application, send DMX data packet in following format (all are BYTE type) through your established communication with the dongle:
DMX(0) = 126 'DMX_PRO_MESSAGE_START 0x7E
DMX(1) = 6 'DMX_PRO_SEND_PACKET for message type 6 output only
DMX(2) = {byte value} 'LSB # channels
DMX(3) = {byte value} 'MSB # channels
DMX(4) = 0 ' START CODE always 0
DMX(5) = {value from 0 to 255} ' channel 1 data
DMX(6) = {value from 0 to 255} ' channel 2 data
... etc ...
DMX(4+#channels) = {value from 0 to 255} ' last channel data
DMX(5+#channels) = 231 'DMX_PRO_MESSAGE_END 0xE7
and any DMX device attached to the dongle universe (Enttec Pro or Lynx) should get its channel data.
RJ please jump in if i'm stating something incorrectly.
Hope this info helps.
Leo
-
Thanks this gives me enough info to move in the right direction.
- Mike
-
I've found a piece of software for mac/linux/windows that works with the enntec DMX pro.
It looks like an actual lightboard (with sliders up/down, master, fade slider). The limitation is that it is only 24 channels but that could probably be changed.
Site where found is
http://www.chromakinetics.com/DMX/ (http://www.chromakinetics.com/DMX/)
software is
mini stage console
-
I have a macbook with the intel based processor. Let me know what I can do to help. I use to program a lot, but took a break the last few years.
-
The Lynx dongle (and the RPM one) only support a subset of the Enttec Pro commands. Some software may not recognize them (or may not work properly) if they try to use the unsupported ones.
/mike
-
Yes but not focusing on the full set of driver commands per se. The driver should be able to send the bare basic commands and we should be able to work around that. I just got the final part for my dongle which was backordered.. well actually still is but found a replacement via the dongle discussion board... over the next several weeks put it together and then hopefully can get a SSR with DMX together as well then I can actually work on trying it out.. From what was discussed earlier I think the basic set should be ok... I have a slight feel for how the command structure might look like and so now it is just to get stuff together and try a very basic set of instructions.. if that works I will post the command syntax and the Cocoa project files and go from there...
- Mike
-
Hey all,
I really like your ideas for a coca app for mac. On my PC, vixen would freeze when I hit test channels, or try to send anything through the dongle. So I installed the FTDI drivers on my macbook pro hoping I could use it here, but no dmx program, even the simple 24 channel ones will recognize the dongle at all. I was wondering if there is something special you did to link the drivers/dongle.
Thanks in advance.
-Collin
-
I have successfully used this software:
http://www.chromakinetics.com/DMX/miniStageConsoleMac.html
Just for testing and fooling around, of course. Mac OS X 10.4.11 on a Gigabit Ethernet G4.
\dmc
-
DMX output is already handled in a cross-platform way by xLights. Last year I was able to demo a Tiger-based Mac natively playing LOR and Vixen sequences. Since xLights is open-source, feel free to leverage the code that has already been written.
Matt
-
If you like the Mac Mini, you might also like this which would solve your software issues:
http://www.amazon.com/CompuLab-fit-PC2-Value-Atom-Z510/dp/B0047CUL8S/ref=sr_1_3?ie=UTF8&qid=1300217172&sr=8-3 (http://www.amazon.com/CompuLab-fit-PC2-Value-Atom-Z510/dp/B0047CUL8S/ref=sr_1_3?ie=UTF8&qid=1300217172&sr=8-3)
-
Just noticed this topic. Anything happen with this?
I was also curious if that many people are currently useing software on there Mac, or just boot camping into windows. I ask because I am trying to determine what driver I want to code to on the FTDI chip. They have a usb one, with a library, that would enable a few extra features I would like to take advantage of (such as being able to load the microcode to the dongle without a PICIT). But the gotcha is one can't have the serial virtualization drivers and the usb driver loaded at the same time. So if you ran things like xLights or something, one would have to reinstall drivers. But if for the most part, no one is really running Mac software, then for new software, using the usb driver would be a reasonable option.
-
As I started laying out my tools/projects I am doing, I was wondering about setting up a daemon (process) to read in network packets,and then spool them to the proper dongle/universe. It would let me isolate the serial items from all my other code, and easily support multiple universes. The network packet would just be wrapper of the DMX packet, with a universe indicator. I was wondering how useful this type of abstraction would be outside my programming. Right now I am planning to right the dispatcher in Cocoa (Mac native support), but could see if written in C, it would work on any platform (with a few tweaks for winsock on windows). Just thinking out loud.
-
If you are going to take that approach, why not use OLA?
http://opendmx.net/index.php/OpenDMX.net (http://opendmx.net/index.php/OpenDMX.net)
-
If I understand that correctly, it is like Art Net, a protocool that is made for the controllers to be ethernet based. That has more to it, since each controller box has to look, respond, etc. This is quite a bit simplier, the controllers are still straight DMX. Just a software program in between that and the serial port, looks at the an extra byte, selected the correct serial port based on universe to port assignment, and then sends the dmx packet.
Unless I am misunderstanding the protocool, and it is for something designed to be something not at the controller level.
-
OLA is not a protocol, think of it more as a translator. It provides a standard API to communicate to a dozen different DMX dongles as well as several different DMX over IP protocols including E1.31 and Artnet. It accomplishes this via a daemon process, just as you propose for your own software. Here is a better link:
http://opendmx.net/index.php/OLA (http://opendmx.net/index.php/OLA)