Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

mjr

VIP Class
  • Content Count

    45
  • Joined

  • Last visited

Community Reputation

5 Neutral

About mjr

  • Rank
    Advanced Member

Profile Information

  • Gender
    Female

Recent Profile Visitors

976 profile views
  1. And to your main point, if DJRobX wants to publish his source code, I can integrate his changes into my version. Alternatively, my source is already published on github, so he can integrate my updates into his version if he prefers.
  2. The glitchy LedWiz behavior is quite complex. SwissLizard knows about it, and I've looked into it quite a bit, but unfortunately there's no good solution. Here's what we know: 1. The LedWiz itself is the actual source of the bug. As far as we can tell, it has a poorly written USB interface in its firmware that doesn't properly protect its packet buffer against concurrent read/write access. It seems that if the host sends a new USB packet at the wrong moment, the LedWiz will interpret PART of the new buffer and PART of the old buffer as a single packet, making a jumbled mess of the two. This results in outputs getting turned on and off randomly, and being set to random brightness levels. 2. PinballX triggers the problem. Exactly how it does this is a huge mystery to me, but you can verify this as follows. Install the DOF version where you see the glitchy behavior. Exit out of PinballX. Launch Visual Pinball directly from the Windows desktop, load a game, run. The LedWiz will run smoothly. It's been reported that some other third-party software also triggers the problem. I think someone mentioned Firefox as another trigger. Again, I don't have any idea what these other programs are doing that affects the USB packet timing, but there's clearly something going on. 3. The only known workaround is to use the DOF "LedWiz delay time" setting. Slowing down the USB messages reduces the likelihood of triggering the LedWiz bug; it doesn't eliminate it, but it makes it happen less frequently, so a long enough delay time makes it infrequent enough not to be bothersome. You can experiment with different delay times to see if you can find a setting that works for you. For a while, a 5ms delay was working pretty well on my system, but the last PinballX update seems to have broken it again even with 5ms, so it may no longer be possible to find a working setting. 4. The DOF version SHOULD make no difference in all of this, but you say that DJRobX's version is glitchy and mine isn't on your machine. This might be because the last official SwissLizard release doesn't seem to be paying attention to the global LedWiz Delay Time setting any more. I added code to my version to obey that. So you might your global settings using a large enough delay time, and it's just not respected in the DJRobX build because of the base version he used.
  3. The live master branch is back to working if you're on the 11/6/2016 commit. SwissLizard rolled back the partial changes that had left things in an inconsistent state, so everything is fully working again in that commit.
  4. It must be some incompatibility in the direct USB communications with the LedWiz, then. i suspect that what's going on is that you have both the old and new DOF DLLs installed, and that PBX is running the old ones while VP is loading the new ones. This would keep them from coordinating their USB access, which could cause symptoms ike these if you can enable logging in both configs, you could check the version number report at the too of the last session in each log to see if this is the case There's actually no need for you to be running this version unless you're using a Pinscape controller. The purpose of this version was to integrate my updates for Pinscape with the latest base code, so if you're using other devices, there's nothing new in this vs the base code.
  5. Binaries are here: http://mjrnet.org/pinscape/dll-updates.html
  6. As far as I've been able to determine, it's based on the same code as the Nov 30, 2015 official DOF release from SwissLizard, with my updates for LedWiz and Pinscape. So it should have no differences for the Pacled64 code.
  7. Interesting. You might try my new version - it eliminates LEDWIZ.DLL and talks to the LedWiz directly. That might make it a little more robust, since it can check for USB communications errors. (http://mjrnet.org/pinscape/dll-updates.html)
  8. Interesting. You might try my new version - it eliminates LEDWIZ.DLL and talks to the LedWiz directly. That might make it a little more robust, since it can check for USB communications errors. (http://mjrnet.org/pinscape/dll-updates.html)
  9. Understood. I'm still curious, though - is it ONLY the knocker that this happens on, or does it happen on all channels?
  10. For what it's worth, I've never encountered this. Are you absolutely sure it's a DOF bug? Do you ever see random misfires of other devices? If the knocker is the only device you've seen do this, I'd suspect a hardware issue rather than DOF. If it's a DOF bug, the misfires would most likely occur on random ports rather than on the same port every time.
  11. Probably not. If it wasn't working the last official R3 binaries from SwissLizard (the Nov 30, 2015 release), it's probably not working in my version either, since I tried to get as close to possible to that release as my starting point. SL's code after that point seems not to work - it looks like he was in the middle of making some additional changes, but didn't finish them and left things in a non-working state until he can get back to them. I'm really glad he saw fit to check in the earlier working version!
  12. Just following up on my own post: I'm going with the last commit on Jan 2, 2016 for now. That looks like it's the closest source to what was in the Nov 30, 2015 public binary release, and it seems to work properly with LedWiz, Pinscape, and the SwissLizard's Teensy controller for addressable LEDs. I've merged all of my latest Pinscape updates and committed everything back to a forked repos on GitHub, and put in a pull request. It doesn't look like SL is actively following any of this right now, so it'll probably remain in this state for the time being, but the pull request and forked repos are there in case else wants to grab my updates. (If you go to the main DirectOutput repos on GitHub, look under "pull requests" to find my updates.)
  13. I know it's been a while, but I'm finally getting around to integrating my updates with the latest you checked into GitHub. Unfortunately, the latest version in source control doesn't seem to be working for me. Should the very latest code in GitHub work, or is that semi-broken work-in-progress code? If it's non-working, do you know the last working version? With the very latest version, it looks like you were in the process of making some changes to clean up the way the unit number property ("Number") is handled in the various output controller classes - adding the onchanging/onchanged event handlers. But it looks like that's incomplete - the Name property changes made in the old Number change handlers were removed and, as far as I can tell, weren't replaced with new code. So the Name never gets set for any of the units, which leads to a null reference exception in the auto configurators when they try to use the Name as a dictionary key. I added back the name change handling for LedWiz and that seems to fix that much, but it makes me suspect that the tip revision might have other issues. Right now I'm trying to help someone get this working with addressable LED strips, and not having much success, so I'm wondering if that problem is related. Any input you have would be most helpful!
  14. I can relate! Wonderful - thanks! I'll check to see if I've made any Pinscape changes since the last ones I sent you, and set up a pull request on GitHub if there are any. Thanks again!
  15. Has anyone been in contact with Swisslizard lately, or has there been any action on getting DOF R3 into GitHub? I've sent Swisslizard a couple of PMs here over the past couple of months and he hasn't replied. His profile says he was last on the site in January, so I'm wondering if he's taken a break from DOF or something. I want to get synced up with him on some DOF updates for the latest Pinscape firmware, so I'm hoping he hasn't disappeared without a forwarding address.
×
×
  • Create New...