Check out the OPNA chip about opn2bankeditor

[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! 🦊 👍
• 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 🤔 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 🦊
(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! 🦊 👍

[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: Wohlstand/libOPNMIDI#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 🦊

[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.

Wohlstand/libOPNMIDI@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:
Wohlstand/libOPNMIDI#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. 😉

[Wohlstand]

Just now I have made OPNA support on Bank Editor side! 🦊 😉

[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

[nukeykt]

YM2612 is basically YM2608's FM block with a cheap YM2413's DAC and very hacky PCM mode, presumably created for Sega MegaDrive. So i think it's pretty easy to use any YM2612 core as YM2608's FM block. Also it's safe to set OPN2 clock rate to 7.9 MHz(for reference nominal rate for YM2612/YM3438 is actually 8MHz, Yamaha/Sega used 7,67MHz for Mega Drive as it was close enough).

[freq-mod]

So this documentation of YM2612 SSG-EG can be used to describe and debug YM2608 SSG-EG?
http://gendev.spritesmind.net/forum/viewtopic.php?p=5716#5716

[Wohlstand]

So, the question that is still be here: is it's fault of NP2's OPNA emulator reguard to SSG-EG implementation, or is real OPNA has the same? But okay, I guess it's the fault of NP2 emulator, and we would to try to fix it.

[nukeykt]

I really doubt that Yamaha would spend time(money) to somehow alter SSG-EG behavior(especially for cheaply developed YM2612). SSG-EG is technically part of FM block and not related to real SSG implementation in YM2608.

[freq-mod]

it's fault of NP2's OPNA emulator reguard to SSG-EG implementation, or is real OPNA has the same?

Nice way to check it would be by adding this emulator in the future - (https://github.com/pbarfuss/PMDWinS036); it appears to be newer but more resource hungry

SSG-EG is technically part of FM block and not related to real SSG implementation in YM2608.

I once heard that YM2612's SSG-EG is just a leftover from YM2608 SSG block, thanks for clarifying

[Wohlstand]

Also, looks like we can add the another OPN2 chip which will use same NP2 emulator, but, as separated slot:
https://github.com/Wohlstand/OPN2BankEditor/blob/master/src/opl/chips/np2/fmgen_opna.h#L474

At the same time, MAME also supports OPNA:
https://github.com/mamedev/mame/tree/master/src/devices/sound
However, that was made as a mess of parts, however, it's easy to split up and get the united OPNA stuff.

[jpcima]

@Wohlstand OPN2 is present in header but not implemented. OPNB crashed, so I don't know if works.
However, it has the other chip family OPM, whose files I removed from this fmgen as they didn't serve. All are built on the shared FM core.

[Wohlstand]

@Papiezak , looks like this PMDWins036 has pre-filled Rhythm-ROM that can be also used for Wohlstand/libOPNMIDI#5 as simplest OPNA-native alternative to custom samples for our MiniWT synth (those are not fit into OPNA, will be played through ADPCM stream or as Pseudo-DAC will be mixed with output out of chip) that we'll use to stream drums and some simple melodic instruments through YM2612's DAC (However, for case of OPNA it's need to correctly ADPCM-compress the stream). The NP2 gives functions to load custom PCM chunks as Rhythm instruments (They are can be found with set of BIOS files of NP2Kai zip for Windows I have found at some place).

[Wohlstand]

P.S. OPNA's SSG also can be used in instruments in three modes: as solo, as dual (like pseudo-4op at ADLMIDI), or in parallel with FM voice. For OPN2 chips the PSG can be placed, for example, equivalent Yamaha's PSG to OPNA's part with envelope support rather to use a shitty SN chip.

[freq-mod]

The NP2 gives functions to load custom PCM chunks as Rhythm instruments (They are can be found with set of BIOS files of NP2Kai zip for Windows I have found at some place).

Shouldn't it be impossible and emulation-wise, fundamentally wrong?
YM2608 Rhythm Sound Source is just a six samples (2608_samples.zip) that are hardcoded into it's built in ROM. You can't alter it or add any more new samples onto it. Simply impossible, like writing to the fully filled non-rewritable CD-ROM. Only control you have with them is volume control and panning. You can't even re-pitch them! It's bilion times worse than even OPL drum mode.

[Wohlstand]

Shouldn't it be impossible and emulation-wise, fundamentally wrong?

That's very possible, anyway, the thing looks like I need to allow emulator (NP2 only can from files) to load those PCM chunks from memory rather from files (to allow passing of those chunks from WOPN file directly).

[freq-mod]

To complement #1, it would be great to have ability to extract instruments from YM2608 VGMs/VGZs
Some samples: Tsunyan_Jaayao_(NEC_PC-9801).zip

[Wohlstand]

YM2608 VGMs/VGZs

I think, it's super-easy to allow OPNA-related stuff be interpreted, let's check that in spec...

VGZ

Looks like I need to begin use zlib for VGZs are not supported yet now...

[freq-mod]

I think SSG-EG is now broken on OPNA because emulator used now (NP2 Kai) seems to be as old and obsolete as Gens 2.10:
// FM Sound Generator - Core Unit // Copyright (C) cisc 1998, 2003.

I discovered there is a YM2608 tracker in early development called Bamboo Tracker. It relies on MAME OPNA emulator and SSG-EG sounds rather close to what is on OPN2 emulators like MAME or Nuked. The only real difference is that frequency is lower as heard in comparison recordings:
ssgeg comparison.zip

[Wohlstand]

Yeah, the MAME OPNA is also choice as I said, so, I'll try to implement it also.

[freq-mod]

Now that MAME is added, SSG-EG works much better. It's still different from YM2612, kinda "slower", but that may be the intended behaviour of a real YM2608.
Still, SSG-EG instruments in YM2612 banks must be corrected to sound fine in YM2608. Just raise Decay 1 rates by 2 or 3.

About square wave channels, I think you need emu2149.c and emu2149.h as well. Don't know what about rhythm samples, though.

[freq-mod]

Now that MAME SSG and rhythm portions of YM2608 are added, I looked at that UI sketch and envelope parameter options look weird...

@rerrahkr - you seem to be knowledgeable about SSG capabilities, does its envelope rely on these CONT/ATT/ALT/HOLD values like in SSG-EG or just 16-step volume level (and 8 "hard" steps)?

[rerrahkr]

In BambooTracker, 8 "hard" steps means using hardware envelope which is controlled by EG frequency, C, ATT, ALT and HLD. The other 16 steps use software envelope controlled by writing volume to its level register for each tick.

The volume resolution of hardware envelope is 32, finer than software envelope that it is 16. But hardware envelope cannot change envelope shape more flexible and volume scale (volume level operation is not reflected during hardware envelope execution).
Therefore some OPNA sound drivers like PMD control SSG envelope by software envelope and don't use hardware envelope.

[Wohlstand]

So, looks like I need to make that SW envelope for here also, like for SN which is totally lacks any envelope support. Also, @rerrahkr , can you better explain how to convert MIDI tone into SSG's tone frequency? Code I have made in my sketch branch is crap and makes completely wrong tone for now. I have the valid stuff for FM.

[freq-mod]

Thanks for the info @rerrahkr!

Looking at sketch I think there should be also an option for noise or combined noise/square wave output; that's going to be crucial for many instruments. Also, Bamboo Tracker supports arbitrary waveforms for SSG produced by hardware envelope manipulation (sawtooth, triangle), it would also be neat if possible

[rerrahkr]

SSG tone is defined as: hertz = master_clock / (64 * TP)
TP is 12-bit register value, high 4 bits are "coarse tune" set to register $01, $03, $04, and low 8 bits are "fine tune" set to $00, $02, $04.
So I think:

uint32_t tp = static_cast<uint32_t>(clock / 64.0 / hertz);
WriteReg(0, 0x00 + cc * 2, static_cast<uint8_t>(0x0ff & tp));
WriteReg(0, 0x01 + cc * 2, static_cast<uint8_t>(tp >> 8));

[jpcima]

Implemented the tuning. Thanks for the information.
Have we any existing files which describe SSG-based instruments?

[Wohlstand]

SSG tone is defined as: hertz = master_clock / (64 * TP)

Implemented the tuning. Thanks for the information.

@rerrahkr , @jpcima , thanks you both for correction of the tone formula! Just now tested the thing, and it works! 🦊 😃

I have made few tweaks on that branch, and will continue the work that needs a deep refactoring, otherwise, current code is a mess... I have some idea to make, will try this possibly tomorrow or later...

[jpcima]

These are some findings about the PMD envelope generator.

1. https://pigu-a.github.io/pmddocs/pmdmml.htm#8-1
2. http://battleofthebits.org/lyceum/HistoryView/1175/#SSG%20Commands

It describes a variation of level over time for 2 envelope kinds, where length of steps are allowed to be controlled by a clock setting defined by user.

A fitting description may be as such:

• envelope type 0: pmd-like / 1: fm-like
• clock: frequency (54.17 Hz typical, second source says 54.25 Hz)
• if type=0: AL,DD,SR,RR (refer to 1. for permissible value range)
  if type=1: AR,DR,SR,RR,SL,AL

Other:

• Tone/Noise mode https://pigu-a.github.io/pmddocs/pmdmml.htm#6-5
• Noise frequency https://pigu-a.github.io/pmddocs/pmdmml.htm#6-6

[freq-mod]

I noticed that chipset wasn't updated with a Neko Project 2 SSG-EG fix (Wohlstand/libOPNMIDI#81), would it be possible to backport these changes into editor?
I want to investigate as some of my SSG-EG based instuments sound bad on YM2608 emus including MAME...

[Wohlstand]

@Papiezak , oh, forgot, gonna to sync that change now!

[jpcima]

Please note, I took Nuked OPN2 as basis for comparison as I made this;
and I'm not sure at all what this comparison is worth, these being different chips.

This was a full rewrite of this broken part of Neko OPN, based on black-box comparison of emulator's respective curves, measured in a few different cases.

[Wohlstand]

@Papiezak , Took those changes just now

[freq-mod]

I've taken a listen.
Now, at some cases (depending on AR value being 31 or not I guess) NP2's SSG-EG sounds either similarly to MAME's ssgeg (but not identical) or exactly like Nuked YM2612 🤔

Please note, I took Nuked OPN2 as basis for comparison as I made this;
and I'm not sure at all what this comparison is worth, these being different chips.

So could it be that these changes are wrong in context of YM2608 and resulted in "hybrid OPNA-OPN2 chip"?
Maybe closer analysis of PMDWinS036 emu would tell more as it seems to be the most accurate of all 2608 emulators...

[nukeykt]

I'm pretty much sure that SSG-EG behaves same at least within YM2608, YM2610 and YM2612(and possibly YM3438)

[Wohlstand]

Anyway, when I compared SSG-EG on all emulators, in my xg.wopn, the telephone is acting slower on OPNA chips than on OPN2

[freq-mod]

It's not only just slower, take the "Car Engine SFX" instument from my GS bank.
On Nuked (and now, Neko Project) it sounds much more aggressive and louder than on MAME YM2608 where it's like muffled:
https://instaud.io/3mAr - nuked
https://instaud.io/3mAs - mame OPNA
I haven't tested PMDWin yet, but it doesn't have SSG-EG implemented anyway 🤷‍♂️

@nukeykt is most likely right, but if to examine SSG-EG capabilities completely, best way would be to compare emulation to real chip.
@rerrahkr's_Bamboo Tracker supports hardware passthrough to real YM2608 (and soundcards that use it) via SCCI. When possible, if someone would provide recordings of SSG-EG instruments behaviour on real 2608, would be extremely grateful ❤️

[freq-mod]

There is a glitch on PMDWin emulator.

1. Open the bank editor without any bank loaded.
2. Set an emulator to PMDWin.
3. Play a note.

Even when instrument is blank/null (AR=0) loud noise will be heard that will last forever. Hitting "Shut up" button helps only a bit, you can still hear the crap, it's only much more quiet.

[Wohlstand]

Even when instrument is blank/null (AR=0) loud noise will be heard that will last forever. Hitting "Shut up" button helps only a bit, you can still hear the crap, it's only much more quiet.

I had same while experimented with Rhythm, when I forgot to click the "Rhythm" and tried to play blank note...

Also, about Rhythm, PMDWin is totally not responds on volume levels and panning bits, and plays all instruments quite about silent, but hearable. Good that NP2 has good Rhythm implementation, so, I have completed my test 🦊

[jpcima]

It's the same envelope problem as always, which makes it stuck forever at the current level.
Possibly related to rate table computations, or the conditions of phase transitions.

[freq-mod]

It also likes to cut short decay and release phases too...
https://instaud.io/3nXA - open hi-hat played on Neko Project 2 emu
https://instaud.io/3nXC - the same hi-hat played on pmdwin

[freq-mod]

Hello. New version of PMDWin is released, with greatly improved SSG-EG emulation and few other fixes: pbarfuss/PMDWinS036#1

[Wohlstand]

@freq-mod , uh ty, klawo! Muszę natychmiast sprawdzić, co tam jest... 👀
[Oh, wow, I should check out, what is now at that...]
P.S. because of some my friend in Telegram, I trying to learn jazyk polski, it's not hard for me 🦊

[Wohlstand]

@jpcima , can you remind me, did you some own fixes on current PMDWin thing? In my memory, you did some fixes here to make it work independently if I'm not mistaken.

[jpcima]

Hi, I did usual things that we apply, like custom panning, but also you can check libOPNMIDI marked comments for full detail.
I don't remember the whole story of it since it was long ago.
There remained an envelope-related problem I haven't managed fixing.

There is this one which is notable.

/* libOPNMIDI: prevent FM channel clipping (TODO: also adjust PSG and rhythm) */