MAMEdev
Replies: 6 comments 2 replies
|
Check this out: |
|
Thank you for the link - and for this special build. ("Thanks to the recent AI coding revolution..." so, I suppose an AI-driven code generated from the MAME sources? Interesting...) But with my topic / first post, I intended if it was possible to make an Official MAME plugin version (= to include the Official VST2, VST3, CLAP plugins builds inside the Official MAMEdev releases, updated each month), so there would not be the need to fork MAME and make a new project for each synth (as you did) each time. So I asked if there's any architectural limitation in MAME sources preventing this : my idea was for a more "unified approach". Anyway, thank you again for you precious contribution (with your project). |
|
It is a proof-of-concept, so in theory it can be done. But every instrument is different: panel layouts, outputs, etc. so I think it is a hard task to automate fully. We are musicians, not programmers, so yes, it was coded with AI help :) |
This is not difficoult to tackle : multiple layouts etc. can be loaded on the fly from external files (as today happens with MAME standalone EXEcutables). What's needed istead (to be included in MAME), is a new layer in the middle. Let's call it "the dispatcher" : There're the "plugin parameters (exposed to DAW)" enum (for example) as Parameter_000000, Parameter_000001, Parameter_000002, ..., Parameter_999999 - always using a generic name. This because - in audio plugins - Parameters can be instantiated once, "simply speaking". Then "the dispatcher" layer which assigns/routes/connects the "plugin parameters (exposed to DAW)" to each "MAME emulated synth/gear controls/gui buttons etc". each time a single synth/audio gear emulator/driver is loaded and executed. So a DAW will always see a list of Parameter_000000, Parameter_000001, Parameter_000002, ..., Parameter_999999 but all MAME internal parameters (different for each emulated gear) will be accessible via DAW automation. MAME project natively available as VST2, VST3, CLAP audio plugins would be a real game changer, for preservation of vintage audio hw and sw. And MAME has an Army of 1000s hyper-talented devs. That should not be a problem for them to find a way for making this happen. |
|
Following this topic, I would keep MAME devs attention to VES Vintage Emulator Studio, recently released by Autodafe : https://github.com/antoniograzioli/VintageEmulatorStudio This direct derivation of MAME is a really good idea. Please keep an eye on it. It would be a glorious step ahead for the official MAME project to natively integrate the philosophy of VES DIRECTLY INTO MAME itself, also if just on the long run. |
|
Hello! Today I did something similar to VES but more targeted to make MAME development for synths more fun https://github.com/hjanetzek/muse |
|
MUSE is already a big open-source DAW popular on Linux. Maybe try to not collide names that much? |
|
Oh nice MusE is back! (recall it from the early 2010s and thought it stalled) |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hello.
Is there any structural limitation or obstacles in the codebase for releasing the whole, official MAME project as a virtual instrument / effect VST, VST3, CLAP plugin ?
So, a VST, VST3, CLAP plugin (of just a few megabytes) calling all the same MAME external files/libraries/dependencies at Runtime, as it happens now with the MAME EXEcutable binary file.
Is it possible for the MAME Team to make a plugin version of it with just minimal, one-time code adjustments/modifications?
By adding the VST, VST3, CLAP binary files (along side the classic EXEcutable binary) to the MAME project's monthly release would also boost (even more) interest in the MAME project worldwide, embracing the Pro Audio scene and their direct feedbacks.
I would like to know more about this aspect, so I asked. Thank you for any infos about it - and congrats for the amazing good job so far (to all 1000s of Devs here).
All reactions