I realized that trackers could be perfect for DJing, given that they are mostly one shot samples being manipulated. That means that tempo can changed easily with no artifacts and syncing separate songs might be trivial.
Is there a way to play two or more tracks in OpenMPT at the same time? If one could simply sync the play button of a track to the already playing one, that would be totally great.
I would love to experiment with that.
I know some people have done this with manual syncing. However, it could also be possible to use a MIDI controller for controlling playback of two separate OpenMPT instances (OpenMPT shortcuts can be bound to MIDI CCs, or you can enable OpenMPT to respond to MIDI play/stop messages). One could use two different keyboard mappings where the same MIDI CC stops the playback on one instance and starts playback on the other. However it is important to note that device initialization would not be synchronized between those instances. But if the device is already running, that might not be a problem. It's worth experimenting with this idea.
I also tried implementing limited to support for MMC messages (https://en.wikipedia.org/wiki/MIDI_Machine_Control) a while ago (in particular MMC Locate) which could help here, but that hasn't landed in the repository (yet). In particular I don't have any hardware that supports these messages so that makes it more difficult to test.
If you don't need manipulation of tracker (in particular pattern) data, a custom tool could be built on top of libopenmpt, which can change playback speed and pitch independently, and also trigger samples outside of patterns.
I think the MVP here could simply be the ability to play two modules at the same time within one OpenMPT instance.
The reason for this is that not all tempo is the same. Tempos could be the same as a matter of fact, but be expressed through different tempo numbers due to a different ticks per row count. I am fine with adjusting this manually.
The reason I want this option within one OpenMPT instance is precisely the one you mentioned: I need the device to already be initiated.
Question is - how trivial is it to build an OpenMPT version that allows to mix modules together?
Quote from: Louigi Verona on October 18, 2019, 13:15:06
Question is - how trivial is it to build an OpenMPT version that allows to mix modules together?
If you want it to be a cheap hack - not that difficult probably. Practically, to have this as a usable feature that we could distribute and maintain - a lot more work.
I think that it might be interesting to have a unique build with a cheap hack, so that I can try it out. It might be that the idea is more interesting than reality.
Well, just to make it clear - "not that difficult" is still at least a day or two of work, and I personally don't have that time to invest into a hack right now.
Understood. No worries, I will try to experiment first and see if any of this is even worth it. But still, this is a very interesting venue to explore.
There used to be an option to have OpenMPT as VSTi in another daw. I don't know the status of this project though, and I think by now it is obsolete maybe (or at least a very old version)? But that would solve your issue.
That was a third-party hack over ten years ago that never made it into the official code. It should also be noted that it didn't solve any of the synchronization issues that would still be there.
One thing that I can also try is writing a tune in real time within one pattern and using the SBx command or smth like that. I will think about it. I just realized that DJing with trackers could be perfect in many ways. But no tool is really accommodating this use case and I understand nobody could be expected to put in work for this strange use case.
Something that you may also look into is pattern queuing (middle-click or ctrl-click an order list item). This could be very useful in particular in combination with some silent pattern.
If you want to try the "tracker in a DAW" approach, you could also give reViSiT a try (but that is also no longer being developed actively as far as I can see).
And not to mention, muting/unmuting and soloing a channel upon transition. :) But that would not allow you transition from one song to another like a real DJ.
I use OMPT in djing for years.
With two OMPTs in one or two eeepc with one to four sound cards, connected to a mixer.
The setting of the tempo on the fly is sufficient.
And the fine tempo setting brought by Saga is perfect for a precise synchronization with other artists without even a MIDI connection.
Just perfect :)
I also render songs as wav and mix with DJ softwares.
Quote from: .^o on October 23, 2019, 06:11:58
I use OMPT in djing for years.
With two OMPTs in one or two eeepc with one to four sound cards, connected to a mixer.
The setting of the tempo on the fly is sufficient.
And the fine tempo setting brought by Saga is perfect for a precise synchronization with other artists without even a MIDI connection.
Just perfect :)
I also render songs as wav and mix with DJ softwares.
Can you record your workflow on YouTube? Would be super interesting to see this being actually done.
No sorry I'can't video record now.
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):
https://www.mixcloud.com/ivogravos/gravos-2013-o-incidmemoriamspainteaser/ (https://www.mixcloud.com/ivogravos/gravos-2013-o-incidmemoriamspainteaser/)
https://www.mixcloud.com/ivogravos/gravos-2013-o-dmp7/ (https://www.mixcloud.com/ivogravos/gravos-2013-o-dmp7/)
https://www.mixcloud.com/ivogravos/gravos-o-2014-hv-intro/ (https://www.mixcloud.com/ivogravos/gravos-o-2014-hv-intro/)
https://www.mixcloud.com/ivogravos/gravos-o-2014-humanity-vortex/ (https://www.mixcloud.com/ivogravos/gravos-o-2014-humanity-vortex/)
https://www.mixcloud.com/ivogravos/gravos-2013-o-a-m-e-n-dd-11-project/ (https://www.mixcloud.com/ivogravos/gravos-2013-o-a-m-e-n-dd-11-project/)
https://www.mixcloud.com/ivogravos/gravos-o-2011-mutations-dancefloormx-10/ (https://www.mixcloud.com/ivogravos/gravos-o-2011-mutations-dancefloormx-10/)
https://www.mixcloud.com/ivogravos/gravos-o-2011-mutations-concept-10/ (https://www.mixcloud.com/ivogravos/gravos-o-2011-mutations-concept-10/)
or older:
https://archive.org/details/GRAVOS-2010-.o-170PETITSCORPSFULL.05.01.10 (https://archive.org/details/GRAVOS-2010-.o-170PETITSCORPSFULL.05.01.10)
https://archive.org/details/Gravos2012.oHomofinalisMolotofNowayout (https://archive.org/details/Gravos2012.oHomofinalisMolotofNowayout)
No much more time for composition for now.
Hope soon...
Are folks aware that Mixxx (https://mixxx.org/) 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 (https://i.imgur.com/gI8zoGE.png) and options (https://i.imgur.com/S5SqWFS.png).
If anyone does C++, tempo data isn't used by Mixxx for bpm yet (https://bugs.launchpad.net/mixxx/+bug/1858247).
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 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.
lol ;D
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.
Quote from: Saga Musix on January 07, 2020, 10:18:27
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 (https://blueprints.launchpad.net/mixxx/+spec/mod-music-playback) (then asked the devs in their Zulip chat to enable by default last year).
A commit search shows it was initially added in 2012 (https://github.com/mixxxdj/mixxx/search?o=asc&q=modplug&s=author-date&type=Commits). 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.
QuoteEdit: 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 (https://github.com/echolevel/chipdisco) by Syphus/Echolevel (https://www.youtube.com/user/bdse)
QuoteHehe, 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. :)
QuoteIt 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).
Quote from: Saga Musix on January 08, 2020, 23:56:25
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 :)
Quote from: .^o on October 26, 2019, 17:19:50
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.
Haha, I've just realised that Arch Linux, which I use (btw, so goeth the meme), has libopenmpt-modplug (https://aur.archlinux.org/packages/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?
QuoteEnjoying the mixes btw! Very tek.
THX
QuoteEdit: 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.
Quote from: Saga Musix on January 09, 2020, 12:05:00
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 (https://lib.openmpt.org/libopenmpt/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 ;)
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.
just a quick shot of what it's look like on stage.
(http://img115.xooimage.com/files/f/e/5/omptl15mon-56ffb07.jpg)