Improve Ensoniq VFX-family display

[cbrunschen]

This adds a layout for the NEC FIP80B5R display as used in various Ensoniq keyboards; this layout is based on traced segments from photos of an actual display.

Before:

After:

Photo of real display:

It also refactors the display & panel classes used by the VFX family of keyboards, consolidating display command processing into a single place.

This makes minimal changes to related display & panel classes for other related keyboards, so as to not disturb in particular the recent excellent changes to the ESQ1 (and SQ80) keyboard panel, which inspired me to try to start some improvements for the VFX family as well.

[happppp]

IMO commits in esqpanel related to the web interface and the attached javascript file should be limited to life support (eg. fixing a critical bug) or gradually removing things. I hope MAME will eventually have internal artwork (.lay files) for these and the web interface can be removed. Maybe even emu/http.* can be removed too if we have no use for it anymore.

Regarding adding digit segment SVGs to MAME:
Are/were these intellectual property?
If we're going this direction, better increase the thickness of the segments to compensate for lack of brightness. As you can see in your example screenshot, it's less readable than the real thing.

[cbrunschen]

IMO commits in esqpanel related to the web interface and the attached javascript file should be limited to life support (eg. fixing a critical bug) or gradually removing things. I hope MAME will eventually have internal artwork (.lay files) for these and the web interface can be removed. Maybe even emu/http.* can be removed too if we have no use for it anymore.

I disagree: I find the web interface to be very useful. It allows someone to simulate these keyboards in a way that basically matches how one would use the real thing: with a PC running the emulator, a MIDI keyboard for the, well, keyboard input, and the control control panel available through the web interface on a tablet together with the MID keyboard.

Accessing the control panel in the web browser can be done on a phone or tablet that has a multi-touch capable display, even when people don't have a touch-capable main screen, so that makes it that much more accessible to actually use.

And the Ensoniq VFX family of keyboards certainly have button press combinations that are fairly far apart: "Preset" + "Compare" is used to show analog values, for example. So as I don't have a touch screen on my PC where I'm developing this, I can bring up the web interface in my phone to access that button combination that I would otherwise be unable to press.

Regarding adding digit segment SVGs to MAME: Are/were these intellectual property?

I took photos of the display on my keyboard, converted them to monochrome, and traced them myself.

They are also the same segments already used in the web panel.

I actually think their specific shape seems to be largely the result of the manufacturing process, rather than a specific design: if you look, the empty space between the segments is pretty constant. It looks like someone effectively looked at a character cell, and drew thick lines separating the segment, leaving the rest as the actual segments to be lit up.

If we're going this direction, better increase the thickness of the segments to compensate for lack of brightness. As you can see in your example screenshot, it's less readable than the real thing.

The brightness in the photo is rather exaggerated due to lighting and my phone camera.

I actually did some experiments when I first added the web interface, stroking the segments as well as filling them when they were lit (see https://github.com/cbrunschen/mame/blob/master/web/esqpanel/vfx/FrontPanel.js#L243); but it ended up looking wrong when compared to the real display.

[Lord-Nightmare]

I thought about this with the very similar NEC FIP8A5AR display in the external SVG artwork for the Texas Instruments Speak & Spell by adding a partial alpha 'bloom' around each segment (which would turn on, per segment, at the same time that specific segment did), sort of like:

but I don't think I ended up going that route in the end.

[cbrunschen]

Here's a picture of the display in a more representative lighting level and from a more oblique angle (such as when actually standing at the keyboard to play it)

Even here, it comes across as a lot brighter in the photo than it appears in person. Even then there's very little bleeding of the light emitted by the segments outside of the segment boundaries.

The way the display is now is the closest I've been able to get it to what I experience when I use the actual keyboard. And that includes the colour: in real life, it looks more green and less blue than in the photos.

Bloom etc are also things I'd be happy to revisit after this is in place and working.

Regarding the web interface, I'd also like to add that it offers two more useful things:

1. multiple concurrent remote connections
2. panning and zooming

The multiple connections are synchronized: they show the same state, even offering visual feedback about what controls are being used on other interfaces. And they can be remote connections, which allows the actual surface you interact with to be somewhere other than on the device where mame is running - such as, as mentioned, on a phone or tablet attached to the MIDI keyboard being played.

Beyond that, within any given browser window, the user can zoom in or out, and pan the view to show all or just a selected part of the panel.

These are useful - I'd even say, important - because of the form factor of these synthesizer front panels: they use the space above the keys which is limited in depth, but offers a lot of width.

The two features above make it not just possible, but easy, to use multiple smaller devices - a couple of phones or tablets for instance - each zoomed and panned to show part of the panel, and allowing the user to interact with both of them, keeping everything in sync. They can put these right within reach, in any available space by or on the MIDI keyboard they're playing - giving full access to the front panel controls of the emulated synthesizer.

Without these, a user needs to have sufficient-large wide-aspect-ratio touchscreen display(s) connected directly to the PC on which they're running mame, and have that combination of displays within touchable reach of the MIDI keyboard they're playing.

So to me, the web interface adds some very useful functionality that I consider quite important for how I want to be able to use these synthesizers in mame. And I'm very much not in favour of removing useful functionality.

[cuavas]

I don’t want to be going down the path of bundling images for specific display models. I’d rather keep the internal stuff generic and allow people to provide more precise representations of specific models in external artwork if they want to.

The current internal web server implementation (actually the second iteration) is problematic in many ways. But a big problem with system-specific stuff in it right now is that it’s effectively unmaintained, and hence likely to rot. It’s too far outside what most MAME developers are going to test, so realistically, it won’t be updated for code changes.

[cbrunschen]

Here's an update that replaces the nec_fip80b5r layout with a more generic esq2by40_vfx one that nevertheless correctly lays out the spacing of the characters within the display. It uses an led14seg element for the 14 segments and a separate disk for the dot / decimal point, rather than using led14segsc which would add an incorrect 'comma tail', as well as a separate underscore.

[cbrunschen]

The main aim of the refactoring for the VFX family was to consolidate the panel command processing into the esqpanel2x40_vfx class and thus simplifying the esqvfd2x40_vfx class. Analogougsly I also removed the essentially duplicated command processing from the FrontPanel.js code.

But in order to not remove functionality that I'm currently using, the ability to interact with the emulated keyboard, i.e., to prevent breakage of something that was fundamentally working, FrontPanel.js has to be able to handle some simpler, lower-level instructions from esqpanel2x40_vfx.

That's all that I'm doing to the web interface. It doesn't change the level of integration. If anything, the lower-level instructions would be easier to implement in something other than a web interface, since they don't require the command processing that has now been consolidated into the esqpanel2x40_vfx class, and thus would make it easier to replace the current web-based remote interface with a different one.

[cbrunschen]

I've updated this to replace the web interface with a much simpler external panel device, which runs a small asio-based server thread that allows connecting a single external device and which uses a simple text-based protocol; this is heavily based on the cps2comm device. This removes the dependency on the http server from the Ensoniq keyboards.

Separately I have a small project that talks to this new external panel and presents the web interface, as a working proof of concept as well as for my own actual use. Once these changes land I will of course make that available (and am happy to share privately before that, too).

[cbrunschen]

Some more updates that might please some:

Layout-based front panels.

Spacing of elements etc based on measuring my real VFX-SD and SD-1/32.

VFX:

VFX-SD:

SD-1 (also SD-1/32):

These work together with the external panel (which is no longer web based, as before), such that each shows any buttons that are pressed the other, and of course also the Volume and Data Entry sliders.

The panels are similar but different enough that I actually write a small program that can generate all three variants.

Any comments would be greatly appreciated.

[felipesanches]

Wow! These are looking amazing!

[felipesanches]

And, to be honest, it was the very first time I was able to try playing music with these drivers and they sound fantastic as well! When they lacked internal layout, they were counter-intuitive to use and the web front-end was too hard to setup (I remember I had tried and failed!).

Don't get me wrong! I think the web-based UI has its legitimate uses as you already described, and we should not close that door. But having functional internal layout is more important, so that more people can easily use it. And I see this PR moving in the right direction. Great work being done here!

[cbrunschen]

I'm glad you like the panels! I do too.

I've never had any trouble accessing the web frontend: I build MAME, run one of the VFX-family of keyboards with the -http flag , and then point a web browser at http://localhost:8080/esqpanel/FrontPanel.html which is where the esqpanel class serves its HTML.

simplescreenrecorder-2025-09-16_19.41.17.mp4

But be that as it may, this PR now removes that integration so the point is rather moot. I can understand not wanting MAME to include something as unrelated as an entire web server.