Matrix Value Send and receive don't operate as expected with Enttec USB Pro. (f24 & f25)
I'd like to report a couple of bugs that occur when I try and use the Enttec DMX USB Pro with Isadora 1.3.0f24 or f25.First of all, when I open up any of my old patches that use the Enttec device to control DMX, as soon as I try and do a lighting fade, Isadora hangs. If I unplug the Enttec device, Isadora resumes working functionally. I traced this problem (which I believe was identified on the forum) to too much information being pushed to the Enttec and solved it by putting in a multi-blocker actor in the serial stream. This, however, causes another problem, in that now the zero value portion of the fade is sometimes blocked, leaving lights ghosting at a low level when they should be off.Another problem also exists with the multi-blocker actor. If you have more than one value in a given actor, all values other than the first one have reverse behaviour if the values are changed in zero time. For example, if I use the bump input on the actor, the value sent to channels 1 are full, but the values sent to channels 2 are zero. I have traced this back to the the multi-blocker, as you can see in the attached screen shot, the value coming out of the Matrix Value Receive is correct, but the value in the Send Raw Serial Data actor is wrong.Hopefully this can be remedied, as I have a couple of shows in the works that are heavily reliant on DMX control through Isadora.Thanks,Craig
Dear Craig,Well, ultimately we need some kind of "throttle" to control the max rate at which messages can be sent via the Matrix Value Send.The main thing is that the multi-blocker actor is not the right one to use here -- because of the problems you outline (I'll get to those in a second.). Instead, you would want to use the Trigger Text actor in combination with the Pulse Generator actor. (See the picture.)You're going to want to set the 'freq' input to the maximum DMX rate -- memory tells me that's 44 Hz, but it might be 50 Hz. (I'm on a train with no internet right now... can't check.)This solves the problem of the "lingering low level light" because it ensures that the most recent value eventually gets sent.The bug you mention with the 'multi-blocker' actor isn't really a bug, because it's doing it's job properly. When you 'bump' the two channels, it doesn't send them as one unit. It bumps the first channel first, and the second channel second. That means the first value that goes through the multi blocker at 'FF00' -- then the second value is updated (to 'FFFF') but the multi blocker actor blocks it.I can see why you would assume this was a "parallel" operation -- but in fact, each channel is updated one at a time.In any case, as I said, use the combo shown above and I think you'll get the results you're hoping for.Best Wishes,Mark
is there a way to test the patch without the interface?
Any actor to monitor a serial port?
Sorry, I am a beginner