Percussa XMX vs 4ms Meta

I’ve just jumped into this space with both a new XMX and a 4ms Meta so I’ll be stress testing both of them in the next few weeks to see what gets to stay in my Live Rig case.
They are both relatively new and about the same size and similar price so I expect many people will be comparing them. Wondering what the rest of you Percussa experts here think about this latest addition to the ‘module in a module, playing field ?

I’ll be back here with my thoughts once I’ve given them both a good workout.

2 Likes

the 4ms caught my attention too

Ive had both for quite a while now… XMX during dev, and bought MM via pre-order.

note: Ive created vcv plugins in the past, hence a reason im interesting in MM.

tl;dr; they are quite different… both with pros/cons.

I was planning on doing a video comparison… but Im not sure, as frankly, I found a bit too much bias when discussing on other forums.
to the point where a discussion seems pretty pointless/uninformed.

first… 4ms did a fantastic job on MM, Ive nothing but technical respect for what they achieved.

MM main value proposition is number of modules due to ‘easy’ porting from vcv, and a certain familiarity of workflow. I also like its 8 cv/audio output (over xmx)
however, for me, vcv is also its achilles heel… in both workflow and performance, and the hardware is ‘ok’ but lacking in quite a few ways.

overall, Id say, its what I expected, but has disappointed me somewhat… but for reasons I did know before I bought.

I personally think the XMX is a better hardware platform (though I wish it had more ram) .
buildroot linux is a much better design, coupled with its much more powerful cpu.
things like usb audio interface are really useful, encoders are better than pots in this domain,
ofc, you trade this for less modules… though their UIs are designed for the small screen unlike vcv modules.

I do think the MM will appeal to more users… partly because its easier to envisage what it tries to be.

but underneath… its kind of odd…
its kind of cute having the vcv panels on the MM, but actually they are often too small to actually be of much use. most of the UI has you selecting parameters and jacks from a text list.
so what functional purpose does it have? esp. on a display which (like XMX) is small enough that UI space is scarce/valuable.
but ‘pretty’ sells … and I do kind of like it :laughing:

(note: if the MM had a panel the size of the SSP, with similar buttons / controls… it’d be a very different story!)

anyway, Im excited by both still…
the current MM ‘sdk’ is too limited for ideas I have, but hope 4ms will improve.

the xmx, well , I need to release what I already have … also messing with vcv has inspired me with ideas for other modules.
(my framework means generally modules will be able to run on both ssp/xmx with only small UI additions)

… so could be a busy winter :slight_smile:

3 Likes

That’s an excellent comparative summary. Thanks.
I’m still very new to both so I can’t add too much to that.
But as a first time user of both I did find it hard to get my head around the XMX menu system for a couple of days whereas I was up and running on the Meta immediately.
Like many people I try to use stuff before reading the manual - and let’s be honest the XMX documentation isn’t great. Plus there is VERY little information on the XMX out there - even on this forum! Which I find surprising.
Having used the XMX for about a week though I’m starting to appreciate its more austere nature and also the built in scopes on inputs and outputs.
I’m already missing some additional outs - 4 would have been good but I can’t complain, it has what it has. It has a header on the back so maybe an expander will happen one day? ( I wonder if I could DIY one….? )

Essentially I think you are right - despite the fact that they both offer the ‘module in a module’ amenity they are actually very different beasts.

1 Like

yeah, the buttons take a little getting used to on xmx for navigation etc…
but it becomes quite quick once you get some muscle memory for it.

indeed, getting used to synthor can take some a while to get used too, but like most things once you get used to it, it can be pretty quick to patch… and there aren’t that many ‘quirks’ (imo)

but vcv has so many tutorials and ofc, is trying to replicate the physical eurorack workflow, so is easier to get going.

synthor, indeed the scopes are something I really like on both xmx and ssp.
also the fact that inputs/outputs can be scaled/offset (and summed) without using additional modules is SO useful.

also when you see my modules on the xmx, I believe you’ll appreciate my plugin UIs are sized appropriately for the physical display - you can easily read/change parameters without having to get close to the module :wink:

I agree about the 8 outputs being useful on MM, which makes some things more general purpose.
e.g. modulation outputs. (especially, as Im used to 16/8 on the SSP)

however, I appreciate the xmx being focused on stereo output, so more for audio - be it voices or fx.
this is compounded by the fact we have a handy headphone output AND the recorder too!

(ofc you get more io via usb audio , but thats a different thing again)

another contender in the equation:
Expert Sleepers NT

yeah, this is a nice product…

what’s interesting is this serialised bus patching was an idea I tried out for Trax in its early design / prototype stage.
(I’d used something similar in my previous virtual modular for the Organelle ‘Orac’)

in Trax my main idea was around 4 ‘chains’ (disting-nt has 1) aka tracks, and these tracks have a serial routing (from 1-8 slots in trax)

however, I moved away from it, because

  • it does have some limitations.
    e.g feedback would have to be done by something similar to the SSP Bus module
  • it still requires ‘patching’ , it just means you don’t have to select the in/out modules, these are inferred by the chain.
    my early ideas for trax was to try to have ‘auto patching’, but I found even with defaults it only really worked with pretty simple chains.

But I will watch it with interest… and see how others get on with it.

frankly, it’d be pretty simple for me to move Trax (or a variation) back to using this patching mechanism, as its pretty much still there at its heart…

I will also say for the XMX, this patching mechanism has one nice advantage - you need fewer audio buffers (basically 24) - useful for xmx, due to it having less RAM.
(not an issue at all for SSP)

but overall, I like it, as I do think it might be easier/quicker to patch, even if a little less flexible.

1 Like

I was looking at both the MM and the NT before a trade came my way and I was able to trade a Nord Engine for a SSP. The NT is conceptually closer to the SSP for me because the virtual modules in it are mainly written by the NT’s creator and not as open as the MM modules are. The SSP has opened up a little more to outside VST developers, we will see what the NT does. The MM module owner has to deal with the problem that only a subset of VCV modules will work on it, and problematically, there is no easy way of telling if ones used in your VCV patch will play at all when loaded into the MM. Also VCV tends to tempt patchers to make patches that are also too large to run on the MM hardware. It is safer to build patches totally in the MM itself and not use VCV at all. That way you are assured that they will work (except for memory overloads). Also for me the MM has so many virtual modules to choose from, all with the wacky names that the Euro market tends to name them, that it is often too hard to choose what to use in it. An overabundance of choices.
The “virtual modular in a module” module is a growing market for sure. I have been a Nord Modular user for decades, and have been amazed it took so long for real contenders to appear.

2 Likes

Can’t help it—your words caused my brain to imagine the Nord Modular OS ported to SSP, for just a moment. It was a nice moment :wink:

I wish Nord would Open Source both NM versions at this point. In the long run, modern modular apps like VCV are much more capable, but it’s sure impressive how a relatively modest number (historically) of NM users pushed that 30 year old platform to create some astounding patches, experiments and techniques, not to mention all the educational resources still available online. Hordijk and others brought their immense talents to bear for years on both the NM1 and 2.

I would bet that almost every Nord user out there wishes that the Nord OS was more open source. All you have to do is look at the Axoloti/Ksoloti and see what being more open can do. There are thousands of community made modules. The Nord is good at making complex patches because the G2 has over 170 virtual modules. But that module list will never grow.
I would just love to be able to edit patches on the SSP as easily as it is on the Nord. As I have posted elsewhere, I don’t even need realtime editing as on the Nord, I could easily settle for reading and writing patch files to and from the SD cards.