To take a load off
(punz, onanism, set one at ease) 
the devs, to making sure no one has to 'put up'(punz, to make, to bear) a faulty sound design , and in case I forget about things.Basically…it's a note book.
I'll write/edit whenever I'm free.
I would recommend you to try and repeat the findings I describe.
You're welcomed to post your suggestions, your unique way of overcoming a problem, or just point and laugh
.The note will most likely be furnace tracker based, I will include Dreamtracker as well.
A. Do not use Virtual Tempo!
Resulting ZSM export would alias, losing details.
Keep it default (150/150)
Here's a simple example of why,
__Base Tempo = 150 / 60 Hz, Speed 6, Virtual Tempo 150/150. ZSM export at 60 Hz__
The song gets exported tick per tick into the ZSM, no data loss
__Base Tempo = 150 / 60 Hz, Speed 6, Virtual Tempo 200/150. ZSM export at 60 Hz__
Tick 0 Furnace -> Tick 0 ZSM
Tick 1 Furnace -> Tick 1 ZSM
Tick 2 Furnace -> Tick 2 ZSM
Tick 3 Furnace -> Tick 2 ZSM
Tick 4 Furnace -> Tick 3 ZSM
Tick 5 Furnace -> Tick 4 ZSM
Tick 6 Furnace -> Tick 5 ZSM
Tick 7 Furnace -> Tick 5 ZSM
The song plays at the right speed, but events are bunched up so that some ticks have 0 delay, essentially. Very fast rhythms will sounds stuttery.
Instead we should set
__Base Tempo = 200 / **80** Hz, Speed 6, Virtual Tempo 150/150 (or anything = 1). ZSM export at **80** Hz__
Then everything lines up
B. Do not use a tempo(engine speed) setting above 255Hz (637)!
ZSM format don't support it.
Note square, on the current popular player Mellodius, anything above 60Hz will get scale down to 60Hz to free some cycles accommodating PCM data feeding.
Even if your ZSM is exported at higher than 60Hz and ZSM supports higher than 60Hz technically, if the playback routing scales it it won't playback the way it's intended on real hardware.
Note^3, As April,2024, Meoldius is updated supporting VIA timmer.
It'll now work with the full range of tempo.
C. Warning, Max ZSM size currently is 2014KiB, do not exceed. You could edge it to 2020KiB with consequences.
D. Warning, there's a chance of buffer underun if switching sample rates/bit too frequently.
As such, try to keep all samples at a consistent bit depth and sample rate.
A personal preference is 27771hz for drums/percussives, 30600hz for vocals/synth, 22050hz if you're running out of space. 8000hz if you're desperate.
Any sample rate above 30khz is inefficient.
27771Hz is the Frequency I measured across multiple drums samples and where the actual spectrum begans, which is around 15KHz, and multiply it by 2x0.8 as MPEG Layer-3 does, there's the 27771Hz.
It's also good for keying the sample since 27khz is on the middle of 48kHz. Now you can have one and a half octaves of notes to play the sample at.
Bit depth depends on how much you hate the quantification noise versus how much space you have.
There's no need to chase the HIFI sample dragons, you could stream PCM from disk at a much better quality than do it in ZSM robbing valuable space from the PSG/FM. ZCM standard for example is a better choice for sample playback.
Note, even set at 277771hz, the zsm exxporter will not resample it. The sample will then playback at 27847Hz.
Note, MP3 is much more complicated than x0.8 sample rate, but yeah it do remove harmonics you don't need to hear.
Note, you can get good enough HH SD BD on 8khz so long as you know what needs to be done. I personally find it not worth it since you have much disk/RAM to use. On occasions where you're producing a keygen/cracktro 8khz might be desirable.
Note, you should check out the VERA PCM freq divisions for rounded sample rate that it would play back, 27847hz for example. And play with keying the sample for the best note range vs quality.
E. Warning, there's is a chance for the VERA PSG waves to randomly run out of phase of each other, will result in odd silence if two waves out of phase by π.
As now, this is marked will not fix bug.
To mitigate, detune channels.
But do play with different detune settings, as detuning can drastically affect the pitch slide range you can go before it sounds really bad, and different intermodulations between channels might be desirable as well.
FM don't have this problem as when the FM channel triggered, the channel phase rests.
Yamaha FM technically is Phase Modulation to mimic FM, hence the phase is "locked", but you can always refer it as FM.
And all Phase and Frequency Modulation is Angle modulation....
Phase changes phi... Frequency changes omega...
yes it's analogue modulation(usually... on OPL3 it might be FSK(square wave as mod.)....), passband modulation(change TL of a modulator then you will see flitter-like-results passband)....
but you're not transmitting it with EMF..... so no worries there...
F. Warninng, VSYNC is not 60Hz!
VSYNC is not 60Hz! if you play back the song on real hardware, expect it to be slower if playback is sync with VSYNC.
VGA =59.52Hz
NTSC480i=59.8596Hz
NTSC240p=59.859593Hz
RGBS = NTSC
Say if made with 60hz in mind, one second difference per 2 minutes.
G. Warning, as now the R44 emulator introduced a mixing bug, resulting a imperfect FM emulation.
Basically, the R44 emulator added a new mixing sub routine, and FM got scale down to 48828Hz same sample rate of VERA.
The sample rate of YM2151 is 55556Hz(4MHz/72).
And the resampling interpolation is performance oriented.
This changes everything that contains high frequency contains like HH, SD, or most of FM instruments when played higher then A-5, as ze spectrum will deflect from 48828/2Hz.
This bug is not effected on real hardware or Furnace tracker, even the Furnace does default to resample to 44.1KHz on default, but with its proprietary interpolater, it's way better.
As now, R45 emulator still carrying the same bug.
A(H). Make sure your zsm export rate is the same as the engine speed to avoid aliasing.
If you're running low on space, you could use a lower export rate to save space at a cost.
I. You can manually patch in a stereo sample.
Worth it! but it's quite a hassle, I'll fill in the how-to if you interested.
2. On furnace, the volume setting is logarithmic, differs from other trackers.
On hardware level, it's all log scale, the YM2151 VERA, all uses log scale.
Log scale have great advantages when it comes to programming it, you only need to do Add and subtract eliminating the need of division which need to broke to tons of subtraction.
On sound design side, a logarithmic fade in/out is much more desirable than a linear one.
That said, you could still change values exponentially to cancel out it make it liner silde if that's you want and volume slide effects don't work for you.
3. Warning, there is no auto trim function for samples, if you put a sample in it and don't tirm it, it will leak to ZSM export causing space waste.
As now, furnace team haven't responded F off to me, so there's a chance.
4. Try not to use LFO/ADSR in the instrument window, it's costy on ZSM size, same applies to the effects.
Nothing is free. not even air and water.
Forget about this tip and do exactly the opposite if you want to go ham on the-best-possible.
There's a rumor of stream from disk ZSM that could potentially lift the limit.
5. You can play C-10 on VERA noise channel for hihats, use arpeggio setting of +24 then play a C-8 note to get done.
6. Warning, the settings on furnace tracker is latched, as such if you switch a instrument and the instrument switch to don't have say Wave bit set, Furnace will not update it thus it'd be the same as the last used by the last inst.
7. Zsm export don't contain any furnace tracker comments, it's just a register dump of instructions to chips.
So it ok to leave comments in song info, no one will find out
8. You can load a big chungus sample into the furnace, and then chop it in furnace to a different sample bank, as long as the big chungus get to played first, ZSM export will not store it twice.
Very very useful feature.
As such it eliminates the needs for 9XXX command, thus 9XXX command will not work on VERA.
The 9XXX job is automatically done by the exporter.
9. don't make music that you don't like.
X. make lots mistakes, but when you do, fix them however it takes.
X. there's a hardware LFO on OPM/N family chips, you can configure it with effects.
it's less versatile than software emulated LFO, but it's hardware, it will save space and CPU.
Use it when possible.
x. The zsm exporter will 'ignore' some effects at the end of a loop, especially if it has anything to do with timing.(engine speed), channel muting.
there's no real fix to this, as it's hard to patching in self modifing ZSM with current standard ZSM.
option you have,
1. make 2nd loop into a different ZSM
2. make 2nd loop a duplicate of the first played rather than points to a pattern, then make the duplicate loop by it self.
All very costy.
x. Warning, there's a bug with the Furnace FM PSG PCM mixing level, that the emulation is off from the real hardware.
Even some versions of the emulator is effected as well.
Basically, the FM is louder PSG is quieter on Real hardware.
It's a oopsiy daisy of one of the dev.
To be fair, I understand how finicky the audio level measure can be, there's frequency response, peak levels, DC bais, fun Nyquist stuffs.
It's unclear if this bug is addressed or not, but most likely it will stay the way it is for quite a long time.
Add: now 5 mouths passed, this bug still persists.
A quick fixw would be to lower OPM's mixing level to 0.9 in furnace.
(See appendix.2)
To avoid back'n'forth checking levels, please use DREAMTRACKER and compose preferably on real hardware.
On realhardware with Dreamtracker, you don't need to worry about sample rate and aliasing.
x. Warning, the first two bytes you write to VERA's FIFO will be discarded,
it's just a feature. Marked will not fix.
As such, I'd highly recommend you to zero fill those two bytes, in case there's a compressed ZSM standard comming out, you can squeeze more bytes this way
x. Warning, due to limitations with reading speed of SD card, if the stream ZSM feature did comes out, there's still a limit for how big your sample can be as all sample data needs to stay resident in RAM.
It's unclear what're the exact numbers, but the PCM sample size should be around 2Megabytes or less to fit in RAM.
There's no support for CRAM yet, the ZSM standard.
x. Warning, there's a potential compatibility breaking fix to the VERA PSG volume behavior which has it's advantages.
I can't give advice as now for it's still a hot potato, and need some time to argue about.
(x16Community/vera-module/issue/20, Github)
Edit, as April,2024, this proposal has been merged, it's less compatibility breaking and saves space when devs found a better way. see above link for details.
x. Warning, FM sampling rate is important if your tune have a lot of high frequency content.
Try to always set the furnace tracker to playback/export at higher than 62500Hz say 88.2KHz, and if you're making video with it try keep it at 88.2KHz as well.
It's mostly a peace of mind, most people can't tell the difference with a good interpolation.
There are instruments that requires the full spectrum, as it's easy to create very high frequencies with aliasing on FM, I have encountered at least 4 such instruments.
The worst is on OPL2, there is a cool Hihat/sfx you can do with adlib card, but when listent to on SoundBlaster which will scale it to either 22.05Khz or 44.1Khz, it sounds bad.
The same pattern follows to OPM/N family chips. It was a tune I cobbled together identified the R44 FM mix bug.
The Aliasing becomes the character of the instrument almost all the time, the difference is whether it's noticeable or not.
Where as NED Synclavier, it's got 256 samples per clock, YMFM all have a sine wave resolution of 1024 samples per clock, so it's effectively 400KHz sampling rate according to the patents, FM now never really bandlimted, thus you don't get aliasing with it "perfect" FM synth, but it sounds "wrong" comparing to say DX7.
As such, keep that hi frequency sideband and you be All good.
x. Be aware that OPM can't do some very low notes without aliasing. G-0 for example.
OPM sample(waveform rom) size is small for notes this long of a wave length.
If you modulate it, there'd also foldbacks from below 0hz.
x. To fight the lower part inaccuracy that chips are putting out and the possible junk speakers/headset user might be using, please consider using the missing fundamental effect as bass or bass/lead.
x. FM generated SAW-like wave is inverted compared to VERA.
x. FM could generate some very loud harmonies above 15KHz and put unwanted stress on mixing, the listener and smearing your mix when playing with FEEDBACK.
(See apedx 1)
Be sure always pull up a scope.
x. on furnace, the loudness/dynamic range is caped a bit lower than you can go on real hardware.
i.e. it'll clip when it shouldn't.
You can play a bit with export and see how it works on emu/hware.
Or use DT.
x. you can write out all 64 PSG reg in less time than you can send three commands to 2151.
The cost of running 2151 with 8mhz bus. Good job most of the work is done with OPM hardware it self so you just sending KON KOFF once all EG PG is set up so it's not too shabby at all.
Musical wise no need to get alarmed, it's mainly the ZSM size you need to worry about than loop time.
x. PSG can aliasing like FM as well, 488888/2 is where the mirroring happen, notes higher than C-7 has potential of fold back, play with fine tuning and macros to get TR909-alike HH Cym.
x. Leave ins.select as is, there's no need to delete the extras(most times), zsm export will look only at register changes and if no change, it will not register.
There are some extreme cases where you would like to keep it as is, and sometimes to play a low octave low volume note to force instrument register update.
Play with it to see the zsm size change.
x.You should not worry about the phase resting noise on YM2151, as the lowpass filter on real hardware would take care of that.
Same with the foldbacks from 65khz/2....at some degrees of TL.
And not just phase rest pops, this would enable you to do more register changes on the fly without introducing too many pops.
You should experiment with it.
That is, you intention is to play on real hardware. If not, you might want to apply this filter yourself as NukeOPM's emulation is very accurate.
It's unclear if VERA shares this signal path.
