9 replies to this topic

[dondi]

I have a PinScape AIO from Oak Micros all setup in the cab and am at the tail-end of the build, tweaking settings and lining-things-out. One of the projects on the cab is an audio jukebox driven by using Kodi and Plane9 Visualizer. Through some crafty startup scripts in PinUP POPPER, this project worked-out nicely. This was done back in March before starting the physical cab build. I left placeholders for integrating LEDBlinky to drive the RGB, 4-wire, non-addressable LEDs & mono-LEDs. LEDBlinky has a function to act as an audio visualizer, animating the LEDs according to audio waveforms. I set this up yesterday and ran-into several roadblocks. Mainly with getting LEDBlinky recognizing the PinScape controller. It really wants to see LEDWiz/LEDWiz-compatible devices, which, PinScape can do. However, I originally setup the PinScape AIO in the config tool as LEDWiz #1 under the USB device setting. While troubleshooting an unrelated issue with DOFLinx, the DOFLinx log was 'complaining' that it 'sees' my controller as a PinScape with three LEDWiz-like devices and the controller should be set to PinScape instead. DDH69 suggested changing the ID to PinScapeID (second from bottom in pull-down) to get rid of the warning in DOFLinx. Harmless, yet it eradicated the warning. All toys, LEDs, feedback etc. working fine. This was the status before LEDBlinky integration.

Yesterday was LEDBlinky day. Getting the flashers, RGB Flippers, three sets of undercab RGBs, all reacting to music coming from Kodi via the audio mix input in Windows OS for the audio waveforms. During this process of setting-up LEDBlinky (actually, very early in the setup process) getting the PinScape controller for access to port assignment was proving impossible. LEDBlinky wanted no part of the native PinScape. I forged-ahead and completed the rest of the setup in LEDBlinky, assigning all relevant ports, getting Kodi recognized as an emulator, designating Kodi as a jukebox for audio animation, etc. Circling-back to the hardware side, I had no LEDWiz.dll files on the system other than the stock file that was contained in the LEDBlinky package. Someone on the VP Chat Discord upped a copy of his. He had success in getting LEDBlinky to link to his PinScape AIO; claiming LEDBlinky sees three LEDWiz 'pages' of ports at 32 each. Makes sense. I dropped this DLL in the LEDBlinky folder, no joy. LEDBlinky still doesn't see the PinScape AIO and its three virtual LEDWiz devices. I then went back to the PinScape Config tool and changed the USB ID from PinScapeID to LEDWiz #1. Voila!!! LEDBlinky is happy and addressing all the RGB toys assigned and all animated to the audio. Here's a video of the success:

 

LEDBlinky, from what it seems, is usually run as a resident service in the SysTray and listens for different emulators, games, commands, etc. I did not set this up in this fashion. My POPPER scripts start and kill the task for the Audio Jukebox sessions, so there is no persistent LEDBlinky process in the background.
The setting-up of LEDBlinky, however, created an issue. When resuming normal pincab activities (even after a reboot and scrubbing-through task manager and MS services looking for any trace of LEDBlinky), DOF seems to have gone mad. Consistent & disturbing behavior; both flippers firing-off Knocker, Shaker motor and gear motor (all three simultaneously). Outer Left flasher blinking from solid blue (port 15) to aqua-greenish (ports 14 & 15). There is evidence of the OuterLeft Flasher 'issue' at the beginning of the video. I had NITE MODE activated (it was late at night), so I didn't experience the knocker/shaker/gear motor issue at the time of the recording. It's definitely DOF getting confused. I gather because of going from being programmed as PinScapeID to LEDWiz #1 in PinScape Config tool. This haywire behavior was present in POPPER front-end as well as in VPX gameplay (although it was difficult to tell the exact goings-on, but is was chaotic - knocker was firing-off like crazy for sure). Anything DOFLinx-related was fine though, as expected. 

I am at a cross-roads and looking for suggestions here. Either ditch the LEDBlinky driving LED animation to the audio in the jukebox (present state of the cab), or get creative about the PinScape hardware and how it can live harmoniously and discoverable by all emulators and applications involved. I prefer the latter, but not sure how to proceed. There is no way to 'switch' its type based on a startup script; not practical and messing with it at the hardware-programming level is just stupid. But as a manual process, I can confirm changing the USB ID between PinScapeID and LEDWiz #1, I do have an either/or situation where the toys related to each case work nicely. Just don't know how to get it to do both. Maybe there is a way to 'hack' LEDBlinky by using the USB Vendor Identifier numbers?? I only installed/used LEDBlinky for the first time ever, yesterday. 

Sorry for the long post, but I believe this details the process and the issue experienced. Hoping for some insightful suggestions, as I'd love to get both conditions to work under one happy cab. 

Edited by dondi, 01 December 2020 - 03:05 PM.

[mjr]

Have you tried setting the Pinscape unit to LedWiz #8?  That's the usual convention to get it out of the way of the real LedWiz, which usually has its ID hardcoded as #1.

[dondi]

Have you tried setting the Pinscape unit to LedWiz #8?  That's the usual convention to get it out of the way of the real LedWiz, which usually has its ID hardcoded as #1.

Ugh, I'm an idiot... sorry @mjr. Totally forgot that I had set the USB ID as LEDWiz #8 on first setup of the cab as per MikePinball's instructions. Totally forgot that bit when troubleshooting LEDBlinky and reverting. 

Quick Question: I may be getting a 'customized' board in the near future. Special, 'unadvertised' project Mike and I working on. Will be an additional PinScape with 128 output ports. During our design discussions, he had reiterated that the AIO be assigned #8 and this new 'special' board #9. Considering the past 2 days and the above issues with LEDBlinky, I'm thinking this new board should get assigned USB ID #11 ?? As of right now, the PinScape AIO 'primary' is 'advertising' LEDWiz devices to LEDBlinky as device IDs 8, 9 & 10. Seems logical that this secondary board get #11 in PinScape Config. Am I thinking about this correctly? These are USB IDs, just not sure what the device IDs will be doing in regards to DOF & DOFLinx, or if it matters. Like, if I assign the secondary board as USB ID#9, I'm guessing in terms of DOF & DOFLinx, the ports #s for toys will still be 100-174 for primary and secondary would be 200-328 (??), but in terms of LEDBlinky, since it only sees groups of 32 ports across multiple LEDWiz-like devices (currently primary is 8,9,10), not sure if the LEDWiz numbers available to LEDBlinky would 'cascade' in iteration numbering; i.e., automatically device #2 (secondary PinScape @ USB ID #9) will automatically 'create' four LEDWiz-like devices starting at device #11.

BTW - The cab is back to full-harmony. Both DOF and LEDBlinky are functioning harmoniously. Thanks @MJR

Edited by dondi, 01 December 2020 - 09:18 PM.

[mjr]

I'm thinking this new board should get assigned USB ID #11 ?? 

 

Exactly right.  Assuming you're using my customized version of LEDWIZ.DLL, the DLL will assign consecutive "virtual" LedWiz IDs to each physical Pinscape unit, according to how many ports it uses.  The LedWiz design only allows for 32 ports per device, so if you have a Pinscape unit with 80 ports, say, it'll require 3 LedWiz IDs to expose the ports: it needs one ID to represent the first 32 ports, a second ID to represent ports 33-64, and a third ID to represent ports 65-80.  To keep things simple, the DLL just assigns the IDs consecutively from the one that's assigned in firmware on the Pinscape device.  So you're correct that your first Pinscape unit with its firmware LedWiz ID set to #8 will use up the virtual LedWiz IDs #8, #9, and #10, and so the next Pinscape device will need to go at ID #11 or higher to avoid conflicts.  You could alternatively set the first Pinscape to a lower LedWiz ID - if you just have a single real LedWiz, it'll be unit #1, so could make your first Pinscape unit LedWiz #2.  The only reason I suggest #8 as the default is that I'm practically certain no one in the whole universe has a real LedWiz called #8, whereas I think there are a few people out there with #2 and #3 units.

[dondi]

Assuming you're using my customized version of LEDWIZ.DLL

I can't assume the LEDWIZ.DLL I got from someone on the VP Discord is the same. When I received it, I put a copy in the LEDBlinky folder and another copy in the C:\Direct Output folder. I'm pretty-sure I had no pre-existing LEDWIZ.DLLs on the system. 

Should I stick with the one I have (seems to be working), or should I grab your customized one (to be sure)? If the latter, where can I get it (mjrnet [DOT] org?), and should I only have one copy on the system to avoid any conflicts from having multiple copies? I think the one local to LEDBlinky is needed for the app locally. 

Thanks again for the help @mjr. Appreciate it.

[mjr]

I can't assume the LEDWIZ.DLL I got from someone on the VP Discord is the same. When I received it, I put a copy in the LEDBlinky folder and another copy in the C:\Direct Output folder. I'm pretty-sure I had no pre-existing LEDWIZ.DLLs on the system. 

Should I stick with the one I have (seems to be working), or should I grab your customized one (to be sure)? If the latter, where can I get it (mjrnet [DOT] org?), and should I only have one copy on the system to avoid any conflicts from having multiple copies? I think the one local to LEDBlinky is needed for the app locally. 

 

You said LedBlinky is seeing the multiple virtual units for the Pinscape board, right?  In that case, you definitely have my version of the DLL, since the regular one doesn't create the virtual units. 

 

So I'd just stick with what you have.  If for some reason you do want to update, look here:

 

http://mjrnet.org/pi...ll-updates.html

 

The location for the DLL varies by program, but in most cases, it should go in the same folder as the program EXE you're running.  So yes, you might have multiple copies scattered around your system by necessity.  You can even use different versions for the different copies if necessary, but I'd avoid it, since it tends to create confusion about what software is actually in use.  A lot of the software issues that people run into turn out to be that they have old/wrong versions of something hidden away in odd corners of their machine.

(My version of the DLL is meant to be a drop-in replacement for the standard version, so even if an app comes with an LedWiz.dll, you should be able to replace that with my version to get its added Pinscape functions.  I don't know of any cases where an app requires its own special LedWiz.dll version to the exclusion of the standard DLL or my DLL.)

[dondi]

Thanks MJR. I have a copy of it in the Direct Output folder. I guess I will regard that as the "master copy" in case I need access to PinScape functionality somewhere down-the-line.

[dondi]

@MJR, think I will continue on this thread with a different issue/concern. I've set the PinScape in USB ID as LEDWiz #8. LEDBlinky is happy. I have now moved-on to dialing-in nudging. In your guide, when bringing-up the Windows USB Game Controller Configuration settings/properties, you show a screen with a Z-Axis and a box for the accelerometer for X- and Y-Axis. I don't get the same visual; I only get 7 buttons. In the PinScape Config tool, I do have ENABLE JOYSTICK checked. My accelerometer (and plunger) actually work in VPX. Not sure if this is an actual hardware issue, or can be, down-the-line. Will be fine-tuning, nudge & tilt for VPX, FX3 and FP, so want to make sure at the start I'm not painting myself in a corner.

My PinScape USB Controller Properties with USB ID set to LEDWiz #8




As a goof, I temporarily set USB ID to LEDWiz#1 and got a different 'look' to the properties window (same 'look' with PinScapeID). It now shows the same as in your guide. PinScape Config bug? Or on purpose? Is the USB information not being sent to Windows when set as LEDWiz #8?

Edited by dondi, 04 December 2020 - 07:41 PM.

[mjr]

For an explanation and solution, see the topic "Buttons/axes are missing in joystick control panel" in the troubleshooting section:

 

http://mjrnet.org/pi...troubleshooting

[dondi]

Thanks @MJR. That worked nicely. I assume that running it prior to the fix was not an issue, or no? Everything, as far as I could tell, was working fine. Just no visual feedback in the Win controllers screen.