Adding a layout for Ensoniq ESQ-1. #14049

felipesanches · 2025-08-12T22:02:13Z

It can play notes by clicking on the keyboard.
Volume and Data Entry sliders are hooked up via Lua scripting.
Volume slider still non-functional. Data Entry slider works fine.
SVG snippets were kept to the absolute minimum (drawings of envelope and oscillators diagrams)
The full unit was drawn, but only the relevant part is visible on the default layout. We may later add other views such as "Full keyboard".

Before

After

src/mame/ensoniq/esq1.cpp

- It can play notes by clicking on the keyboard. - Volume and Data Entry sliders are hooked up via Lua scripting. - Volume slider still non-functional. Data Entry slider works fine. - SVG snippets were kept to the absolute minimum (drawings of envelope and oscillators diagrams) - The full unit was drawn, but only the relevant part is visible on the default layout. We may later add other views such as "Full keyboard".

felipesanches · 2025-08-13T08:24:49Z

The octaves are wrong! I'll reassign the midi note values to fit the correct range.

…tave higher.

Because PORT_GM_* replaces them.

src/mame/layout/esq1.lay

cuavas · 2025-08-13T15:59:27Z

src/mame/layout/esq1.lay

+	<element name="white_rect">
+		<rect><color red="0.83" green="0.86" blue="0.83" /></rect>
+	</element>
+
+	<element name="grey_rect">
+		<rect><color red="0.2" green="0.2" blue="0.2" /></rect>
+	</element>
+
+	<element name="dark_grey_rect">
+		<rect><color red="0.13" green="0.13" blue="0.15" /></rect>
+	</element>
+
+	<element name="panel_sheet">
+		<rect><color red="0.17" green="0.17" blue="0.18"/></rect>
+	</element>
+
+	<element name="screen_border">
+		<rect><color red="0.05" green="0.05" blue="0.05"/></rect>
+	</element>
+
+	<element name="invisible-rect">
+		<rect><color red="0" green="0" blue="0" alpha="0"/></rect>
+	</element>
+
+	<element name="black-rect">
+		<rect><color red="0.0" green="0.0" blue="0.0"/></rect>
+	</element>


You should avoid making separate elements for things that are the same thing in different colours. It’s more efficient to use a single white rectangle and colour it when instantiating it.

Maintainability over efficiency here, I'd say.

<element ref="descriptive_rect"><bounds x="0" y="0" width="10" height="10" /></element> <element ref="rect"><bounds x="0" y="0" width="10" height="10" /><color red="0" green="0" blue="0" /></element> 

yeah, my rationale was exactly what @happppp described here. The handling of colors in the .lay schema is quite insane. In the near future I'd like to propose improvements for a version 3 with better ways to author layouts and better color declarations are one of the things I would include.

@cuavas, what do you think?

cuavas · 2025-08-13T16:02:52Z

src/mame/layout/esq1.lay

+		<element ref="white_rect"><bounds x="0" y="20" width="9" height="1"/></element>
+		<element ref="white_rect"><bounds x="0" y="29" width="9" height="1"/></element>
+		<element ref="white_rect"><bounds x="0" y="38" width="9" height="1"/></element>
+		<element ref="white_rect"><bounds x="0" y="47" width="9" height="1"/></element>
+		<element ref="white_rect"><bounds x="0" y="56" width="9" height="1"/></element>
+		<element ref="white_rect"><bounds x="0" y="65" width="9" height="1"/></element>
+		<element ref="white_rect"><bounds x="0" y="74" width="9" height="1"/></element>
+
+		<element ref="white_rect"><bounds x="38" y="20" width="9" height="1"/></element>
+		<element ref="white_rect"><bounds x="38" y="29" width="9" height="1"/></element>
+		<element ref="white_rect"><bounds x="38" y="38" width="9" height="1"/></element>
+		<element ref="white_rect"><bounds x="38" y="47" width="9" height="1"/></element>
+		<element ref="white_rect"><bounds x="39" y="56" width="9" height="1"/></element>
+		<element ref="white_rect"><bounds x="38" y="65" width="9" height="1"/></element>
+		<element ref="white_rect"><bounds x="38" y="74" width="9" height="1"/></element>


This isn’t a good idea – each of these will be composited as an additional textured quad. It’s a lot more efficient to make a single element to represent these tick marks so it’s composited as a single textured quad for all of them. In fact, you should put as much of the slider as you can in a single element to reduce the amount of geometry you’re pushing around.

Remember MAME still thinks immediate mode is cool, so this overhead adds up quickly.

Would using <repeat> here help? Or would it still be the same issue?

Remember MAME still thinks immediate mode is cool, so this overhead adds up quickly.

Maybe it is clear to you because you know about some internal implementation detail, but I fail to comprehend the meaning of this sentence. What is the thing you refer to when you use this "immediate mode" expression?

Let me take the opportunity to mention that I think sliders should be supported natively by the layout system. The current approach of building our own slider all the time by copy-pasting the same lua script everywhere we need it is a mess. It is very error prone and it is not a joy for layout authors.

This demonstrates that there's a need for the feature. And also that it would be useful to have a way to include external scripts and then we could maintain a small library of useful reusable things (like the slider script and also external assets such as SVG files - as described by @rb6502 and others at #12735 (comment)).

Believe us, we know. It is, as is often the case, more complicated that it should be to add.

Some time ago, I sent a proposal for how to share slider functionality (#13414), based on @galibert 's suggestion here. At the time, it was deemed better to just copy-and-pate, since the proposal was not compatible with the future plans for layouts.

This is up to the MAME team. But if there is appetite to revisit the approach above, since the number of layouts with sliders has increased, or if there are suggestions for how to make the proposal "less incompatible" with the future, let me know.

For reference, "immediate mode" means you generate draw commands and send them to the GPU naively as you go. This is bad among other reasons because you're potentially incurring DMA setup and teardown time for each command instead of just having it all-at-once. The alternative is "retained mode" where the commands are put into a scene graph and the CPU does a pass to generate an optimized display list from the results.

For reference, "immediate mode" means

Thanks for the clarification!

This isn’t a good idea – each of these will be composited as an additional textured quad. It’s a lot more efficient to make a single element to represent these tick marks so it’s composited as a single textured quad for all of them. In fact, you should put as much of the slider as you can in a single element to reduce the amount of geometry you’re pushing around.

Remember MAME still thinks immediate mode is cool, so this overhead adds up quickly.

@cuavas, I understand that you are worried about hypothetical performance issues, but how would you measure it? Do you have suggestions for any profiling / performance measurement tool that could give us a concrete evidence of this specific snippet in the ESQ1 layout causing performance issues?

I have run the driver with the layout as described in the PR and I do not perceive (subjectively) any performance issue.

There are roughly a bit more than 300 elements in this layout. Why would these elements from the slider be more problematic than all the other ones?

Also, the layout in this PR makes the driver extremely more useful than it is in its current state at git master. In my opinion, its usefulness outweighs any hypothetical performance concerns. Especially when such performance issue seems to not even be measurable.

cuavas · 2025-08-13T16:04:08Z

src/mame/layout/esq1.lay

+	<!-- TODO: SVG images for the logos
+		<element name="ensoniq_logo"><text string="ensoniq"><color red="0.83" green="0.86" blue="0.83" /></text></element>
+	-->


You aren’t going to be able to do this with reasonably human-readable SVG. It’s not going to go in an internal layout. There’s no point having a TODO for it.

Trademark issue anyway if MAME adds it in the source, and claims CC0.

Cool. But could we leave the comment as a tip to external layout authors?

The version of the Ensoniq wordmark from this era expired long ago. Creative has kept a different Ensoniq wordmark active (last renewed 2016), but it's visually different and the last Ensoniq branded anything was 2002. So I'm not worried about trademark here.

That said, the human-readable SVG thing is real, so this isn't a TODO. I don't have an issue with it being a comment, just having it marked TODO, which has a specific meaning in MAME.

Cool. The TODO is not there anymore. It was removed on an amended commit pushed here a couple days ago.

The version of the Ensoniq wordmark from this era expired long ago. Creative has kept a different Ensoniq wordmark active (last renewed 2016), but it's visually different and the last Ensoniq branded anything was 2002. So I'm not worried about trademark here.

That said, the human-readable SVG thing is real, so this isn't a TODO. I don't have an issue with it being a comment, just having it marked TODO, which has a specific meaning in MAME.

Well... I think I can make it fairly readable:

<svg width="286" height="70"> <g fill="#e2dbce" stroke="none">  <path d=" M 0,0 v 20 h 67 v -20 Z m 0,25 v 20 h 67 v -20 z m 0,25 v 20 h 67 v -20 z"/>  <path d=" M 76,0 v 45 h 47 v 5 h -47 v 20 h 67 v -45 h -47 v -5 h 47 v -20 Z" />  <path d=" M 152,0 v 70 h 86 v -20 h -19 V 0 Z m 20,20 h 27 v 30 h -27 z" />  <path d=" M 266,0 l -12,20 h 12 v 50 h 20 V 0 Z" /> </g>  <path fill="#36dbe9" stroke="none" d="m 222,0 h 39 l -19.5,32.5 z"/> </svg>

src/mame/layout/esq1.lay

felipesanches · 2025-08-15T19:25:28Z

There are a few questions that I left for @cuavas above and I may address them when I get an answer, but I consider that I have put my best effort here and that this PR is ready for a final review & merge.

galibert reviewed Aug 13, 2025

View reviewed changes

src/mame/ensoniq/esq1.cpp Outdated Show resolved Hide resolved

felipesanches added 2 commits August 13, 2025 05:14

Use PORT_GM_* declarations on Ensoniq ESQ-1 driver

b437c74

felipesanches force-pushed the add_ensoniq_esq1_internal_layout branch from bbc2f15 to b437c74 Compare August 13, 2025 08:15

felipesanches added 2 commits August 13, 2025 05:30

[Ensoniq ESQ-1]: Reassign notes of the internal keyboard to be one oc…

22082ff

…tave higher.

[Ensoniq ESQ-1] Remove PORT_NAME entries with musical note names

19b4c1e

Because PORT_GM_* replaces them.

cuavas reviewed Aug 13, 2025

View reviewed changes

Address some feedback from @cuavas (at #PR 14049)

93ea7f9

Adding a layout for Ensoniq ESQ-1. #14049

Are you sure you want to change the base?

Adding a layout for Ensoniq ESQ-1. #14049

Conversation

felipesanches commented Aug 12, 2025

Before

After

Uh oh!

Uh oh!

felipesanches commented Aug 13, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

felipesanches Aug 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

felipesanches commented Aug 15, 2025

Uh oh!

Uh oh!

felipesanches Aug 13, 2025 •

edited

Loading