How to configure X68k system in MAME?

[aorin1]

Yes, in this case, I think the Sharp X68000 looks better then. Similar cases often occurred in games released between Genesis/SNES, the latter often having the same stretching like the comparisons above.

[e-tank]

bumping this post to both point out and say thank the libretro team for their recent work they’ve been doing over the past few days in cleaning up this core. wow, thank you so much!

i actually have a couple experiments/fixes in a git branch locally for various things, some of them have already been addressed by the flurry of recent work being done, but one is a proper fix for what audio desync hack option currently handles. i adapted the same method neocd_libretro uses, which keeps an accumulator that persists across frames in order to accurately determine how many samples to send out per frame in a way that keeps it in balance. however, it currently only works with the actual system framerates and not the compatible/fake ones that are set as the default so /shrug?

that said i’m not well versed on how retroarch itself handles the audio it accepts from a core. it might also be ok to (and after testing this it actually SEEMS to be ok to) just hand off all available samples on hand per frame and let the frontend figure it all out.

that said i don’t feel confident with either atm to push them out let alone pull request…

also, i noticed c68k was set back to the default cpu core after it was fixed (presumably by this commit here: https://github.com/libretro/px68k-libretro/commit/6e7e0b75cc65ad578bebcb4cfcab1aa9b1340789 i was expecting the worst thinking the offending cast that was truncating the upper address bits was buried somewhere in the core’s sea of macros…) i’m not at all opposed to the switch but i do bring it up just to point out that due to c68k’s less accurate timings it does break one of the platforms most popular games under default settings, that being castlevania. for anyone who wants to play castlevania you will need to bump the base clock speed up from 10mhz to at least 16 if you don’t want to encounter some game breaking bugs later on, namely the raft on stage 2 from disappearing out from under you randomly (more often than not) after breaking the lions head and killing you instantly. the game runs perfectly at 16 and above though, thankfully

@Awakened

Though apparently Etoile Princess still crashes at the title screen regardless of using the musashi or c68k cores. You still have to use an old build for that game: https://github.com/libretro/px68k-libretro/issues/135#issuecomment-1215629357 1

huh, it works fine on my end. even on my slightly outdated branch that doesn’t include the flurry of recent care and attention the core is getting. maybe check again?

@Awakened

Maybe someone will take MAME’s x68k emulation and create a more accuracy focused x68k libretro core someday. I don’t want to bother with the full MAME core just for x68k, personally.

i haven’t checked in with mame’s x68k core in a while, probably over a year at this point, but last i did px68k was actually in better shape in some ways, particularly in terms of graphical accuracy. mame just definitely had the upperhand when it came to audio though, hence why i suggest using it to compare against in this aspect.

you see the thing about midi in px68k rn is, while i know i need to make adjustments to the current system/host interface code, namely getting proper time/syncing of playback in order, it’s probably going to be hard to know exactly where issues exist as from what i can tell px68k never had working os interface code for midi hooked up (not talking about libretro, just in general), meaning i imagine the actual core/emu code isn’t well tested and may be buggy or incomplete. again, if mame’s midi support is in good order then it’ll be a good reference to help fix up px68k’s

@hunterk

You’re welcome to use my actions recipe as a starting point

It’s a cross-compile from linux, but all you should need to do is swap out your repo address (and, if needed, add a branch checkout step).

thank you, i’ll certainly look into this

@DukeSkinny

Edit Disregard, the dragging was on me. Vsync Swap Interval = 2, specifically.

oops, ya i forgot to mention i was using video_swap_interval = “1” in my list of options that i was using to get the results i got in my recorded footage. i’m pretty sure getting the timing stuff in order i previously mentioned will take care of this particular problem

@DukeSkinny

For MT-32, I of course put the core in ‘LA’ mode. Both synths produced sound, but with a lot of incorrect instruments. No matter which one I used, or however I fiddled with Munt settings the outcome was identical.

how does it sound compared to the footage i posted earlier in this thread? if it’s drastically different then it may be an issue with your munt config. also, thank you for your work testing

[Tatsuya79]

We went back to C68K as it’s quite faster:
-920fps musashi vs 1030fps C68K on akumajou stage2 at 10MHz, ryzen 5600X
-380fps vs 680fps at 100MHz
So it can be maybe twice faster on slow platforms.
As it’s a kinda hacky core made for speed it makes sense to go with C68K as default.

But maybe we can have both compiled and a core option to switch between them?
I’m not a qualified coder myself to do it though, a bit clueless about a lot of compilation stuff.

The crash with Etoile Princesse is happening for me as well on win10 x64, it could be about how it’s compiled/unsafe memory allocation. This build from here is running the game fine (older gcc?): https://github.com/hunterk/libretro_builds

If you checked mame a year ago, it didn’t change at all for x68k.
I was just checking how Gardis Light 2.10, which has a strong screen refresh issue on px68k, was running with it. It’s not even booting.
I did the x68k snapshot collection for progettosnaps.net, and I quickly stopped using mame for it as its compatibility is still a lot weaker than px68k.
It can do midi though and it was working fine in akumajou iirc. Make sure the license allows it before directly porting any code.

There’s xm6 old source code there too (xm6_205s.zip):
http://yohkai.no-ip.info/x680x0/XM6.htm#download

[DukeSkinny]

it may be an issue with your munt config

You may have a point. Been at it like crazy though and can’t find a working setup, despite using both standalone latest Munt and Falcosoft’s MuntVSTi through Midiplayer. At that point it seems the only thing in common would be the MT-32 ROMs which should be all right. Will keep fiddling though.

Edit I’ve had this suspicion since last night, but now that I’ve thought about it I’m sure it must be SysEx messages not getting handled correctly. MT-32 sounds excellent coming through DOSBox-core where Munt is built-in, and the same Munt setup which fails me with px68k exhibits the same problems using np2kai. Must be loopMIDI dropping the ball as it routes the input to a custom port.

[Hari-82]

Etoile Princess crashes for me as well after the first title screen. I tried dim and the 2 [a] versions and also a hdf, same results. Also tried to change ram and cpu speeds with no luck.

[Awakened]

@e-tank

for anyone who wants to play castlevania you will need to bump the base clock speed up from 10mhz to at least 16 if you don’t want to encounter some game breaking bugs later on, namely the raft on stage 2 from disappearing out from under you randomly (more often than not) after breaking the lions head and killing you instantly. the game runs perfectly at 16 and above though, thankfully

That bug always drove me nuts in px68k, so I was happy I didn’t run into it when testing musashi. Good to know why it happens now and how to fix it in c68k

@e-tank

huh, it works fine on my end. even on my slightly outdated branch that doesn’t include the flurry of recent care and attention the core is getting. maybe check again?

I’m not too interested in playing that game myself, but I’d seen @Tatsuya79 post about it elsewhere so I brought it up. Looks like it’s still an issue from his post and @Hari-82 's above.

@e-tank

i haven’t checked in with mame’s x68k core in a while, probably over a year at this point, but last i did px68k was actually in better shape in some ways, particularly in terms of graphical accuracy. mame just definitely had the upperhand when it came to audio though, hence why i suggest using it to compare against in this aspect.

Huh, well good to know px68k is better graphically and compatibility wise. I bet MAME has better FM synth if it’s audio is generally better.

[hunterk]

Anybody have any thoughts on this? https://www.reddit.com/r/RetroArch/comments/wqbn0m/comment/ikyf4hf

Copy/pasted here for convenience:

Unfortunately, the latest version (0.15+ 77bfb32) from Aug. 19th seems to re-introduce the bug (it could also be a new bug). “Akumajou Dracula” crashes again during loading. “Street Fighter II Champion Edition” doesn’t crash but gets stuck at this screen: https://i.postimg.cc/6prV8WFZ/Street-Fighter-II-Champion-Edition-Stuck-during-loading.png

The version from Aug. 18th (0.15+ d2a4248) doesn’t have any of these problem. So I guess it’s likely caused by changes from yesterday.

Update: I did more tests with the latest core on Android, which has the same crash or freeze issue as the Windows core. Pretty sure this is a new bug, not the old Windows-only bug.

[e-tank]

the issue with etoile princess sounds like another improper type/cast issue truncating higher address bits, but at least we know now that it’s (most likely) not in the cpu core this time since it affects both c68k and musashi.

@Tatsuya79

But maybe we can have both compiled and a core option to switch between them?

oh, that’s a really good idea. i’ll look into the feasibility of it. would be nice to have a selectable core option with something like - CPU Core: C68K (Fast) || Musashi (Accurate)

@DukeSkinny if it helps here’s md5 hashes for the rom files i’ve been using:

md5sum /usr/local/share/mt32-rom-data/*
9513fec4f09a7d327748340ce3a2a59b  /usr/local/share/mt32-rom-data/MT32_CONTROL.ROM
89e42e386e82e0cacb4a2704a03706ca  /usr/local/share/mt32-rom-data/MT32_PCM.ROM

as for how i have munt config’d, i have only these two parts of munt installed (2.7.0):

the system library: https://github.com/munt/munt/tree/munt_2_7_0/mt32emu

mt32d background process daemon program: https://github.com/munt/munt/tree/munt_2_7_0/mt32emu_alsadrv

and i run mt32d without any config files, i just point it to the rom files with:

mt32d -f /usr/local/share/mt32-rom-data/

@hunterk the issue is in this massive commit here: https://github.com/libretro/px68k-libretro/commit/711f018b2efb8530f1887d44b4a4e835e3463252, which is the very next commit after the one the person reported was good. dunno where exactly but compiling with musashi fixes it so the problem is most likely with one of the files associated with c68k that it touches

@Tatsuya79

There’s xm6 old source code there too (xm6_205s.zip): http://yohkai.no-ip.info/x680x0/XM6.htm#download

will grab for later ref, ty!

[hunterk]

hey @e-tank, any chance you can pop onto our discord server? Twinaphex reverted that big commit that re-broke stuff but I think he’s wanting to ask you some stuff about the core.

[DukeSkinny]

Oh boy. With the latest changes from the official repo the infinite sustain of the SC-VA synth is gone, but now both it and the MT-32 produce wildly inaccurate and comical sounds.

If the problem is on my end, it seems strange that the SC-55 mode sounded accurate last I checked, the infinite sustain issue notwithstanding. The MT-32 also produces different sounds than before. In addition, DosBox-pure gives me the correct SC-VA sounds (though with infinite sustain on choice notes), and standalone emulators such as PCem have no problems with my synth setups… likewise for Np2kai in RA. So it doesn’t seem to be a case of the communication between my RA setup and external synths breaking down, though I should try a clean RA setup just in case.

Edit Nope, that wasn’t it.

[Tatsuya79]

Etoile Princesse should work now. Recent changes fixed it for me.

[Hari-82]

just tried the hdf and it works for me as well!

[Awakened]

Well done video people in this thread should check out with real hardware footage:

Castlevania for Sharp X68000 Akumajo Dracula compared to NES, SNES, Genesis/Mega...

[Hari-82]

px68K not working anymore for me.

[hunterk]

Anything useful in a verbose log?

[Hari-82]

not that I could see

[INFO] RetroArch 1.11.0 (Git 9586d67)
[INFO] === Build =======================================
[INFO] CPU Model Name: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz
[INFO] Capabilities:  MMX MMXEXT SSE SSE2 SSE3 SSE4 SSE4.2 AES AVX AVX2
[INFO] Built: Sep 30 2022
[INFO] Version: 1.11.0
[INFO] Git: 9586d67
[INFO] =================================================
[INFO] [Input]: Found input driver: "dinput".
[INFO] [Environ]: SET_PIXEL_FORMAT: RGB565.
[INFO] [Core]: Version of libretro API: 1, Compiled against API: 1
[INFO] [Audio]: Set audio input rate to: 48000.00 Hz.
[INFO] [Video]: Set video size to: fullscreen.
[INFO] [Vulkan]: Vulkan dynamic library loaded.
[INFO] [Vulkan]: Found vulkan context: "vk_w".
[INFO] [Vulkan]: Detecting screen resolution: 1920x1080.
[INFO] [Video]: Fullscreen set to 1920x1080 @ 60Hz on device \\.\DISPLAY1.
[INFO] [Vulkan]: Found GPU at index 0: "NVIDIA GeForce GTX 960".
[INFO] [Vulkan]: Using GPU index 0.
[INFO] [Vulkan]: Using GPU: "NVIDIA GeForce GTX 960".
[INFO] [Vulkan]: Queue family 0 supports 16 sub-queues.
[INFO] [Vulkan]: Got 2 swapchain images.
[INFO] [Vulkan]: Using resolution 1920x1080.
[INFO] [Vulkan]: Using RGB565 format.
[INFO] [Vulkan]: Loading stock shader.
[INFO] [XInput]: Found XInput v1.4.
[INFO] [Joypad]: Found joypad driver: "xinput".
[INFO] [Video]: Found display server: "win32".
[INFO] [XAudio2]: Requesting 64 ms latency, using 64 ms latency.
[INFO] [Display]: Found display driver: "vulkan".
[INFO] [SRAM]: SRAM will not be saved.
[INFO] [Playlist]: Loading history file: "D:\EMU\RetroArch FINAL\content_history.lpl".
[INFO] [Playlist]: Loading history file: "D:\EMU\RetroArch FINAL\content_music_history.lpl".
[INFO] [Playlist]: Loading history file: "D:\EMU\RetroArch FINAL\content_video_history.lpl".
[INFO] [Playlist]: Loading history file: "D:\EMU\RetroArch FINAL\content_image_history.lpl".
[INFO] [Playlist]: Loading favorites file: "D:\EMU\RetroArch FINAL\content_favorites.lpl".
[INFO] [Core]: Using content: "D:\EMU\RetroArch FINAL\ROMs\Sharp - X68000\Chourensha 68K (1995)(Famibe No Yosshin)\Chourensha 68K v1.01 (1995)(Famibe No Yosshin).dim".
[INFO] [Core]: Content ran for a total of: 00 hours, 00 minutes, 00 seconds.
[INFO] [Core]: Unloading core..
[INFO] [Core]: Unloading core symbols..
[INFO] [Video]: Does not have enough samples for monitor refresh rate estimation. Requires to run for at least 4096 frames.
[INFO] RetroArch 1.11.0 (Git 9586d67)
[INFO] === Build =======================================
[INFO] CPU Model Name: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz
[INFO] Capabilities:  MMX MMXEXT SSE SSE2 SSE3 SSE4 SSE4.2 AES AVX AVX2
[INFO] Built: Sep 30 2022
[INFO] Version: 1.11.0
[INFO] Git: 9586d67
[INFO] =================================================
[INFO] [Input]: Found input driver: "dinput".
[INFO] [Core]: Loading dynamic libretro core from: "D:\EMU\RetroArch FINAL\cores\px68k_libretro.dll"
[INFO] [Overrides]: Core-specific overrides found at "D:\EMU\RetroArch FINAL\config\PX68K\PX68K.cfg".
[INFO] [Config]: Appending config "D:\EMU\RetroArch FINAL\config\PX68K\PX68K.cfg".
[INFO] [Environ]: SET_CONTROLLER_INFO.
[INFO] [Environ]: SET_SUPPORT_NO_GAME: yes.
[INFO] [Environ]: GET_CORE_OPTIONS_VERSION.
[INFO] [Environ]: RETRO_ENVIRONMENT_SET_CORE_OPTIONS_V2.
[INFO] [Remaps]: Core-specific remap found at "D:\EMU\RetroArch FINAL\config\remaps\PX68K\PX68K.rmp".
[INFO] [Overrides]: Redirecting save file to "D:\EMU\RetroArch FINAL\saves\PX68K\Chourensha 68K v1.01 (1995)(Famibe No Yosshin).srm".
[INFO] [Overrides]: Redirecting save state to "D:\EMU\RetroArch FINAL\states\PX68K\Chourensha 68K v1.01 (1995)(Famibe No Yosshin).state".
[INFO] [Environ]: GET_LOG_INTERFACE.
[INFO] [Environ]: SYSTEM_DIRECTORY: "D:\EMU\RetroArch FINAL\system".
[INFO] [Environ]: CORE_ASSETS_DIRECTORY: "D:\EMU\RetroArch FINAL\downloads".
[INFO] [Environ]: GET_SAVE_DIRECTORY.
[INFO] [Environ]: SET_PIXEL_FORMAT: RGB565.
[INFO] [Environ]: GET_RUMBLE_INTERFACE.
[INFO] [Environ]: GET_DISK_CONTROL_INTERFACE_VERSION.
[INFO] [Environ]: SET_DISK_CONTROL_EXT_INTERFACE.
[INFO] [Environ]: SET_FRAME_TIME_CALLBACK.
[INFO] [Content]: Content loading skipped. Implementation will load it on its own.
[INFO] [SRAM]: Skipping SRAM load.
[INFO] [Core]: Version of libretro API: 1, Compiled against API: 1
[INFO] [Audio]: Set audio input rate to: 44100.00 Hz.
[INFO] [Video]: Game FPS > Monitor FPS. Cannot rely on VSync.
[INFO] [Video]: Set video size to: fullscreen.
[INFO] [GLCore]: Found GL context: "wgl".
[INFO] [GLCore]: Detecting screen resolution: 1920x1080.
[INFO] [Video]: Fullscreen set to 1920x1080 @ 60Hz on device \\.\DISPLAY1.
[INFO] [WGL]: Extensions: WGL_ARB_buffer_region WGL_ARB_create_context WGL_ARB_create_context_no_error WGL_ARB_create_context_profile WGL_ARB_create_context_robustness WGL_ARB_context_flush_control WGL_ARB_extensions_string WGL_ARB_make_current_read WGL_ARB_multisample WGL_ARB_pbuffer WGL_ARB_pixel_format WGL_ARB_pixel_format_float WGL_ARB_render_texture WGL_ATI_pixel_format_float WGL_EXT_colorspace WGL_EXT_create_context_es_profile WGL_EXT_create_context_es2_profile WGL_EXT_extensions_string WGL_EXT_framebuffer_sRGB WGL_EXT_pixel_format_packed_float WGL_EXT_swap_control WGL_EXT_swap_control_tear WGL_NVX_DX_interop WGL_NV_DX_interop WGL_NV_DX_interop2 WGL_NV_copy_image WGL_NV_delay_before_swap WGL_NV_float_buffer WGL_NV_multisample_coverage WGL_NV_multigpu_context WGL_NV_render_depth_texture WGL_NV_render_texture_rectangle 
[INFO] [WGL]: Adaptive VSync supported.
[INFO] [GLCore]: Vendor: NVIDIA Corporation, Renderer: NVIDIA GeForce GTX 960/PCIe/SSE2.
[INFO] [GLCore]: Version: 4.6.0 NVIDIA 516.40.
[INFO] [GLCore]: Using resolution 1920x1080.
[INFO] [XInput]: Found XInput v1.4.
[INFO] [Joypad]: Found joypad driver: "xinput".
[INFO] [Shaders]: Specific shader preset found at "D:\EMU\RetroArch FINAL\config\PX68K\PX68K.slangp".
[INFO] [slang]: Compiling shader: "D:\EMU\RetroArch FINAL\shaders\shaders_slang\crt\shaders\guest\advanced\stock.slang".
[INFO] [slang]: Using render target format R8G8B8A8_UNORM for pass output #0.
[INFO] [slang]: Compiling shader: "D:\EMU\RetroArch FINAL\shaders\shaders_slang\crt\shaders\guest\advanced\stock.slang".
[INFO] [slang]: Using render target format R8G8B8A8_UNORM for pass output #1.
[INFO] [slang]: Compiling shader: "D:\EMU\RetroArch FINAL\shaders\shaders_slang\crt\shaders\guest\advanced\afterglow0.slang".
[INFO] [slang]: Using render target format R8G8B8A8_UNORM for pass output #2.
[INFO] [slang]: Compiling shader: "D:\EMU\RetroArch FINAL\shaders\shaders_slang\crt\shaders\guest\advanced\pre-shaders-afterglow.slang".
[INFO] [slang]: Using render target format R8G8B8A8_UNORM for pass output #3.
[INFO] [slang]: Compiling shader: "D:\EMU\RetroArch FINAL\shaders\shaders_slang\crt\shaders\guest\advanced\avg-lum.slang".
[INFO] [slang]: Using render target format R8G8B8A8_UNORM for pass output #4.
[INFO] [slang]: Compiling shader: "D:\EMU\RetroArch FINAL\shaders\shaders_slang\crt\shaders\guest\advanced\linearize.slang".
[INFO] [slang]: Using render target format R16G16B16A16_SFLOAT for pass output #5.
[INFO] [slang]: Compiling shader: "D:\EMU\RetroArch FINAL\shaders\shaders_slang\crt\shaders\guest\advanced\gaussian_horizontal.slang".
[INFO] [slang]: Using render target format R16G16B16A16_SFLOAT for pass output #6.
[INFO] [slang]: Compiling shader: "D:\EMU\RetroArch FINAL\shaders\shaders_slang\crt\shaders\guest\advanced\gaussian_vertical.slang".
[INFO] [slang]: Using render target format R16G16B16A16_SFLOAT for pass output #7.
[INFO] [slang]: Compiling shader: "D:\EMU\RetroArch FINAL\shaders\shaders_slang\crt\shaders\guest\advanced\bloom_horizontal.slang".
[INFO] [slang]: Using render target format R16G16B16A16_SFLOAT for pass output #8.
[INFO] [slang]: Compiling shader: "D:\EMU\RetroArch FINAL\shaders\shaders_slang\crt\shaders\guest\advanced\bloom_vertical.slang".
[INFO] [slang]: Using render target format R16G16B16A16_SFLOAT for pass output #9.
[INFO] [slang]: Compiling shader: "D:\EMU\RetroArch FINAL\shaders\shaders_slang\crt\shaders\guest\advanced\crt-guest-advanced.slang".
[INFO] [slang]: Using render target format R16G16B16A16_SFLOAT for pass output #10.
[INFO] [slang]: Compiling shader: "D:\EMU\RetroArch FINAL\shaders\shaders_slang\crt\shaders\guest\advanced\deconvergence.slang".
[INFO] [slang]: Using render target format R8G8B8A8_UNORM for pass output #11.
[INFO] [slang]: Building pass #0 (N/A)
[INFO] [slang]: Building pass #1 (StockPass)
[INFO] [slang]: Building pass #2 (AfterglowPass)
[INFO] [slang]: Building pass #3 (PrePass)
[INFO] [slang]: Building pass #4 (AvgLumPass)
[INFO] [slang]: Building pass #5 (LinearizePass)
[INFO] [slang]: Building pass #6 (N/A)
[INFO] [slang]: Building pass #7 (GlowPass)
[INFO] [slang]: Building pass #8 (N/A)
[INFO] [slang]: Building pass #9 (BloomPass)
[INFO] [slang]: Building pass #10 (N/A)
[INFO] [slang]: Building pass #11 (N/A)
[INFO] [slang]: Building pass #12 (N/A)
[INFO] [GLCore]: Not using frame history.
[INFO] [GLCore]: Using framebuffer feedback for pass #2.
[INFO] [GLCore]: Using framebuffer feedback for pass #4.
[INFO] [Video]: Found display server: "win32".
[INFO] [XAudio2]: Requesting 64 ms latency, using 64 ms latency.
[INFO] [Display]: Found display driver: "glcore".
[libretro INFO] Set Controller Device: 1, Port: 0 1 0
[INFO] [Environ]: SET_INPUT_DESCRIPTORS:
[libretro INFO] Set Controller Device: 1, Port: 1 1 1
[INFO] [Environ]: SET_INPUT_DESCRIPTORS:
[INFO] [Playlist]: Loading history file: "D:\EMU\RetroArch FINAL\content_history.lpl".
[INFO] [Playlist]: Loading history file: "D:\EMU\RetroArch FINAL\content_music_history.lpl".
[INFO] [Playlist]: Loading history file: "D:\EMU\RetroArch FINAL\content_video_history.lpl".
[INFO] [Playlist]: Loading history file: "D:\EMU\RetroArch FINAL\content_image_history.lpl".
[INFO] [Playlist]: Loading favorites file: "D:\EMU\RetroArch FINAL\content_favorites.lpl".

[Awakened]

The latest core from the buildbot still works for me. But I’ve only tried Akumajou Dracula.

[Hari-82]

I just tried to load just the core and it crashes as well.

EDIT: I tried with a fresh install, just moved the keropi forlder and downloaded the core didn’t change any settings and it crashes.

[Hari-82]

Solved!

from the keropi’s folder I deleted: config, sram.dat and RTC.dat

Not sure what was the problem because I didn’t touch those in a long while…

[riggles]

@e-tank

while i know i need to make adjustments to the current system/host interface code, namely getting proper time/syncing of playback in order, it’s proba

Trying it right now, I’m just getting Munt to play AcuPiano1, that’s the issue you were having? I just got it from the core downloader. Not sure if there’s anything I’m missing here, appreciate any help. Super pumped about potentially finally playing this with midi support.