Beiträge von light-o-matic

    I use the Android app "AURORA DMX" to control JINX remotly via WIFI. This allows you to send saved cue set's to JINX via art-net.

    Thank you, I tried it and it's very good! Much simpler than my solution. I realized that to get a button for each scene I can record a cue for each scene selection .. but then it also resets the brightness, which is not what I want. Using Osc Control I have 24 buttons to select the scene, and a slider to independently control master and strobe, and the Osc-TPM2 gateway is approx 50 lines of python code.

    What I'd really like is to have the remote load and display the name of each scene, but to do that I would have to parse the Jinx! data file .. and without having the source code that would be a lot of effort. I'd also like if my remote control could be bidirectional: Display the changes on all remotes if any remote changes. The OSC protocol supports this but none of the clients that I have found support it .. so I'd have to write my own. Again, a lot of work.

    I had the idea to write just the engine code similar to Jinx, but with no user interface .. since that's the most work. Just an OSC, MIDI and / or REST API for all controls, then this could run on a raspberry pi or any small computer and be controlled various ways, eg. Via AJAX from a web UI, or whatever you want ... I just don't know if I have the time for all that right now ...

    Hello! I apologize for posting in English.. I don't know German.

    I use Jinx! to run my WS2811 "milky ball" curtain for years now, and decided finally this week to get a remote working .. and had the same flickering problem with the remote control in Windows 10 ....

    But I got it working in Windows 10 using Windows 7 compatibility mode as follows:

    Right click "Jinx!" in Windows 10 "Start" menu, and select "Properties". In the Properties window, look for "Run this program in compatibility mode for:" .. with a checkbox. Check this box, and in the dropdown, select "Window 7".

    No more flickering of the remote value.

    I think (complete guess on my part) is that.. There is some code in the event loop which compares the previously received control packet with the currently received control packet. If there is a difference, it generates windows events to simulate the requested actions, then copies the current packet as the previous one for later comparison.

    Windows 10 probably changes the event loop logic, possibly with multithreading which causes a race condition in the moment the packet is copied.

    Hopefully the author will eventually be able to go back to work on the software (hoping it was something GOOD in his life like children or a great new job that got in the way, and not something bad that interfered), but meanwhile this works.

    In case you are interested, what I'm doing is using an Android OSC app (Right now "Osc Control" but it has some problems so I might like to find a better one), and I've written a little OSC server in Python (using python-osc) that forwards the control events to Jinx! as packets. So now me and my wife can easily turn the LEDs on / off, control brightness, and select patterns from our smart-phones.

    And.. I haven't done this part yet.. but there's a good python library I've used in the past for installing/controlling python code as a Windows Service so that it'll start up and shut down with Windows.

    I just started on this project yesterday but it's working.. and I have some cleaning up to do, but when it's ready I'll put it up on github for sharing if you're interested.