Language…
11 users online: Batata Douce, crocodileman94, Darolac, DasFueller, Dzing, Gamet2004, Hammerer,  icrawfish, jump_run_repeat,  Nanako, Rykon-V73 - Guests: 280 - Bots: 330
Users: 64,795 (2,377 active)
Latest user: mathew

dealing with the gaps between notes

Hi,
Yesterday I was doing a port by request, and because the music was laid back, I decided to use a tempo twice as high as I normally would have. For example, instead of using t39, I used t78 or thereabout. Combined with $f4 $02, I feel this helped improve the overall feel of the port, because the gaps the nspc engine introduces between notes were reduced.

I did some more experimenting today and found that using tempos above t60 is generally not a good idea as the readme hints at. A few of my ports seemed to have just a touch of slowdown with a tempo in the high 50s. #halvetempo doesn't seem to do much for me if slowdown does occur. It might reduce slowdown but I don't think it really goes away. Also I've noticed that the faster your tempo goes, the more dramatic slowdown becomes, and the easier it is to make happen. Just adding a channel with a few notes on it, at insane tempos anyway, is enough to make slowdown happen throughout the entire track, even if some of the channels are silent. I even remember one time the tempo actually slowing down as I increased it in the txt.

I know absolutely nothing about assembly or the NSPC engine when it comes to that level of technicality, but I found this interesting. I know AMK1.1 is meant to optimize the engine and dramatically reduce slowdown, but I haven't tested it in these cases.

No doubt there are ways to work around this even at slower tempos. Using $f4 $01 is a common thing that works. I also managed to eliminate the gaps by spamming the $f4 $01 command, like so:
Code
$f4 $01 c $f4 $01 $f4 $01 d $f4 $01 $f4 $01 e $f4 $01

Which plays c d e, rekeying the note each time, but without a gap. This produces objectionable clicking, but for drums in particular I've found it useful, though I don't do it in anything I intend to be used in smw as it will really inflate insert size for little real benefit.

So what I'm basically wondering is, what is it that creates the gaps between notes? It sounds like a gain fade to my ears that takes effect on a note to ramp it down a tick or two before the next note. But, I really don't know. I've heard this sort of ramping between notes with many other games, and presumably many other engines too. A few don't, though, and in those cases you either get really clicky sound, or rarely, it actually sounds good. Software Creations games seem to use a very different engine which lends well to nearly gapless notes. Winter Gold FX also sounds like its notes have smoother transitions. Maybe my ears and brain are playing tricks on me, but I don't think AMK could easily replicate that. I wonder how they do it and am curious about what would at least hypothetically be done to AMK if tomorrow it was to have its gaps between notes reduced.
Make more of less, that way you won't make less of more!
This is a wild guess, but maybe you shouldn't be toggling legato ($F4 $01) on and off like that? Maybe if you just leave it toggled on for the notes you want to play gapless it'll sound better and clickless (and wasting less ROM or RAM as a bonus), because as far as I know, when legato is in effect there are no ticks between notes so in theory they should be 100% gapless.

I don't have technical reference to back me up, it's just what I think I've heard from someone with more knowledge, so I might be wrong.
Legato does produce notes without a gap but the notes are not rekeyed or restarted. So if there's an ADSR on the notes it will continue to sustain or decrease even as new notes come in, and the sample will keep on playing instead of restarting from the beginning. This is useful in many situations. But what I am asking is how some engines managed to rekey notes while having less of a gap. My example with $f4 $01 just illustrates how AMK can sort of be brute forced into removing its own gaps while still rekeying notes, but this produces clicks because the samples are very abruptly being cut and switched out. Here's an example of a game that does it more or less properly. There's little if any cllicking and the gaps are minimal. The guitars perhaps show it most obviously. Even if you solo channels in the spc they still sound fairly smooth. If you slow them down in Snes SPC700 player, you start to hear gaps but they are smaller than those in AMK, or most other games for that matter..
Make more of less, that way you won't make less of more!
Oh, I see what you were getting at now. I checked the SPC track of Bad to the Bone out of curiosity and slowed it down to the maximum and apparently it's indeed using some sort of trick with GAIN and legato as you implied, since by pausing at the right moments I'd notice GAIN was assuming a value of 77 for an instant instead of the usual 78, so maybe that's your best bet with AMK's current engine.

However, I tried experimenting a bit with it by setting two GAIN commands, one with a value of $10 and another with $7F immediately following the previous one, both between two notes, and although they did indeed simulate a rekey there was some noticeable clicking, but maybe that had to do with how I set two commands between notes instead of setting one while the first note is finishing playing, or also the abrupt change in GAIN values I chose, so trying with smaller changes like that used by Bad to the Bone may give better results.

Also out of curiosity, I also tried separating legato notes with an r192 (which I think is 1 tick long) and interestingly enough the gaps it produced were longer than having no legato and only light staccato ($F4 $02), so apparently light staccato already works under time not limited by ticks, so unless you're after sheer perfectionism, that command will probably be good enough for all intents and purposes.
Glad you were able to analyze and make some headway with it.
Unfortunately I am a perfectionist! Though this does not bother me all that much, since as I say, most games exhibit the AMK behavior. The games that don't have this behavior, and which I also like the sound of, are few and far between.

To introduce an odd twist, I do notice that sometimes the Software Creations engine produces crackling sounds when doing volume fades like decay and release. There's a section in Equinox where they use tremolo on a vibe sound where the crackling is painfully obvious, and in bass parts of some songs where that engine was used, you can hear this crackling effect on note releases. So, that engine may be using gain/volume differently, maybe down-scaling the smoothness of it to make room for extra time resolution. It's my best guess anyway, but AMK doesn't seem to have this problem nearly so much. So I guess you can't have your cake and eat it too.

If I was better at the actual technical side I would maybe try to investigate how different engines worked, since on the surface they mostly sound the same (probably because they might copy a lot from nspc), but as I get more involved with Snes music, I notice tiny differences like how pitch slides sound or random other things. I do remember reading once that most companies used nspc as a starting point, or whatever libraries Nintendo supplied, but that Software Creations often wrote their own drivers, with one programmer responsible for the sound driver. So perhaps that is why the sound is different. I dunno, I just find this stuff interesting.
Make more of less, that way you won't make less of more!
Originally posted by musicalman
So what I'm basically wondering is, what is it that creates the gaps between notes? It sounds like a gain fade to my ears that takes effect on a note to ramp it down a tick or two before the next note. But, I really don't know....
Before the next note is played the engine ensures to KEY OFF the channel. So I read KEY OFF reduces envelope volume by 8 every sample, at 32khz that means KEY OFF takes 1/4 of a millisecond??? Tempo affects the precision of the engine and it must ensure that anything currently playing is ABSOLUTELY keyed off before the next note. The gap is "quantized" so to speak, higher tempos allowing finer rests before actual after KEY OFF execution. Legato as you mentioned, is the primary way to prevent such behavior.

Originally posted by musicalman
To introduce an odd twist, I do notice that sometimes the Software Creations engine produces crackling sounds when doing volume fades like decay and release.

They're using software envelopes via Direct GAIN. Because of limited precision it's nigh impossible for truly smooth fades. If the current envelope volume is, for example, at GAIN D 20 and it transitions to 7F a pop/click may occur. This is due to the lack of continuous sample flow/ramping. This scenario is typical when an instrument has not fully decayed and you KEY ON the next note. Alternatively named interrupted sample flow can result in noise, best example is a broken loop point where you hear loud clicks. The flow is not continuous and this misalignment can be perceived as clicking.

The GAIN driven driver didn't seem to key off automatically so it's up to the composer to determine when to key off, legato, and avoid artifacts from unsustained sample output.
Winter Gold FX is also using Direct GAIN for envelopes. So ggamer77 tells me and I believe as well, AMK itself is ill-suited for fancy GAIN. Doing so, anyway, would not only inflate filesize but if you're clever you can use channel volume to achieve more granularity with your sound compared to straight ADSR.

Edited a number of times because sleep is for the weak.
Just another example.

Deset Camp

This original stuff is buttery smooth.

Desert Camp SMW

AMK's not so much. And they're both NSPC.

Listen to them both at 10 seconds in, channel 4 at 25%.
The original has no noticeable dead gap between notes and a gain rest instead.

Don't know how this is done since I'm no programmer.
A few songs in this game do start to click between notes so I'm assuming you cant go too high on the tempo in this engine. But it's never really that high in the first place with most songs being around t30 and still being smooth.
________________________________________________________
Mario the Gaul
Originally posted by ggamer77
Deset Camp
Desert Camp SMW

AMK's not so much. And they're both NSPC.

Listen to them both at 10 seconds in, channel 4 at 25%.
The original has no noticeable dead gap between notes and a gain rest instead.
Well having gained rests definitely makes a difference. I think if you tried adjusting the quantization or using light staccato you should get better results. SMW by default is a bit more "staccatoey." if you leave quantization alone.


Originally posted by ggamer77
A few songs in this game do start to click between notes so I'm assuming you cant go too high on the tempo in this engine. But it's never really that high in the first place with most songs being around t30 and still being smooth.
I skimmed a few but couldn't find the one with clicking you mentioned. I'm suspecting it just might be a "bad" sample with F 7 7 ADSR (if you can link the specific song anyway.) I haven't had clicking issues with tempos excess of 100. My highest might've been t224. It's an unfinished song but from it is at least evidence that higher tempos provide shorter gaps. I think AMK allows up into the 400s, you'd need unreasonably fast notes with potential lag inducing tempos to start experiencing clicks from rapid switching.
Originally posted by ggamer77
The original has no noticeable dead gap between notes and a gain rest instead.

Don't know how this is done since I'm no programmer.

A few songs in this game do start to click between notes so I'm assuming you cant go too high on the tempo in this engine. But it's never really that high in the first place with most songs being around t30 and still being smooth.


That example is probably one of my favorites so far. It doesn't have the problems my game examples do with crackling envelopes, and it even uses echo with surround sound!

How do you know that t30 is used in the original? Are you able to read what's going on in a hex editor or something?

In the AMK version, what tempo was used? Doubling it would help make it more smooth, but might introduce slowdown, as it often does.

I'm also a tiny bit confused about what you mean by the game using gain rests between notes, since it at least sounds to me like AMK is already doing that, it's just using a more sparse resolution. From my informal tests I did a while back, AMK seems to have 48 ticks per beat and using the last one or two ticks of a note for the gain fade. I think? normally it uses two, if you use light staccato it's one.

Speaking of tests. I just put together a collection of tests. In them I attempt to show how different tempos sound, and the advantages and disadvantages of using higher tempos. $f4 $02 was used in all of these. The spcs were generated with AddmusicK1.05. I've yet to test 1.1.

In the test single channel example, I start off with an insanely low tempo and play the same phrase repeatedly, trying to double the tempo on each repetition. The note lengths are adjusted so that even though the tempo is being doubled, the notes sound at the same speed. This is so you can hear how the resolution and the gaps get more finite as you increase tempo. By the fourth repetition at t49, it's starting to sound smooth. The fifth and sixth, at about t100 and t200 respectively, are particularly interesting. t100 sounds pretty good, though it has some subtle clicks. They're not quite bad enough to deter me, though. , 200 introduces more clicks, I think because the ramping doesn't have enough time to finish between notes. If you slow the spc down, the clicks disappear.

testtempo1-4 does the same procedure, doubling the tempos on each file but adjusting the note lengths to sound the same, but this time, it's done to a little stupid track I wrote where all 8 channels are called. The track starts out simple and gradually introduces busier and busier parts to test for gaps and also for slowdown.

testtempo1 is, for most intents and purposes, not smooth enough. That said, stylistically it can sound cool. testtempo2 is probably the preferred one here. testtempo3 has less gaps, being in the t100 range, but it has a lot of slowdown for a somewhat simple track. Testtempo4 tries to mitigate this by using #halvetempo, with little success. If I try to make the tempo even faster, the tempo actually sounds slower. The only way that faster tempos work is by removing channels, so I've pushed it about as much as I can here.

If anyone is bored enough to actually find a use for these tests, go for it! Lol
Make more of less, that way you won't make less of more!
Originally posted by musicalman
That example is probably one of my favorites so far. It doesn't have the problems my game examples do with crackling envelopes, and it even uses echo with surround sound!
The examples you gave weren't related to the N-SPC engine but instead relied on Direct GAIN.

Originally posted by musicalman
In the AMK version, what tempo was used? Doubling it would help make it more smooth, but might introduce slowdown, as it often does.
t79 for the AMK version

Originally posted by musicalman
I'm also a tiny bit confused about what you mean by the game using gain rests between notes, since it at least sounds to me like AMK is already doing that, it's just using a more sparse resolution. From my informal tests I did a while back, AMK seems to have 48 ticks per beat and using the last one or two ticks of a note for the gain fade. I think?
I'm almost entirely certain it's just the typical KEY OFF but the SPC700 play only updates so fast... Thus a high tempo/precise song makes it look like the channel is constantly playing when it's not.

Originally posted by musicalman
Speaking of tests. I just put together a collection of tests. In them I attempt to show how different tempos sound, and the advantages and disadvantages of using higher tempos.

The fifth and sixth, at about t100 and t200 respectively, are particularly interesting. t100 sounds pretty good, though it has some subtle clicks. They're not quite bad enough to deter me, though. , 200 introduces more clicks, I think because the ramping doesn't have enough time to finish between notes. If you slow the spc down, the clicks disappear.
It's an audio issue indirectly related to tempo. Like you said it's ramping. Slow the attack on the ADSR or if you have a sample that doesn't "violently" attack the clicks are non-existent. For those making there own samples it's generally a good idea to use a fade in for the first 16-32 samples unless it's REALLY short.

Originally posted by musicalman
testtempo3 has less gaps, being in the t100 range, but it has a lot of slowdown for a somewhat simple track. Testtempo4 tries to mitigate this by using #halvetempo, with little success. If I try to make the tempo even faster, the tempo actually sounds slower. The only way that faster tempos work is by removing channels, so I've pushed it about as much as I can here.

Apparently vibrato is an intensive command. Commented out the vibrato and slowdown begone! Figured because I only met slowdown issues when the songs I had employed vibrato.
Originally posted by Brozilla
The examples you gave weren't related to the N-SPC engine but instead relied on Direct GAIN.


Figured as much. I really don't know a whole lot about how the nspc engine plays a part in this, I only assume really. Lol

Originally posted by Brozilla
Slow the attack on the ADSR or if you have a sample that doesn't "violently" attack the clicks are non-existent.

Really? I thought the click was caused more by the key off at that point and the attack would be less important in that case. Haven't tried what you suggested, though. I should at some point.

Originally posted by Brozilla
Apparently vibrato is an intensive command. Commented out the vibrato and slowdown begone! Figured because I only met slowdown issues when the songs I had employed vibrato.

Makes sense, the vibrato does sound very smooth and so it's probably taking up a lot of resources to accomplish that. I should try to see how much vibrato makes a difference. I do use vibrato a lot so not being able to use it would probably be reason enough for me to avoid those tempos.

With amk1.1, I do remember playing with vbibrato once with the #efficient and #semiefficient commands, which introduce a graney quality to the vibrato in particular, so maybe once AMK1.1 is officially released, and if people insist on using a tempo that fast, those commands may save them at least to a point. Lol
Make more of less, that way you won't make less of more!
Originally posted by musicalman
Figured as much. I really don't know a whole lot about how the nspc engine plays a part in this, I only assume really.
It's pretty irrelevant actually. The most important thing is Direct GAIN, limited time precision of the SPC700 prevents Direct Gain [Gain D] from being as smooth as the 16-bit DSP's other GAIN modes and ADSR.

Originally posted by musicalman
Really? I thought the click was caused more by the key off at that point and the attack would be less important in that case. Haven't tried what you suggested, though. I should at some point.
To test it you can set the ADSR to something like $ED $7D $E0. For your SPC I just used a custom string sample, everything else is the same. KEY OFF is extremely fast so you're likely to run into other problems than the limitations of the actual DSP.


Originally posted by musicalman
With amk1.1, I do remember playing with vibrato once with the #efficient and #semiefficient commands, which introduce a grainy quality to the vibrato in particular, so maybe once AMK1.1 is officially released, and if people insist on using a tempo that fast, those commands may save them at least to a point. Lol
I think with the default #amk 3 without #efficient you should still get less slowdown. At least the tempotest4 you gave seemed to have no lag with vibrato on the 1.1 Beta. Instruments with "startup lag" are the ones often affected by the gap from lower/higher tempos.
Originally posted by Brozilla
with the default #amk 3 without #efficient you should still get less slowdown. At least the tempotest4 you gave seemed to have no lag with vibrato on the 1.1 Beta. Instruments with "startup lag" are the ones often affected by the gap from lower/higher tempos.

Yeah, not surprised. What do you mean by startup lag? Are you referring to things with a longer attack ADSR, for example?
Make more of less, that way you won't make less of more!
Basically samples with slow attacks. The best example is something that's non-marcato. Wanted to use a piano but mines couldn't generate an extreme case.

Cello Spiccato Strings will be our test subjects. The _long brr has the entire attack sampled whereas the _short is the work of me trimming 512 samples of startup. **This SPC plays a loop, 4 times, for our long brr and 4 times for our short. The startup is bad enough to fail the eighth note sequences. Both samples have the default F 7 7 ADSR.
"Startup Lag" is an arbitrary name but it's more for people who make their own samples (such as yourself) There are some SNES samples with behavior like this and also stresses how important "the gap" is. Which is partly why I'm very involved in this topic #smrpg{<3}



**I had volume set to 50% so the SPC wound up twice as loud as expected.
Haha so you noticed/remembered I do my own samples.

Yep, I always trim my samples so that the first few milliseconds contain very audible audio, in some cases I cut into the attack as you did, and if needed restore the attack with ADSR. It gets on my nerves when, as a sample plays down a scale, the gaps between the notes get longer and longer because it's not well trimmed.

I wasn't really getting at this though when talking about gaps between notes in this thread. I was more referring to the engine's gaps, which you'd hear with SMW samples, or other simple wavetables/well-trimmed things.
Make more of less, that way you won't make less of more!
Figured but I brought up the samples because I think we have sufficient data to understand the issue. Off-topic though, as nostalgic as SMW it'd be nice to see more sampled music since only a handful of members actually push it to the limit.

Problem: There is a gap when playing notes in succession.

Why: I didn't write AMK or N-SPC so this is only a conjecture. Tempo affects the stepping/precision of the note data. Similar to a ruler. Slow tempos might increment every decimeter, faster increments centimeter, even faster millimeters. KEY OFF is placed at some point before the next note. As precision increase it's quantized finer to the position. This point can be moved via quantization commands.

Solutions: Use $f2 $04 (light staccato), 'q' syntax command or increase the tempo. All afforementioned will reduce the gap generated by AMK.


From the Super Famicon Wiki it says KEY OFF takes 8ms which is actually longer than I thought, 32x to be exact (I must've misinterpreted the other document.) That being said you're probably right that higher tempos can prevent a KEY OFF from actually completing. Though, from a musicians' point of view, it's just volume ramp down.

The topic revolves around KEY OFF and that is the 16-Bit DSP's way of ramping. N-SPC Engine uses hardware ramping (our DSP) but it needs a position in time to write the KOF register $5C. Engine limitations prevent the KOF register to be written precisely 8ms before the next note. This imprecision is the length of the gap. Shorter gaps imply KOF is executed closer to the next note.
You can bypass ramping altogether but it's your job to make sure there is continuous sample flow. The cause of popping, clicking, and ill effects are the result of disconnected or abrupt sample behavior which results in a very displeased waveform.
Originally posted by Brozilla
It'd be nice to see more sampled music since only a handful of members actually push it to the limit.


Same here. I'd be curious to know how exactly you'd be interested in pushing it to its limit.

Originally posted by Brozilla
Tempo affects the stepping/precision of the note data. Similar to a ruler. Slow tempos might increment every decimeter, faster increments centimeter, even faster millimeters. KEY OFF is placed at some point before the next note.

I think my theory about the 48 ticks per beat may be a more direct explanation. Here is some code to illustrate:
Code
#amk 2
?
$f4 $02
t2
#0 o4 l16
@22 [v255 c192 v150 c192 c192 c192 c192 c192]99

#1 o3 l16
@0 $ed $7f $e0 v130 c4 c4

The tempo is really slow so we can hear individual ticks and tell what's going on. #0 contains notes at a length of 192, which I believe is the smallest length you can have. IN the example, I spiced it up a bit and accented every sixth note, which will make it easier for counting purposes which I will describe below. On #1, I put a couple c4s, each obviously represents 1 beet. If you carefully count the c192s, in this case the high hats, you'll notice that after 47 of those, the long c4 note cuts off on the 48th one, leaving it playing alone. Then the c4 comes back in on the 49th note. In other words the gap between the c4s is one tick wide. If you comment out/remove the $f4 $02, then the 47th and 48th note are played alone, so the gap is two ticks wide. At reasonable tempos where the ticks are much more closely spaced, the effect caused by using or not using $f4 $02 just amount to a difference in the smoothness, but if you speed up the tempo of my example and slow the spc down, the tick counts I mentioned will still be accurate.

Originally posted by Brozilla
N-SPC Engine uses hardware ramping (our DSP) but it needs a position in time to write the KOF register $5C.

I know nothing about registers and the like, so I would be pretty lost if you spoke about these in depth. I wonder how exactly the key off is accomplished. AT first I thought it was a gain decrease, but after experimenting a bit I can't get gain to sound like a key off. It can do fast fades like a key off does, but none that sound the same. So I guess it's not that, but I could very well be wrong.

I wonder if the version of NSPC used in the example which Gamer77 posted just natively runs at a higher resolution by design, so doesn't have the slowdown that AMK does when you push it too hard. Either that, or if the resolution is still 48 ticks per beat, maybe it has some way of delaying key offs to produce the best compromise, instead of on a tick like AMK seems to do.

Quote
You can bypass ramping altogether but it's your job to make sure there is continuous sample flow. The cause of popping, clicking, and ill effects are the result of disconnected or abrupt sample behavior which results in a very displeased waveform.

I've thought about attempting this, but I can't imagine making smooth transitions from sample to sample. There'd be no easy way to avoid clicks once you compress to BRR and put everything into AMK. I think I once got it to do strange things while trying to switch pulse wave duty cycles though, once again trying to break the $f4 $01 command, but I'll have to try to remember how I did it. Not that it would be very useful, though. In any case, forcing AMK not to ramp only seems useful to me in certain circumstances. Maybe for loud bright drum sounds where a click would not as easily be heard. But I'm sure I'm not the most creative or knowledgeable person out there haha. Someone is bound to think of something I don't.
Make more of less, that way you won't make less of more!
Originally posted by musicalman
Same here. I'd be curious to know how exactly you'd be interested in pushing it to its limit.

It's very opinion based I'm probably more referring to an SMW hack that overhauls the entire sample set. We have access to more instruments and tools that should enable us to reach pinnacle SNES audio without much trouble.

Originally posted by musicalman

I think my theory about the 48 ticks per beat may be a more direct explanation. Here is some code to illustrate:
Code
#amk 2
?
$f4 $02
t2
#0 o4 l16
@22 [v255 c192 v150 c192 c192 c192 c192 c192]99

#1 o3 l16
@0 $ed $7f $e0 v130 c4 c4

At reasonable tempos where the ticks are much more closely spaced, the effect caused by using or not using $f4 $02 just amount to a difference in the smoothness, but if you speed up the tempo of my example and slow the spc down, the tick counts I mentioned will still be accurate.

Examples are definitely better than analogies in this case. That being the said it would seem 'q' command increases the number of ticks on for the gap with that statement.
Quote
I wonder how exactly the key off is accomplished. AT first I thought it was a gain decrease, but after experimenting a bit I can't get gain to sound like a key off. It can do fast fades like a key off does, but none that sound the same. So I guess it's not that, but I could very well be wrong.

Accordingly it's done by decreasing envelope volume by 8 at 32khz. If the reference is correct then the most accurate GAIN to disguise KEY OFF is $ED $80 $9C. Envelope volume is multiplied to the current sample/waveform height. When envelope volume is zero, as you know, anything multiplied by zero becomes zero.

Quote
I've thought about attempting this, but I can't imagine making smooth transitions from sample to sample. There'd be no easy way to avoid clicks once you compress to BRR and put everything into AMK.

It's not really a SNES problem but just audio in general. Let's pretend we have no ramping and come across a rest. It would be a "Note Cut" effectively ending the waveform, from 7797 to 0 in one sample. Essentially the equivalent of running into a brick wall. You'd feel much better running into layers of pillows. With ramping our waveform would then go 7797 -> 974.63 -> 121.83 -> 15.23 -> 1.90 -> 0.24 -> 0.03 -> 0.00
That is 8 samples at 32000khz. Ramping is not necessary on more advanced systems. This is a rather subtle example (it's somewhat a real world case) but the *files in the folder has a note-cut versus note-off. When you have spare channels you release the currently played note and the new note will play on a different channel, e.g. CH11. Essentially they will overlap each other creating a false sense of reverberation depending on the release time. I disabled volume ramping for both, however using note cuts, which is SNES like, produces popping like we expect. Unless you have a funky envelope, note-offs will fadeout based on their release properties. While note-offs can be emulated in MML it'd **cut your channels in half during worst case scenarios... Testifying as to why most SPC engines use ramping.


*The piano is a VST and is exempt from everything, automatically note-offs.

**Technically you can eat up all your channels but if we're being real it's unlikely you'd want to do that, especially for polyphony constrained songs.