Author Topic: Announcing: a Graphical switch sender and lamp visualizer (for OSC mode)  (Read 10475 times)

MOcean

  • P3 Developers
  • *
  • Posts: 822
  • Michael Ocean
    • View Profile
Re: Announcing: a Graphical switch sender (for OSC mode)
« Reply #15 on: December 30, 2014, 06:58:42 PM »
I'll say that exporting out of VP tends to produce distorted images, but those on in the download section seem to be "clean" scans, prior to the aspect distortion that is "needed" for/by VP.

Curbfeeler

  • Wizard
  • *****
  • Posts: 239
  • Dan - Des Moines, IA
    • View Profile
Re: Announcing: a Graphical switch sender (for OSC mode)
« Reply #16 on: December 30, 2014, 07:35:33 PM »
Ahh, that's true they are squatty, but the one time I stretched one in GIMP (F14) it actually looked pretty nice.  If your game is out on the downloads section, though, that's the best as Michael says.

MOcean

  • P3 Developers
  • *
  • Posts: 822
  • Michael Ocean
    • View Profile
Re: Announcing: a Graphical switch sender (for OSC mode)
« Reply #17 on: December 30, 2014, 08:57:16 PM »
I committed an update that fixes an issue on OSX for machines with a large number of switches (greater than 72).  It works on Windows, but OSX was picky.  Thanks to Rosh for discovering the issue (as always).

Mark Jarzewiak

  • Wizard
  • *****
  • Posts: 244
  • Mark Jarzewiak
    • View Profile
Re: Announcing: a Graphical switch sender (for OSC mode)
« Reply #18 on: December 30, 2014, 09:29:33 PM »
Thanks for pointing that out.  Never looked in the other download sections over all these years!

MOcean

  • P3 Developers
  • *
  • Posts: 822
  • Michael Ocean
    • View Profile
Re: Announcing: a Graphical switch sender (for OSC mode)
« Reply #19 on: December 31, 2014, 09:35:24 AM »
Lamp support is coming ..maybe sooner than I first anticipated.

Would people rather a new mode to add to their game or that I change Brian's OSC mode to also support sending lamp data?

Mark Jarzewiak

  • Wizard
  • *****
  • Posts: 244
  • Mark Jarzewiak
    • View Profile
Re: Announcing: a Graphical switch sender (for OSC mode)
« Reply #20 on: December 31, 2014, 10:18:25 AM »
Not sure I should make a suggestion since I haven't yet set this up but I'd think adding to the OSC mode made the most sense. 

Brian Madden

  • Wizard
  • *****
  • Posts: 498
  • Mission Pinball
    • View Profile
    • Mission Pinball
Re: Announcing: a Graphical switch sender (for OSC mode)
« Reply #21 on: December 31, 2014, 10:58:17 AM »
Yeah I'd be all for extending the OSC mode to support lights & drivers, both for reading and setting. I was thinking ultimately OSC could also be used to read audit data, read & set operator settings, etc. Then you don't need a service mode.. you can use an app (mobile or desktop)!

We have some of this in MPF's OSC mode (read/write switches & lamps, read audit data) if any of that helps:

https://github.com/missionpinball/mpf/blob/dev/mpf/plugins/osc.py

Also it would be cool for the desktop app to support colors for lights. If it's a traditional lamp, then it would be cool to set the color in the desktop app. Ideally this would be something that you'd set in the machine YAML file.. like a "color: ff0000" for lamps that the desktop app could read.. that way the data would be there for other future uses. Then also if this was used with RGB LEDs, the desktop app could show the proper color.

The the OSC interface could just use a "light" address, like /light/shootAgain and the data could be a string of the hex color. Reading that data would just be the color that the OSC Server sent. Writing it would just put the RGB hex color for LEDs, and if writing to a lamp it could be something like "off if 000000", "on if anything else"

Maybe we should start a new thread to discuss a formalization of the OSC interface? It would be great if MPF and pyprocgame used the same OSC addresses and data settings so apps like this worked for both. I'm planning (haven't started yet) to write a proper mobile app which uses OSC to communicate to an MPF machine, so if the OSC interface matches on both then it could be used for both (as well as this desktop app, obviously.)

@MOcean, I would volunteer to handle the OSC interface side of things for pyprocgame if you want to handle the desktop app. The only catch for me is today I'm wrapping up MPF 0.1.2 which will include all the DMD and display stuff, but then I'm out for a few days. I could get to it this weekend though.

In MPF you can add handlers to any device (kind of like switch handlers), so getting updates of light status changes to the OSC module is as simple as the OSC module registering handlers which are notified of changes to lights. I'm not sure how that would work in pyprocgame but I'm open to ideas? (I'm sure it's not a problem.. I just haven't thought about it yet.) I guess worst case we could monkey patch lamp methods? Is that even allowed in real programming? :)

Also receiving light data has the potential to be a lot of traffic. Well, all the messages are short and it's UDP, but if you have 60 lights and an active light show, you can imagine hundreds of updates per second. So I think we'd also want to make it so there are OSC addresses which can be used to configure what's sent? Like /config/enable-light-messages or something with the data being how many you want per sec?
Brian
The Mission Pinball Framework (MPF) Project*
Twitter
* Disclaimer: MPF is a work-in-progress!

Brian Madden

  • Wizard
  • *****
  • Posts: 498
  • Mission Pinball
    • View Profile
    • Mission Pinball
Re: Announcing: a Graphical switch sender (for OSC mode)
« Reply #22 on: December 31, 2014, 10:59:16 AM »
Oh and to be clear, if you want to extend the OSC interface for lights, please.. go ahead!! :) I'm just saying I can volunteer to do it if you want, but not until this weekend.
Brian
The Mission Pinball Framework (MPF) Project*
Twitter
* Disclaimer: MPF is a work-in-progress!

MOcean

  • P3 Developers
  • *
  • Posts: 822
  • Michael Ocean
    • View Profile
Re: Announcing: a Graphical switch sender (for OSC mode)
« Reply #23 on: December 31, 2014, 12:24:20 PM »
Thanks, Brian.

I agree that if there's an OSC-protocol for pinball machines it would be in the common best interest to make sure both are the same.

I already have some proof-of-concept code that reads the lamp states out of the fakepinproc module, and builds OSC messages from them.  It works within a mode, no monkey patching; it's an on-demand pull of the driver states.  It's easy, especially if you've spent as much time with the Visual Pinball-PROC bridge as I have --I learned quite a few tricks from that code :)

I'm not sure I'd buy into an OSC mode replacing the service menu; I think a lightweight web-server is the correct answer (and I'll admit to starting code for that once, then abandoning it).

The addresses do need to be figured out. Re-reading the OSC-spec, I'm not sure the addresses quite right if we are allowed to get and set values.  I would think an address that made explicit get/set would be a bit more clear, unless omitting the value makes explicit that the client is asking and not telling. 

For the " bandwidth" issue, my thoughts thus far:
the client will request the lamp states and therefore set the rate.  A request of /lamps/set_sequence should define to the server the order the lamp states should be received in (theoretically, this could be a partial list of lamps) and the server will respond to /lamps/ by sending back all the lamp states for those in the sequence, in the same order.

I may hack this in sooner than later, since I can't really test the client until the server is done, and the stub I would write to test the client would be no more complicated to write than the real server at this point.  Oh, and I know I'm using client/server in the non-OSC sense.  Since now both the client and the server will require an osc-client and an osc-server...


- Michael

Brian Madden

  • Wizard
  • *****
  • Posts: 498
  • Mission Pinball
    • View Profile
    • Mission Pinball
Re: Announcing: a Graphical switch sender (for OSC mode)
« Reply #24 on: December 31, 2014, 12:48:23 PM »
Oh man.. so many awesome ideas here.

Ah, yeah having your code poll the lights makes sense.. especially since you can then vary the rate it sends data and you can still filter to not re-send duplicate states and stuff.. So yeah, that is way way better than what I said. :)

For a service menu, yeah, I guess a web server makes more sense because you can still have a REST API for reading & writing settings but you'd also be able to have it serve up pages with the UI all done. Like a Linksys Router. I like it! Operator Settings in pyprocgame are saved in a YAML file, right? If so I would imagine that whatever I do for MPF could be made to work with pyprocgame? (Well, at the end of the day I guess as long as the settings are in a Python dictionary then it should be no prob.)

Anyway, for the specifics of the "pinball spec" for OSC, I'll support whatever you want to do there. Totally makes sense for different addresses to get and set, or, like you said, something like /sw/switchname is the getter and /sw/switchname/set is the setter.

So I guess, man, yeah, this is awesome. Let me know if I can help.
Brian
The Mission Pinball Framework (MPF) Project*
Twitter
* Disclaimer: MPF is a work-in-progress!

Snux

  • Wizard
  • *****
  • Posts: 779
  • Mark Sunnucks
    • View Profile
Re: Announcing: a Graphical switch sender (for OSC mode)
« Reply #25 on: February 22, 2015, 09:18:09 AM »
OK, so this is officially cool in my game too now :)

I'd be happy to help with driver testing if it gets that far....
F14 Tomcat - Second Sortie

MOcean

  • P3 Developers
  • *
  • Posts: 822
  • Michael Ocean
    • View Profile
Re: Announcing: a Graphical switch sender (for OSC mode)
« Reply #26 on: February 22, 2015, 04:54:43 PM »
Sorry this has been a low priority. Almost everything has taken a back seat to insane amounts of snow (and ice and ice dam damage to my house... and digging snow in my backyard all day today to try to protect my basement from when all this stuff melts). Really it's been one thing after the other.  If you haven't seen pictures, those of us in the metro west Boston area have an insane amount of snow here. 

I was pretty far along on this before I paused this for work on the new HDVGA code. Seriously every new shiny thing distracts.

I have code to report lamp and driver states back to the client and I think I had code on the client to receive and layout lamps. A weird thing I ran into was that I was running a Very old version of Brian's OSC mode, so when I went to compare with the latest I realized it would take some time to put my changes into his latest and greatest.

I'll look into this again, soon.

Mark Jarzewiak

  • Wizard
  • *****
  • Posts: 244
  • Mark Jarzewiak
    • View Profile
Re: Announcing: a Graphical switch sender (for OSC mode)
« Reply #27 on: February 22, 2015, 08:15:14 PM »


I have code to report lamp and driver states back to the client and I think I had code on the client to receive and layout lamps. A weird thing I ran into was that I was running a Very old version of Brian's OSC mode, so when I went to compare with the latest I realized it would take some time to put my changes into his latest and greatest.

I'll look into this again, soon.

Looking forward to it as I think I'll be using this for development, once I get things running as is.

MOcean

  • P3 Developers
  • *
  • Posts: 822
  • Michael Ocean
    • View Profile
Announcing: a Graphical switch sender (for OSC mode)
« Reply #28 on: March 05, 2015, 04:31:45 PM »
I made a little bit of progress on this over the last few days; lamps are in the layout format now, they appear on the playfield, and can be moved in the gui just like switches (or manually by changing the layout file)

I've got a "request lamps" osc message (/lamps/get) coming from the OSC switch tester every 33ms or so and my osc mode has been adjusted to include responding by sending the states of all the lamps with the state being read from either FakePinProc or real PROC (/lamps/name 1 or 0 indicating on or off).

I'm noticing that the 'branch' (ie, touchosc tab number) part of the address that Brian sends back for TouchOSC really breaks down the logical namespace parsing behavior, so I'm not sure how to proceed on that front. I'll need to test these changes against TouchOSC and probably diff my version to his to ensure that I'm supporting all the latest features in his current OSC mode (again, the one I've been using is quite old).

Technically lamp colors (on and off) can be changed in the layout  file, too. I guess I could allow for size and shape. Right now they're all the same shape and size (circles of 20px diameter) --now that I think about it, on retina display that won't be so hot.  Maybe lamp size will be a system wide parameter.

Anyway, I'll have a version to share with everyone soon. I still have bugs I'm ironing out.  It's cool to see the lamp shows running in the touchosc gui. I'm only visualizing lamps, not flashers or coils ...at least for now, though I had a nice idea for gradually fading the fill color of the driver shape back to its off color so you can actually see when it's been pulsed.... Anyway...

After this is totally done, next up on the roadmap would be to turn this functionality into some sort of graphical lampshow editor.
« Last Edit: March 05, 2015, 04:33:42 PM by MOcean »

Brian Madden

  • Wizard
  • *****
  • Posts: 498
  • Mission Pinball
    • View Profile
    • Mission Pinball
Re: Announcing: a Graphical switch sender (for OSC mode)
« Reply #29 on: March 05, 2015, 08:41:07 PM »
@MOcean: If you want to propose a new design for the OSC message / address format, then I can update the OSC mode code to match. (I mean feel free to edit my code for me fine by me! :)

We can talk off list if you want. brian@missionpinball.com. Off the top of my head I can't remember what the "branch" thing is, but that whole OSC mode was thrown together pretty quickly, so if there's anything I can do which will help you then I'm up for it.

I'll also update the OSC plug-in for MPF so it matches whatever you want to do. That way any tools you build will work with MPF and pyprocgame.

Brian
Brian
The Mission Pinball Framework (MPF) Project*
Twitter
* Disclaimer: MPF is a work-in-progress!