interesting lowpass / slow volume ramp which muffles transients *only* when played in a pattern

[coderofsalvation]

First of all, love this tracker, and thanks for all the hard work.

Ok, so here's a simple XM: https://filebin.net/ua5993g4hehmghfz

When you play the sample on the keyboard, it will sound correctly. However, whenever pressing play: the transients (the bright attack at the beginning of the sample) dissappear for some reasons. Is this a matter of adjusting the ramp-up volume of the note-on's?

UPDATE: milkytracker does the same, which might be good news. Is something odd going on with the samplerate etc?

[coderofsalvation]

solved...just added a bit of silence to cheat :)

[steffest]

Actually, most trackers I observed add a little "ramp up" volume-slide when playing notes to minimize the clicking/ticking transition sounds that otherwise occur when you have sudden volume jumps in sample data. Bassoontracker does too. I should probably make that linked to some option you can set. (I've had some requests of removing this altogether, which in case of these tiny chiptune samples makes sense.)

[coderofsalvation]

Right, well at least Bassoontracker acts consistent with milkytracker's default (which I guess is based on other default values). Thanks for the heads up!

On Mon, Apr 26, 2021 at 1:09 PM Steffest @.***> wrote:

Actually, most trackers I observed add a little "ramp up" volume-slide when playing notes to minimize the clicking/ticking transition sounds that otherwise occur when you have sudden volume jumps in sample data. Bassoontracker does too. I should probably make that linked to some option you can set. (I've had some requests of removing this altogether, which in case of these tiny chiptune samples makes sense.)

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/steffest/BassoonTracker/issues/69#issuecomment-826748383, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABL6ZGGLOMDX6GL56SOIHLTKVCXFANCNFSM43PM5YQQ .

-- L Ξ Ο N V Λ N Κ Λ Μ Μ Ξ N

Senior creative technologist & researcher https://2wa.isvery.ninja/hello https://www.linkedin.com/in/leonvankammen

[coderofsalvation]

reviving this thread:

Having second thoughts (as a milkytracker dev). Volume ramping is not part of the MOD/XM spec, and is not available in the original xm/mod players/trackers which are responsible for most of the content (protracker/fasttracker). Im also assuming volume ramping does not imply interpolation of XM instrument envelopes (which can cause clicks when poorly implemented).

So if I would reason against my previous argument: clicks/transients can be prevented or intended by the composer by adjusting it in the sample-editor. Volume ramping is a user-setting which should be always turned off, after loading a new mod. In milkytracker, we've had similar concerns regarding the limiter, which has been solved by allowing a 'reset after module load'-checkbox:

read the conversation about it

Im thinking to also apply this to volume ramping..

I mean, a volume ramp with a predetermined (which?) fade-length is an opinion (of who?). Default volume ramping causes an uncertainty to workaround for composers (if you want to ensure snappy drums). It also undermines the predetermined clipping value of XM/Mod from the spec, which composers often want to drive their mix into (musical digital clipping is a tool).

Im starting to think it should be a non-default optional setting, with auto-reset turned (see GIF) on by default.

Another thought, is to only volume ramp when a notesound is cutted (via volume-command by another note). This would still reduce clicks to a certain degree, but I also feel yet-another-ramping-strategy makes mod/xm-playback is not going to help.

WDYT?

[coderofsalvation]

I've added a commit which resets any playback-features which are not in the XM/MOD spec, when loading a module:

I think this a step towards more uniform (expected) playback for composers.

[steffest]

Awesome! I especially like the "if sample.floats[0] == 0:" check. That could totally work.

Alse very interesting thread on the Milkytracker Github.

I'll have a fresh think on this matter. On one hand, yes: it could/should primary be up the author of a song if he intended the song to have any volume ramping, and secondly up the the user if he wants that.

On the other hand... I have given up on the idea that a tracker should sound "100% exactly like the original" It's just not possible because you never can tell with 100% accuracy what "the original" was ? Apart from the obvious different behaviour of trackers and tracker version, even an Amiga 500 sounds different than a Amiga 1200, and some modules sound different with fast CPUs than with slow CPUs (e.g. with ED0 command) etcetera, etcetera, etcetera, ... I come to think of trackers as some kind of orchestra that plays a piece of sheet music. It's OK to have slight differences in sound, as long as it's not just "plain wrong"

Or like how some/most sound systems have post-processing filters like "bass-booster", "surround level", "stereo field enhancer" ... all colour the sound, some people like them, some don't.

Yes, you're right that the volume ramping implementation is based on opinion, just like all those audio-enhancement features and plugin, but is that a bad thing? And do you really want to overload an app with a gazillion options that 99% of the users don't care about or don't know what they mean?

Maybe I'm just making up excuses. (probably .... yeah ... definitely :-))

So: my 2 cents after this rant: Yes: volume ramping should be a setting, and I'll add that in a next release. (Re-opening this issue so I don't forget) But I'm inclined to keep the state of such a setting the same across sessions. Exactly like those audio enhancers/ filters of audio gear: if a user likes them, a user likes them, and if you're an author of music, you will want to listen to your track on different gear anyway.

[coderofsalvation]

I totally agree with many things (which might be offending to some sticklers):

• MOD/XM playback is way more accurate compared to a 'general midi' .mid file
• but accurate playback is a endless rabbithole, even with .wav :)
• people like to tweak their experiences (game-modding, game-shaders, audioplayer fx etc)
• at the end of the day batteries-included settings are up to the dev
• opt-out is great in such case

Regarding the ramping-algo, I'm not superhappy with milkytracker's volume ramping. I totally like the way it reduces clicks when notes end, or are cut off by other notes. However, with note-onsets of drums it really turns drum-transients into fluffy soup of sadness. However, perhaps we need to experiment a bit with that adaptive code-example (which I accidentally erased when updating my previous comment):

# note-onset volume ramping to preserve drum-transients
if sample.floats[0] == 0:
  return sample.floats[current]    # all good, no clicks expected
else
  return zeroUntilFirstZero( sample.floats, current)  # feed zero's until first zerocrossing to prevent clicks

That way we prevent excessive peaking, and only clip when intended.

[coderofsalvation]

fyi:

latest milkytracker now has 3 ramping modes:

• 0 no ramping [MOD]
• 1 ramp-out [default, keeps transients]
• 2 ramp-out + ramp-in [FT2]

We did not bother with variable ramping like openmpt, as this fixes most usecases quite well already.