Hold Effect (&&) Bug about dn-famitracker

[N-SPC700]

Weird, I don't remember this being an issue in previous versions...

Anyways, I went ahead and checked this out myself, and I can also confirm this bug is existent in the latest version. What's more is the VRC7 implementation still retriggers slightly despite being told not to retrigger. As for the other chips, the Sunsoft 5B doesn't seem to suffer from this (both using a macro and manual Vxx selection). I'm assuming the tracker is still assuming the && is a "unique" instrument, and thus uses the macro this "instrument" uses (which it doesn't have one, hence the V00). Seems like it might require a bit of refactoring for how instruments are handled...

[RaijinXBlade]

It is actually an issue with the 5B too. All you need to do is enable the noise/mode envelope and add one to it, then place 2 notes down in the pattern, with the second having && applied to it for an example (this example more or less works the same way for the rest of the chips, although you need to change the duty setting at least). This bug can be heard with all chips.

[nyanpasu64]

I've looked into this behavior before, and documented its current behavior:

• Google doc
• Test case (.0cc file)

I don't know when this behavior started. Perhaps I changed &&'s behavior when I fixed "too-long envelopes crash the program" many years ago? I don't know if changing this behavior will break existing modules composed around the current behavior.

[N-SPC700]

All you need to do is enable the noise/mode envelope and add one to it, then place 2 notes down in the pattern, with the second having && applied to it for an example

Re-tested this, with some interesting results:

• If a Vxx was applied prior to the && instrument, it uses that specified Vxx instead
• If there was no Vxx, use the default V00 (and in case of the 5B, V01 for squares only)

These conditions match the conditions of a "blank" (no macros enabled/used) instrument, so it seems it's treated as such.

[nyanpasu64]

it's been broken for a while, tested in 0cc 0.3.14.5 (didn't try earlier versions) and 0cc 0.4.0 (latest dev commit), and behavior is the same as dn at casual inspection. i didn't look deeply. but i know that notes with && don't behave "correctly" for non-looping duty envelopes in 0cc, but still overwrite them with Vxx.

[RaijinXBlade]

I suppose that means it's entirely possible Hertz didn't implement it correctly from the start. Either that, or it broke very early on, which seems more unlikely since it was only implemented a couple of versions before (0.3.14.3 iirc).