<Paulius> as milky ever considered supporting stereo sample playback?
<coderofsalvation>good question! many times!
It would require adding a new tracker-format OR improving .it playback support (as XM, the spirit of milkytracker, does not support exporting it).
Since that's not an easy task (at least for me it would take years), it really requires the right person at the right time for that.
High-capable folks like @8bitbubsy knows more about the art of reproducing module-playback (he made both pt2-clone and ft2-clone, which is insane).
<8bitbubsy>I would definitely not call myself "high-capable". The amount of times I need to scratch my head over something simple is probably a Guinness World Records candidate. And to be frank, I mostly port existing code, written by the guys that were really smart. 😄
While you technically do not need a new format for stereo samples in XM (OpenMPT already supports this by just using one of the free sample flag bits), it definitely is good practice to do make a new file format for it. OpenMPT and MPT were kind of evil back in the days, adding existing features to the older formats so that people make more tunes that are not compatible in the original trackers, nor many of the replayers.
Disclaimer: Opinions are my own. "Evil" is of course an exaggeration. Also I may or may not have added full 128kB sample support to PT2.3F on Amiga, which kind of is the exact same thing I'm advocating against. Oops! (though the format perfectly allows for it, just buggy/poor replayers)
<coderofsalvation> @paulius1k @8bitbubsy this ties back into how the usecases of sampletrackers multiplied over time:
1. source distribution/playback of modules (opensource, directly editable format, netlabels, demogroups)
2. pre-rendered distribution of module-output as .mp3/.wav (traditional recordlabels, streamingplatforms, websites)
3. many more usecases
I think adding stereo-support for milkytracker makes sense for usecase #2, but is orthogonally opposed to #1 (as @8bitbubsy pointed out).
I wonder how it differs from the 'limiter' (see settings) in milkytracker..its great for usecase #2..but after consultation with trackerdevs (like @8bitbubsy and SagaMusix), to respect usecase #1 **milkytracker resets the limiter** as soon as a new module is loaded (**see screenshot below**).
I usually do stereostuff manually (pan both tracks differently, and offset one sample via `902` for haas-effect e.g.)..so there's a bit of a catch22:
If we'd introduce a similar checkbox: 'evil stereo sample support", then it would degrade usecase #1 (which would sound different).
Another take on the idea is: **stereo sample support from a UX-perspective** which honours both 1 & 2:
1. when importing a stereo .wav (`bbeat.wav`)
2. load left-channel on sample 1 of selected instrument
2.1 hardpan left in instrument settings
2.2 prefix the sample name with `L_` (`L_bbeat.wav`)
3. repeat the same for right-channel (hardpan right + `R_bbeat.wav`)
4. when entering notes in the pattern editor, it would write a left+right note on 2 tracks (when `L_` + `R_` are detected)
We could extend the import-dialog by setting '3' (all) as default for such behaviour..probably index 0 is better as there are >2channel .wav files:
initial question from discord chat:
We could extend the import-dialog by setting '3' (all) as default for such behaviour..probably index 0 is better as there are >2channel .wav files: