Check out the OPNA chip

[Wohlstand]

https://www.vogons.org/viewtopic.php?p=704730#p704730

SLON: What about the possibility of using the YM2608 core? It was distinguished by the presence of additional SSG and ADPCM (and RHY-channels), and also, as far as I know, a higher-quality DAC. True, I do not know how useful this will be for MIDI.

Wohlstand: It's dependent on the availability of necessary emulator and the chip specification I can use to provide an interface. For now, libOPNMIDI doesn't use DAC, but its support is WIP. On side of libOPNMIDI are three emulators: Nuked OPN2 is implemented YM3438 chip, but it's very powerful and won't work on slow hardware in real-time if you running more than 3 chips; MAME OPN2 is implemented YM2612, doesn't using much power, but is a most balanced emulator that gives well-accurate and doesn't eat too much CPU; And the GENS 2.10, the old and inaccurate emulator, but, the fastest emulator I have at me.

If the OPNA chip has compatible ABI, we can try to use it as an alternative chip together with existing OPN2 chips. For the case of DAC-equipped chips, they are all will have the sample-streamer on the side of ChipSet base backend, and necessary to do that from outside. The only exception would be for OPNA that does support of ADPCM.

• [x] Provide at least one OPNA emulator at libOPNMIDI
• [x] Provide at least one OPNA emulator at OPN2BankEditor
• [x] Provide a support for file formats are related to OPNA bank / instrument formats
• [x] Add PMDWinS036 OPNA emulator to verify FM block behaviour (https://github.com/pbarfuss/PMDWinS036)
• [x] Add MAME OPNA emulator code
• [ ] Add support for OPNA-specific bank / instrument file formats are also can be used here
• [ ] Make WOPNv3 know about OPNA Rhythm instruments (NP2 supports custom samples passed, I wanna check this at evening)
• [ ] Research SSG-EG capabilities
• [ ] Research and implement PSG support
• [x] Research and implement OPNA Rhythm
• [ ] https://github.com/Wohlstand/libOPNMIDI/issues/5

[freq-mod]

Regarding YM2608, one thing to remember: there were two versions/revisions of it.

• initial phase of YM2608 that had one 4-bit monoaural hardware ADPCM channel capped at 16 KhZ
• YM2608B (OPNA rev.B) that didn't have it, PCM was meant to be provided by external chip, in similar fashion to Sound Blaster 16

There were rhythm channels derived from YM3301 drum machine. 6 samples, somewhat terrible quality, stored in built-in ROM. YM2608 relied on external DAC, so there were no distortions. Also, sampling freq. was higher at 55466 Hz (hi-hats sound much more convincing on 2608 IMO 😉 ) As for emulators, there is PMDWin core, MAME YM2608, Neko-project FMGEN core... all of them should be accurate enough.

[jpcima]

There is now a WIP for OPNA on my work branch. This adds "Neko Project II Kai OPNA". https://github.com/jpcima/libOPNMIDI/tree/neko-opna

It plays with some glitches. This is what I know so far.

• I adapted the chip to the native clock and rate, which are different than OPN2. I took the native rate as @papiezak mentioned and the clock 7.9872 MHz which is the same as Neko emulator and maintains a factor 144. The pitches sound off, I guess it's computations of block and f-num which also need adapting.

• The emulator output is a mix of generators: FM, PSG, ADPCM and RHYTHM. OPNB can be enabled in place of OPNA, this one segfaults on use; it needs to be checked why. (template parameter selects one of 2 chip types)

• Some channels seem to skip or play wrong things, probably by the design differences of both chips. You can hear some of channels which will sometimes generate as PSG square output. For some reason, it is heard more frequently at 1 chip than the higher chip counts.

Other than this, I cleaned up warnings, I've marked code by // libOPNMIDI comments where are made more significant changes. At first look this seemed like a light emulator on the CPU, and also nice when it comes to license (MIT).

[Wohlstand]

I have tried to play random music on a quick hand, and I can say next:

• Sounding is good, that good, no shit-voicing sound, OPN2's voices are sounding on accessible channels fine! :fox_face: :+1:
• Tone isn't tuned fine (a bit higher than on OPN2), looks like need to polish the coefficient to align the note tone with OPNA :thinking: Possibly, move the tone coeffient into the chipset (which is used in the frequency compution from various pitch values).
• I need the programmer spec for OPNA chip to compare with OPN2 as I guessed, their ABI is different, therefore many channels are missmatching and not working (the synthesizer is designed for 6-channels of the chip). Possibly, I'll need to align the chip communication logic to allow it use OPNA chip correctly...

[Wohlstand]

P.S. Please also convert all Shift_JIS files into UTF8 to avoid future crap and let read Japaneese comments in a quite :fox_face: (UTF8 with no conversion)

(Shift_JIS with no conversion, need to save as UTF8 later)

[Wohlstand]

As a minor workaround, I have forced MIDI synthesizer to skip 3 last channels while range scan for goodness check, so, 3 first channels are in use: And music playing fine with no missing channels! So, I ague, it's the OPN2 and OPNA difference of post-3 channels alignment or way to call of them.

EDIT: This is safer, otherwise, the check is skipped, and previous will lead a crash...

[Wohlstand]

I have found something related, will research the stuff after sleep: https://wiki.neogeodev.org/index.php?title=YM2610

YM2608J Translated.PDF

[jpcima]

I converted the shift-jis encoding. Also I agree that some chip-related information be abstracted through chip-base's interface, taking precaution of avoiding virtual calls at the audio rate.

I'm interested to see your handling of channels which improves playback situation, and also I forgot how is computed the frequency coefficient formula. I will look again after some rest.

[jpcima]

I scaled the pitch coefficient, and this fixed the frequency. Next is to manage the channels correctly.

[jpcima]

Found ! It needs to set bit SCH "six channels" of register 0x29. Then it has all the FM channels working.

[Wohlstand]

Oh, neat! :fox_face: :+1:

[Wohlstand]

So, there is only some questions about ABI difference: which features are different between OPN2 and OPNA related to FM synth

[Wohlstand]

One thing I forgot, OPNA has some sort of PSG in place as I know...

[Wohlstand]

And, which sense of SSG-channels?

[freq-mod]

One thing I forgot, OPNA has some sort of PSG in place as I know...

It does. It's built-in YM2419 core, the same that was in ZX spectrum, Amstrad CPC, Atari ST... It has 3 channels - each of them can produce either 50% square wave, noise or combined square wave & noise (at the same time, occupying one channel!) It also has ADSR envelope generator, like FM synth or SID chip - common for every channel

[Wohlstand]

It also has ADSR envelope generator, like FM synth or SID chip

Looks like an easy solution of this: https://github.com/Wohlstand/libOPNMIDI/issues/6

[freq-mod]

SN76489 doesn't have ADSR, just a simple 4-bit volume control. YM2419 SSG chip sounds slightly different as it's noise generator is much more sophisticated than SN crap.

2419 also has 4-bit volume control but it's just an addition to envelope generator.

[Wohlstand]

Neat! Also, it's would be cool then add it into OPN-BE to benchmark it, I'm curious how much it loads the CPU, and, how accurate it emulates the sound in comparison to others include MAME.

[Wohlstand]

Anyway, I have checked out the CPU load by opnmidiplay, and loos NP2's OPNA is a bit faster than MAME :fox_face:

[jpcima]

Yeah but it's a bit like Gens also. It's not faster in full use, but it's good at saving CPU usage from the inactive parts. MAME is a stabler CPU usage.

[Wohlstand]

I also hearing that percussions are sounding differently than on OPN2 chips, due different clock and oscilators. But also means, need to tune a bit the frequency coefficient...

[freq-mod]

Yeah, that is because sampling frequency is different, 55466 rather than 53267 hertz. That's the reason percussion used to sound different on Gens core compared to Nuked.

[freq-mod]

Hmmm... i checked out OPNA emulation, SSG-EG based instruments sound completely off Did YM2608 not have SSG-EG and this is normal?

[jpcima]

Yeah it has the SSG and I reproduce the problem. Gotta debug into this.

[freq-mod]

I'm not certain but there can be a problem with detune values... I tried porting hi-hat from some PC-9801 game and it sounded off until i (blindly) played around with detune parameters... weird.

[jpcima]

I took a plot of SSG-EG based off the patch SFX Laughing from @Wohlstand's bank, it's based on /\/\ shape. Let's try extracting same infos off Nuked or MAME...

[jpcima]

This was MAME SSG-EG.

[freq-mod]

For temporary, I have made a separated bend coefficient for percussions, as because of chip clock difference (between OPN2 and OPNA), percussions are too sensitive and needs a different pitch to sound correctly.

https://github.com/Wohlstand/libOPNMIDI/commit/7076de broke the percussion such as hi-hats, they sound completely wrong now, at least compared to Hoot player, meanwhile they had the same timbre before hihat before (note only the timbre, accidentally record two of them my bad): https://instaud.io/2W91 hihat after: https://instaud.io/2W92

[Wohlstand]

That I did, is really mess, as it was my ugly attempt to polish OPN2-ish drums over OPNA, but this breaks native OPNA instruments, so, yeah. The true solution is adding of per-chip per-instrument fine (like not offset, but as micro offset unit) tune into WOPNv3, and this I'll nuke down.

[jpcima]

but this breaks native OPNA instruments

Exactly, why not let chip sound native like it should be ? Let chip use own instruments for it, or you can clock down chip's sampling rate for identical effect. You're free to invent a tool which patches OPNx instruments of one chip for another.

The true solution is adding of per-chip per-instrument fine (like not offset, but as micro offset unit) tune

NO it's not the tune, it's operating sample rate. To detune is not a mathematically correct solution. You can set operating rate of this emulator at anything you want. Did you try using OPN2's ratings?

[Wohlstand]

NO it's not the tune, it's operating sample rate.

I mean, keep the chip native rate, but polish the instrument to fit into multiple different chips with keeping native rates of all of them.

You can set operating rate of this emulator at anything you want. Did you try using OPN2's ratings?

That yeah, but I didn't tried that, but, let's try... I'm interesting which result will happen...

[jpcima]

opn_chip_family.h change:

template <>
struct OPNFamilyTraits<OPNChip_OPNA>
{
    enum {
        // nativeRate = 55466,
        // nativeClockRate = 7987200,
        nativeRate = 53267,
        nativeClockRate = 7670454,
    };
};

[Wohlstand]

Done just now, and yeah, the sound of percussions is now same as on OPN2 chips, that yeah, however, percussions made for OPNA directly, will be broken as I said, and there are needs to be polished...

[jpcima]

What do you think to be a solution? it's not satisfactory to use a solution based on detuning. As I understand, this gets you 1. broken OPNA and 2. not-very-good compatibility of OPN2, like a worst of both worlds compromise. In this situation, you can't play in fidelity instrument from both of chips.

I'm just saying to let chip act like they want. At least then it can be a good OPNA. OPN2 instruments run the best on OPN2, and OPNA same. If you'd like compatibility, drop sample rate.

[Wohlstand]

Anyway, what about the bank-wide flag "force OPN2 clock on OPNA"? (it can be added into WOPN2 without of damage) So, the bank intended to work on OPNA will work fine, but OPN2-bank will force OPNA chip to work in OPN2's frequency.

[Wohlstand]

Also, having this flag, OPNA-intended banks would say to synthesizer to automatically choose OPNA chip than OPN2 that is in use by default.

[jpcima]

This, I think it would be ideal.

However it's a possible problem in case of mixing OPN2 and OPNA instruments, so I want to let know what is the enabled mode of operation in my programs. In chip setup, I would like to access the mode in read and write, so I can show it and control from a menu.

[jpcima]

Note: you can also do the reverse, clock OPN2 as OPNA, for an emulator which has this support

[Wohlstand]

Note: you can also do the reverse, clock OPN2 as OPNA, for an emulator which has this support

Yeah ;3 This will be not possible with Nuked OPN2 as it's the simulator of real chip, and that will be same with potential Nuked OPNA when @nukeykt will introduce it (if is a plan for it?), so, the porting of instruments between OPN2 and OPNA will need the tuning to "align" the instrument into necessary chip.

[jpcima]

This will be not possible with Nuked OPN2 as it's the simulator of real chip

Why not? it has the controls of rate and clock.

[Wohlstand]

Why not? it has the controls of rate and clock.

Trying to change clock you'll also change the rate of LFO (example of result of my early mistake: http://wohlsoft.ru/docs/_files_for_posts/Misc/NukedOPN2/Suzanna-Nuked.flac) You'll hear that LFO's frequency is too fast here

[Wohlstand]

@papiezak , okay, the frequency crap has been resolved with adding chip category which will say in which frequency all emulators are must work to match OPN2 or OPNA in dependency which instruments you want to create. At OPN2-BE I have added the chip type flag: you can use to tell for which chip you creating the bank, and by this flag, bank will set necessary frequency of the chip emulator (even OPN2 chips will work in OPNA's frequency when you wanna use OPNA-ish drums without distortion). And @jpcima has implemented this on libOPNMIDI side: https://github.com/Wohlstand/libOPNMIDI/pull/74 Anyway, the thing is left on OPN2-BE to port the updated chipset to introduce OPNA emulator at the here.

[jpcima]

Anyway, the thing is left on OPN2-BE to port the updated chipset to introduce OPNA emulator at the here.

I let you have this task if you want, as currently I'm doing the implementation work in the plugin and testing.

[Wohlstand]

I let you have this task if you want, as currently I'm doing the implementation work in the plugin and testing.

Anyway, the question: will you change chipset API again in nearest time? If no, I gonna to backport it into OPN2BE now

[jpcima]

Current libOPNMIDI has been sufficient for my needs, so it would be fine.

[Wohlstand]

Okay, I'll work on this now. :wink:

[Wohlstand]

Just now I have made OPNA support on Bank Editor side! :fox_face: :wink:

[freq-mod]

Hmmm, testing native OPNA instruments I can hear there is a difference in timbre between instruments played in bank editor and OPNMIDIplay... hihat banked.zip - there is a zip file with comparision between these two and instrument file in question

EDIT: bank editor's output matches Hoot player, which is what should it be

[jpcima]

Having latest libOPNMIDI and wopn bank saved with OPNA flag, I had identical timbres between bank editor and VST. opnmidiplay is to retry but I gave it some light testing with different banks as I implemented in libOPNMIDI, and it showed to work correctly during these tests.

[freq-mod]

Damn, flase flag. Looks like weird timbre is only the case of some .mids, like MIDI_sample.mid from http://wohlsoft.ru/docs/Music/MIDI/ I didn't test it thoroughly enough my bad 🤦‍♂️

Still, SSG-EG should be looked at

[Wohlstand]

I have found what's the sense of channels of OPNA: https://www.youtube.com/watch?v=bFphJBs6PSk

• FM channels, we know

• SSG-channels, it's an embedded PSG channels, square waves. Yeah, the OPNA chip is an full-featured combination of YM2612+Powered-SN-ish:

  The tone of the analog signal (SSG sound) is output from the output terminal of OPNA(pin
  27; ANALOG OUT). The register of SSG is different from the FM sound source part, and
  read/write is possible. It explains each register as follows as the function of the SSG
  sound source part.
  3-1: Tone generator control
  A rectangular wave of 1:1 compared with the duty can be pronounced by three sounds in the
  SSG sound source part simultaneously. The tone generator control sets the pronunciation
  frequency of channel A, B, and C by the data of 12bit in total of rough adjustment 4bit
  and fine-tuning 8bit. The expression from which the pronunciation frequency is requested
  is as follows.

• Rhythm-channels, are simple channels are using ADPCM chunks to play:

The rhythm sound source part is a digital rhythm tone that uses ADPCM voice synthesis.
ADPCM rhythm tone can pronounce tones of the rhythm musical instruments that the sound
making is difficult with easy software in the FM sound source. Moreover, the rhythm tone
can comparatively sample easily because of the attenuation sound by a little memory, and
secure the envelope from the generation of the sound to the disappearance naturally.
The tone is composed of six kinds of drums of a basic tone, and can be pronounced by six
sounds simultaneously. Because each tone can individually set the level, the accent
processing to say nothing of the balance adjustments of each musical instrument can be
freely done.
The control register of the rhythm sound source part is composed of $10-$1D. Moreover,
when bus control signal A1 is“0”, the data access to this register is possible.
(Refer to seven pages to the bus control)

• And ADPCM:

  ADPCM sound source part is a speech analysis and is synthesized by using the data
  compression technology by ADPCM method. The ADPCM(Adaptive Differrential PCM) method is
  able not to ruin tone quality so much by encoding the difference between the voice data
  and the forecast data according to the width of the quantization (width of the adjustment
  quantization) that flexibly changes into the displacement of the shape of waves and to
  attempt the reduction in volume of information (bit rate) necessary for the reproduction.
  It is possible to pronounce simultaneously with the FM, SSG, and rhythm sound source parts
  by sampling the genuine sound quality of a human voice and the natural world by building
  ADPCM sound source into.

And the full doc is here: https://github.com/Wohlstand/OPN2BankEditor/files/2588007/YM2608J.Translated.PDF