I'm Brian Madden, one of the guys (along with Gabe Knuth) who's writing the Mission Pinball Framework (MPF). Sorry I'm a bit late to this thread. I haven't been following it recently as I figured it was just more of the same. (I hung in there for the first few thousand posts.
Anyway, to answer some questions people specifically asked us (in random order):
Rosh is correct, the Big Shot EM conversion we brought to Expo last year used a P-ROC with P-ROC driver boards.
MPF is open source (via the MIT license), meaning anyone can do whatever they want with it. So just because a project is using MPF doesn't mean that Gabe or I are involved. (Well, I guess we would be by association since we're writing MPF, and certainly we've prioritized certain MPF features over others based on requests from users, but there are lots of people building projects with MPF now.)
So the question about whether anyone involved in MPF has ever written a complete, fully-featured DMD-based pinball machine sort of depends on what you mean by "involved." I can answer that neither Gabe nor I have. But again, there are lots of people downloading and starting to build games with MPF, so I don't know what the experience level is with everyone.
MPF is hardware agnostic with a pluggable platform interface which can be used to connect to different types of controller hardware. Gabe and I have written platform interfaces for the Multimorphic P-ROC and P3-ROC, and the FAST WPC and Core controllers.
If a new hardware platform just materialized in front of us and someone said, "I want MPF to work on this," then we (or they?) wouldn't have to redo everything from scratch, rather, we'd just have to write the platform interface for MPF for that hardware. Gabe and I have focused our efforts on what's most useful for the community which is why we've only written platform interfaces for publicly-available hardware, but I know of at least one other open source hardware project where they are working on a platform interface for MPF, and we've received emails from a few other people asking about MPF on their hardware. Again, since it's open source software, so we don't know exactly what everyone is doing.
We release new versions of MPF every 3-4 weeks. The current version is 0.14 (the 14th release), though 0.15 is done and available in GitHub and we're just working on updating the documentation for it which will be done in a few days. (We're crazy about documentation. Currently we have over 600 pages of explanations, tutorials, how-tos, references, etc. The main documentation lives at https://missionpinball.com/docs, and the API reference is at http://mpf.readthedocs.org/ .)
We started MPF in June 2014, so we're 9 months in. The feature list of what we have done is here: https://missionpinball.com/docs/introduction/current-features/. Since we iterate rapidly, any statements about what MPF is missing are only valid for a month.
Rosh is correct that we're aiming for a "1.0" release this summer. That was an arbitrary date. To be honest, the whole version numbering is pretty arbitrary. I mean really how do you say something is "1.0," especially when you have enough ideas for 5 solid years of programming and you release a new version every few weeks? (Our multi-year idea list is here: https://missionpinball.com/blog/2014/10/the-mission-pinball-framework-roadmap-vision-for-the-future-of-pinball/ ) And of course just because we call it "1.0" doesn't mean it won't have bugs, and it doesn't mean that "1.0" is any more permanent than 0.18 or whatever was right before it, since I'm sure we'll have 1.1 a month later. But we appreciate that 1.0 is a big mental step for people, so that's why we decided to make it a goal.
Speaking of goals, we have two main goals for MPF: (1) To create a complete framework that allows for the rapid creation of games, and (2) to allow non-programmers to create their own games (whether they're updated software for existing machines or full custom machines).
The "non-programmer" thing is pretty huge for us. We believe that 95+% of a game's code can be handled with MPF's text-based config files, including scoring, modes, objectives, game logic, light shows, sounds, display, animations, effects, multiball, etc. Seriously, a lot of stuff in pinball machines-- even JPOP’s and new LCD ones--are about 99% identical. (Like the difference in DNA between a human and a chimp.) Our claim that you can do 95% of a machine with text-based config files is something that a lot of people don't believe. Our response? We're fine with it. We just try to keep our mouths shut and our heads down. Frankly we don't need to worry about this because we're not selling anything. MPF is open source, so if people don't like it, ok then. They don't have to use it. (Plus my favorite pinball machine is Road Show, so I'm already comfortable with people not agreeing with me.
As a side note, the "LCD versus DMD" complexity is an issue for the artists and animators and affects the computer power you'd need in the machine. It doesn't make a lick of difference for the programmer. From the programming standpoint it's just elements on a display, and the way you handle layering, movement, transitions, decorations, fonts, etc. is identical for both types of displays. Same for RGB LEDs versus single color lights. RGBs are more work for whomever's designing the light shows and lighting effects, but it doesn't make a difference to the programmer or MPF.
Anyway, I agree with Ben about a full pinball OS (or whatever you want to call it) taking 17-18 months. The good news with MPF is that everything we've done in MPF already counts towards that. So if someone started completely from scratch today and chose to use MPF, they could have their game completely done in a few months. (And again, if people don't believe that statement, that's fine, I won't argue.)
Speaking of time, I've been working on MPF full time since last June. My professional background is in IT, though I love pinball programming. That said, I understand the realities of the pinball industry and don't relish the thought of trying to make my money from pinball and hopping from project to project, wondering if I'll get paid or where the next meal will come from. So instead, I've simplified my IT life so that I now do contract IT work two days a week, leaving three days to work on MPF. (I call it "full time" because I spend 40 hours a week on it. Typically 12 hours on my three non-IT work days, and usually another 12 hours on the weekend.) I do not view this as temporary. Between Gabe and I, we spend 50-60 hours per week, every week, working on MPF. We love it so much that we don't want it to end which is why we're excited that we have 5 years of ideas.
It's true that we haven't written a complete game in it, but that's more because we're spending our time actually writing MPF itself. I think at this point MPF has been run on at least ten different machines. The hard part of pinball software is not the actual programming, rather, it's doing the complete game and rules design, and it's putting together all the assets. (Designing the actual light and flasher shows, building the animations, recording and editing the sounds.) But once that's done, the programming is just linking it all together. And once you make one mode, you can make 20.
Whenever I say this, people (who tend to be non-programmers) always protest, "What about this weirdo device or that crazy mode?" But so far I haven't seen anything that can't be figured out pretty quickly. MPF is very pluggable, so when we come across something that's weird, we write a few lines of Python code to handle it. That's the "other 5%" of the 95% of stuff that can be done in text-baed config files. Example: The crane unloader for the Deadworld in JD. There's no "standard" MPF device for that, but we have motor and magnet support, so it was just about 20 lines of Python code to override the Deadworld ball device's eject() method with one that uses the crane, and boom, done. Took an hour.
If a brand new machine that I had never seen before showed up at my door (assuming the hardware was hooked up), it would literally only take a few hours to have a game running on it. I don't mean just having flippers flipping and knocking a ball around--I'm talking an actual playable game. Players, shots, scoring, DMD and/or LCD with lots of real info, etc. Give another few hours and we can make some light shows, and another few hours and we can make some modes.
In fact, I will put my money where my mouth is there. I just picked up a Demolition Man this weekend. It's stock, and I haven't written line one of config for it for MPF. Once we finish up the documentation for 0.15, I'll spend one full day with it to see how far I can get and I'll blog about it and post videos and stuff. (So let's say next week for that.)
Anyway, to tie this back to JPOP, I guess my point is that if he does decide to go with MPF, someone (whether it's us or someone else) can have his machine legitimately running very quickly. (And if he chooses a hardware platform that's already written and tested for MPF, then it's even faster still.) Of course whether JPOP uses MPF and what hardware he chooses is up to him and his team. Frankly I don't care either way, I just really really really want to see those games get built since they look sick.
Sorry for the crazy long email. Back to 0.15 documentation for me!