DSP563xx Emulator (Access Virus, Nord Lead, Waldorf MW...)

[rafa1981]

I don't know the technical aspects, but I think that the mame license disallows any kind of profit using the emulators.

You can't use a Mame VST in a commercial song.

EDIT: That license was changed in 2016 to regular gpl + bsd. What I said doesn't apply.

[Uncle E]

I would ask something related to MAME, to real EXPERT people only. Please.

(Please notice I avoided to ask in the Instruments section, indeed).

Is there any structural limitation or obstacles in releasing the WHOLE 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 MAME DEVS to make a plugin version of it without touching or rearranging the project itself? Basically by just adding the VST, VST3, CLAP binary files (along side the classic EXEcutable binary) to the MAME project's monthly release.

I'm trying to access the MAMEDEV official forum in order to ask but it seems new registrations are not allowed...

Virtual JV is basically a MAME ported to plugin and given a much improved UI:

https://github.com/giulioz/jv880_juce

[xhunaudio]

VirtualJV, MAmidiMEmo, etc. etc. are derivations of MAME.

I ask this because - from several months or more - the original, official MAME project is now silently takling a gigantic number (basically every single one) of vintage (70s-80s-90s-2000s) digital and analogue audio gears (from 20.000 USD workstations to 60 USD toysynths) of the past.

For example, Giulioz himself is completing the Ensoniq core emulation in MAME before "publishing" it (with optimizations) under the TUS project. And this is GREAT news. The AKAI MPCs, Ensoniq SD-1 and a ton of others (with status: good or imperfect) are almost complete on MAME.

It's about 100s+ (1000s in the future) of very highly accurate, low-level emulations. If the MAME Dev Team (up to 2000 devs at the same time, worldwide) could add - beside the EXEcutable app - the VST, VST3, CLAP plugins binaries of the SAME, FULL MAME project itself, that would be amazing. Every month new gears are added (and/or perfected). I know they rebuilt the whole audio system of MAME months/years ago : maybe this is the step before introducing a plugin version of MAME ?

Nothing against MAME derivations (they are all great), but making separate derivations for the 1000s of audio gear included in MAME would be a neverending task...

This is why I asked for this specific matter : is there any limitation preventing a FULL, Official MAME VST plugin or it is something possible ?

Any (minor) workaround is needed (like it happened for Cardinal, the VCVRack project as a plugin) or is the source code of MAME ready for the prime time, NATIVELY?

PS : also, playing NBA JAM in Cubase would be sensational

[rafa1981]

Virtual JV uses Nuked-SC55, which has the original pre-2016 MAME license. It can't legally be used in commercial music. On this one I'm sure, that's why I got confused on my message above.

See the license:
https://github.com/nukeykt/Nuked-SC55

[unned]

I'm looking for collaborators on a project using the DSP56k emulator!

I've been working on a project to emulate a certain device I own and love. The unit runs on two DSP chips, so in theory it shouldn't be significantly more demanding than some of the TUS team's previous emulation efforts. It's my understanding that the TUS team is not currently interested in emulating this device, and they're unable to give any help/advice on using the emulator.

I think I've gotten pretty far with my attempts over the past 2 months, and I'm now looking for other technically inclined people who have explored the emulator’s internals and might be interested in sharing knowledge or collaborating.

If this sounds interesting to you, feel free to reach out

[xhunaudio]

I'm looking for collaborators on a project using the DSP56k emulator!

I've been working on a project to emulate a certain device I own and love. The unit runs on two DSP chips, so in theory it shouldn't be significantly more demanding than some of the TUS team's previous emulation efforts. It's my understanding that the TUS team is not currently interested in emulating this device, and they're unable to give any help/advice on using the emulator.

I think I've gotten pretty far with my attempts over the past 2 months, and I'm now looking for other technically inclined people who have explored the emulator’s internals and might be interested in sharing knowledge or collaborating.

If this sounds interesting to you, feel free to reach out

Too cryptic, mentioning the name of the device would definitely not be a crime.

[unned]

....

Too cryptic, mentioning the name of the device would definitely not be a crime.

Sure, I kept it general because any knowledge sharing is welcome. I'm working on the Machinedrum.

[Uncle E]

If you create a separate thread about it, please link to it here so we can subscribe to it.

[xhunaudio]

That's the point. As an example, the Machinedrum was more of a niche device, but it has a great value and it HAS to be preserved too, by virtualization. Asking to emulate it (from the ground up) to single teams of (really excellent) developers, well... this way, it would be difficoult that the Machinedrum will be emulated in reasonable time.

That was the point of my posts above. It would be great to have the whole OFFICIAL MAME project (NO forks, NO derivations, just the official MAMEDEV build) available as VST, VST3, CLAP plugins, every month (.286, .287, ...). THIS ALONE would speed up reserarch and developments a lot - and the interest around the MAME project will literally explode in an exponential way, by involving the pro audio scenario and its direct feedbacks.

With this (existing and growing) central, unified and solid MAME (LLE) codebase for every existing device - AVAILABLE AS AN AUDIO PLUGIN - the emulation, preservation and studying process of very niche systems (with their original User Interfaces and buttons, sliders, ... - no embellishments, no fashion presets browsers, etc.) would be in a state of grace. Every 2 weeks, or 3 months,... etc. there will be one, or two, or ten of the 2000+ amazing MAME developers from around the world who will add a line of code or two for the Machinedrum emulation too, slowly completing it.

Then, if you want to focus on a single device and make a ultra-optimized LLE emulation of a specific device with extended UI, presets browser etc., you're always welcome by forking/studying the MAME project. But that would be a piece of cake in comparison, since 99% of the work was already completed within the official MAME project.

[rafa1981]

It would be great, but someone has to put the legwork

[xhunaudio]

Sure, but MAME has 1000s of incredibly talented researchers and devs (with deep knowledge of its inner structure) and there's no hurry, it could take years to be completed - and that's fine.

At this point Native Audio Plugin (VST, VST3, CLAP) support for MAME emulated audio gears is important as MAME support for Control Pads for emulated Consoles. Digital and Analogue devices are being emulated/simulated with amazing accuracy and great progresses are made on a daily basis (a few days ago TPT simulations of CEM analog chips have been introduced too). Again, at this point MAME is too amazing not to include a plugin version of it - and VST3 format too has been "completely free-licensed" recently, so...

But it's important to be takled from its foundations, by the Official MAME project (not forks of forks of forks... of it). Otherwise it will just be another (abandoned) fork. I was interested to see if there's any plan to introduce this later on and if there was any obstacle in the codebase itself, preventing audio plugins support.

I opened a new thread on GitHub, asking for infos about this. If there's anyone here interested in this aspect too... maybe joining and asking too in that thread is a good idea, just to "shake waters".

Thread on GitHub :
https://github.com/orgs/mamedev/discussions/263

[Uncle E]

Giulioz said on the Discord "after the fourth night spent debugging stuff, I can now confidently say that we can do better than mame I think"

[xhunaudio]

Yes, take the Access Virus B. MAME LLE is waaay behind TUS LLE, but - anyway - MAME LLE basis for the different DSP563xx series (and CPUs, etc) are there. To be completed on the long run.

TUS made literally giant steps ahead (and very quickly) but it's focusing on "a few" devices, takling them one by one - not a few number, there are 10s, but compared to MAME...

The point is if MAME codebase is structured to be a plugin, it can take years and years to takle all audio gears and get the "status : good" on all audio devices, but at the end of the process, we're talking about an amazing, omni-comprehensive LLE machine preserving audio production history, accessible as a Plugin inside a DAW. The beauty of MAME is on the long term.