[SMS] can't seem to be able to play two drum hits at the same time. nor at their own volumes

[bazz1tv]

This is from Xyz I believe this is pertaining to rhythm mode / ROM drums...

[Xyz39808]

Yes this is about YM2413 (OPLL). The operation is normally that it has 9 channels (XPMCK channels E-M) but if you set bit5 on OPLL register $0E (XPMCK command M1), then it enables rhythm mode which converts the last 3 channels into becoming 5 different drum hits: bassdrum, snare, hihat, cymbal, tom.

During this mode, there are 3 registers which store each drum's volume. The current XPMCK limitation of setting all channels at once is an artificial limitation. Bassdrum vol: low 4bits of register $36 Snare vol: low 4bits of register $37 hihat vol: high 4bits of register $37 cymbal vol: low 4bits of register $38 tom vol: high 4bits of register $38 It should be noted that these are attenuation values, so a value of %1111 will mean the drum is silent.

Once those volume are set, then back on register $0E you have the keyon/keyoff bits. Setting bit4 triggers the bassdrum, bit3 the snare, bit2 the hihat, bit1 the cymbal, and bit0 the tom. As these triggers are done bitwise, it should be obvious that there are 32 ways to trigger drums, silence included. XPMCK currently has an artificial limitation of sending only one drum at a time.

My suggestion is to implement these register writes to be compatible with the mml notation seen in the MSX driver MGSDRV. Which has the following commands: vb# - set bassdrum volume, range 0-15 vs# - set snare volume, same range vh# - set hihat volume vc# - set cymbal volume vt# - set tom volume.

MGSDRV also has two ways to input all the rhythm commands, either on channel K (the first of the latter 3 channels), or on a new channel R. It would see any rhythm commands on channels L or M as invalid and fail to compile.

It also introduces new note commands that easily facilitate the 32 trigger combinations. b# - only bassdrum triggered with # length value (similar to c4, c16 etc.) s# - snare only h# - hihat only c# - cymbal only t# - tom only bs# - bassdrum+snare ... bshct# - all drums triggered. Trying to input normal notes like c c+ d d+ etc on the rhythm channel will make the compiler give an error.

I don't know for certain if doing something like b16 while a cymbal is already set to %0010 0010 (rhythm enabled + cymbal triggered on) will overwrite the cymbal bit1 to become 0 or it MGSDRV will only seek to flip bit4. They sound off too quickly to really test this anyway so the difference may be negligible.

As a side note, in MGSDRV you enable rhythm mode using a header which means once the song is set to rhythm mode or melody mode it's stuck that way. This too is an artificial limitation and it may be nice to keep the current XPMCK method of using command M0 to switch back to melody mode and M1 to switch to rhythm at will. Something to consider.

[bazz1tv]

Bear in mind all this OPLL / rhythm mode stuff is completely new to me. I took some time to carefully read your post. Allow me to summarize and get some feedback from you again.

XPMCK has an artificial limitation in setting all rhythm instruments volumes at once, rather than individual of the 5 possible instruments.

XPMCK currently has an artificial limitation of triggering only one drum at a time, although 32 trigger combinations are possible.

---

(based on reading your post) -- So you mean to tell me XPMCK somehow managed to use 3 channels for rhythm mode and somehow is incompetent to MGSDRV's single R channel implementation?! hah! I wonder what led to such a seemingly bad implementation...

Is it possible to retain all of the regular Channels while just adding the Rhythm channel? Because if it's possible, I don't see the point in sacrificing a pre-existing OPLL channel.. (This is why I gravitate to the "R" channel addition you mentioned about MGSDRV)

---

If I properly understand everything.

• Keep M0,M1 way of deactivating and activating rhythm mode so it can be done potentially mid-song.
• Add a Rhythm channel (R)
  • Accept volume commands for each of the 5 rhythm instruments
  • Accept triggering of all 32 trigger combos for the rhythm instruments

[Xyz39808]

Yep you got that summary down.

About channel management, it really is up to ya'll how you wanna handle it. To me, it makes no sense to have such a thing as channels K L an M even existing while rhythm mode is enabled. It is also weird to have such a virtual channel R hovering around in a state of nonexistence while melody mode is enabled instead. (though a virtual channel isn't unheard of, it exists in VortexTrackerII for the noise and env speed)

You would probably have to take into account what the compiler should do if a user tried to input commands on channel K-M and R at the same time. But overall, just implementing an R channel then figuring out where how to handle melody mode conflicts seems to be the way to go.

[bazz1tv]

You are OK with KLM floating during rhythm mode (me too), but you are not fond of R "floating" during melody mode. Yet, what other solution could there be? (you did not actually mention any alternative). For the sake of continuing my thought process, I am just assuming that we already have the ideal solution.

KLM floats during rhythm mode, R floats during melody mode

Having the channels float at least could save on pattern data, rather than force the user to write channels with large sections of rests to match the other channel lengths (a waste of ROM and effort)

---

In fact, this is causing me to think of a new set MML commands ("deactivate channel", activate channel) that could, as I see, serve 2 purposes:

• to save space against large "rest" sections
• to re-sync channels without having to explicitly "length-match"

These commands would be implemented "under the hood" for R / KLM channels, with the M0/M1 commands as the trigger, but could be made into legit MML commands for users to gain the same benefits.

As legit MML commands, "Deactivate channel" should be called from the channel you wish to deactivate "Activate channel" must be called from a separate active channel, which will bring the activated channel directly in sync with this channel"

---

I did some reading on the OPLL Rhythm Mode.

Is it really possible to play up to 5 sounds simultaneously on Rhythm Mode, even though only 3 channels appear to be used for rhythm mode -- are they mixed down or something?

Is it true that there are actually 6 rhythm instruments (2 Bass Drums), although only 5 can be active?. Do you somehow select the active ones (slots?) via F-Num? I don't know how slots work on this thing...

reference: http://www.smspower.org/maxim/Documents/YM2413ApplicationManual#iii17

---

[bazz1tv]

For the record, of the 3 known SMS output formats (ROM/SGC/VGM), which reliably export and play FM properly? XYZ states

I'm not sure how to confirm for SGC since I can't tell if bad SGC playing is a problem of XPMCK or either nezplug or foobar2000

21 shows that VGM-export needs improvement to shut off rhythm mode.

It is unknown how the ROM FM is functioning at the moment.