OpenMPT for DJing

[milk]

Are folks aware that Mixxx can load modules and it uses modplug behind the scenes? The feature was there for a while but behind a build flag, Arch and Fedora had it, now it's on by default in the official build, for Linux at least.

It downmixes the tracks to stereo in RAM, so no muting/soloing tracks (maybe one day Mixxx will do multichannel music).

Screenshots: decks and options.

If anyone does C++, tempo data isn't used by Mixxx for bpm yet.

[Saga Musix]

Very interesting, but sad to see that in this day and age they go for libmodplug (including all its antiquated DSPs) rather than libopenmpt. But chances are high that it will actually use libopenmpt rather than libmodplug behinde the scenes at least on Debian-based OSes, as our libmodplug emulation layer is available there.

Edit: Do note that tempo estimation for modules is often not accurate; OpenMPT can do it but sometimes it will be off by a factor of two (because there is no clear concept of how many rows make up a beat in most tracker formats). The next major version of libopenmpt (0.5) will provide the same tempo estimation as OpenMPT: https://bugs.openmpt.org/view.php?id=1286

[I-S3-O]

I didn't watch the whole thing, but i listened to one of your posts (cid memoriam), and I have to say: your opening soundscape was ridiculous! I loved it! I couldn't imagine trying to compose something like that.

[.^o]

lol 

This was a teaser for a party we played in south of france for a dead friend some years ago.
The sunday I played 12 hours long, parts of my live sets and DJ sets.
I'll play in a party in 15 days and I'll try record video or take some shots but cant promise.

[milk]

Very interesting, but sad to see that in this day and age they go for libmodplug (including all its antiquated DSPs) rather than libopenmpt. But chances are high that it will actually use libopenmpt rather than libmodplug behinde the scenes at least on Debian-based OSes, as our libmodplug emulation layer is available there.

Hehe, I think it's less "they" and more "one programmer came along years ago and added a feature to an open source programme", a feature that was kind of forgot about and hidden behind a build flag until I asked in 2018 (then asked the devs in their Zulip chat to enable by default last year).

A commit search shows it was initially added in 2012. I think it was enabled by default in in 2.2.3, which isn't packaged for Debian yet (though I guess Launchpad works as a PPA).

Searching the codebase for openmpt though and there are two results; a documentation reference and a borrowed graphic

I guess I can put a shout out / request on the Mixxx issue tracker regarding a possible upgrade to libopenmpt.

Edit: Do note that tempo estimation for modules is often not accurate; OpenMPT can do it but sometimes it will be off by a factor of two (because there is no clear concept of how many rows make up a beat in most tracker formats). The next major version of libopenmpt (0.5) will provide the same tempo estimation as OpenMPT: https://bugs.openmpt.org/view.php?id=1286

A-ha, good point, thanks. It appears the wiki article on formats says most have an initial tempo, but you are saying that there is a more ambiguous relationship between aspects of timing in the different tracker and player implementations?

Edit: re DJing, see also Chipdisco by Syphus/Echolevel

[Saga Musix]

Hehe, I think it's less "they" and more "one programmer came along years ago and added a feature to an open source programme", a feature that was kind of forgot about and hidden behind a build flag until I asked in 2018 (then asked the devs in their Zulip chat to enable by default last year).

Ah, it sounded like it was a relatively recent feature. In 2012 there was no libopenmpt yet so noone could have used it of course.

It appears the wiki article on formats says most have an initial tempo, but you are saying that there is a more ambiguous relationship between aspects of timing in the different tracker and player implementations?

If you're ready for it, all the dirty secrets about how tempo is interpreted in module formats can be found here:
https://wiki.openmpt.org/Manual:_Song_Properties#Tempo_Mode
The "classic" column in the table applies to most modules (especially those not made with OpenMPT, of course). The crucial thing to notice is that the actual BPM is made up from several variables, and what you have found to be returned by XMP is only one of them. Most importantly, one of the variables isn't even known in most oldskool formats, and that is "Rows per Beat". OpenMPT has to assume a value for this variable, and while it is 4 in many modules (OpenMPT's default guess), it could just as well be 3, 6, 8 or any other value (although the mentioned ones are the most common ones). Also, the tempo may of course change within a song (sometimes the tempo and speed value change but the resulting BPM stays the same), so Mixxx should not rely on determining this value once (in particular due to the lack of initial tempo values in some formats like MOD).

[milk]

If you're ready for it, all the dirty secrets about how tempo is interpreted in module formats can be found...

Gosh golly, thanks, some bed time reading

In case you want listen what is sounds like, here are some old sets (party live recorded for some) with those configurations (only OMPTs and a mixer, no mix software)

Enjoying the mixes btw! Very tek.

[milk]

Haha, I've just realised that Arch Linux, which I use (btw, so goeth the meme), has libopenmpt-modplug in the AUR, a "libmodplug compat layer/bridge to libopenmpt", which I've just built and installed.

Edit: exactly how different is libopenmpt from libmodplug these days?

[.^o]

Enjoying the mixes btw! Very tek.

THX

[Saga Musix]

Edit: exactly how different is libopenmpt from libmodplug these days?

From a user perspective: It supports more formats and it supports them much better. libmodplug hasn't been properly maintained for about 15 years now, so its playback compatbility is lacking behind greatly.

[milk]

From a user perspective: It supports more formats and it supports them much better. libmodplug hasn't been properly maintained for about 15 years now, so its playback compatbility is lacking behind greatly.

Thanks. I had seen that there were a few more recent libmodplug commits, but yes, there's no real active development effort there.

The FAQ notes: "libmodplug features missing in libopenmpt: ... Surround, extra bass, equalizer, automated gain control and noise reduction DSP effects: libopenmpt only tries to decode the actual module file itself and does not try to implement a general post-processing effect chain. Any effects could easily be applied by any player program externally after decoding via libopenmpt."

(Is it the bettered DSP mentioned earlier in the thread related to that linked with module file format fx?)

I understand the separation of concerns, though Mixxx utilises these aspects of libmodplug as can be seen in the options screenshot, and they do help in bringing a more immersive and modern feel to module music (that can allow more people to enjoy it, given modern production values and aesthetic expectations .

Thus a full drop-in replacement in Mixxx might not be a seamless affair. Saying that, Mixxx does have it's own effects plus LV2 support, so a channel path with spatial/EQ fx is still possible, but such a manual overhead would be undesirable. Maybe other Mixxx and/or related OSS plugin code could be utilised.

I'm not a developer though, just a very interested party who would like to highlight possibilities in case others might wish to action them

[Saga Musix]

I know many people for some reason enjoy drowning their modules in those effects but I simply don't get it from a musician's point of view. There is no good reason to apply a global reverb effect on a song. In particular bass frequencies will sound very muddy as a result. Automatic gain control is also a particularly bad effect. Noise reduction does nothing more than applying a 6dB/octave lowpass filter on the whole signal, so all it does is removing treble frequencies. As a result, I think a good reverb (that is not applied to bass frequencies) could work, and maybe a good compressor, but none of the effects that came with libopenmpt can be considered good in that context. They maybe were good 25 years ago. Last but not least, bass boost can be a useful effect but can probably be solved more suitably with a global EQ in the software (or a hardware mixer if you play on stage).

If it's really required, all those effects are still in the OpenMPT source tree and could be just copied over (although I personally still think one should aim for more modern effects as described above). They are all post-processing effects anyway, so there is no need for them to be applied inside libopenmpt. That way they could be applied to all formats, not just modules.

[.^o]

just a quick shot of what it's look like on stage.