Skip to content

VGM2PRE open beta

Beta test!

Technical discussion about the VGM format, and all the software you need to handle VGM files.

Moderator: Staff

  • User avatar
  • MaliceX Offline
  • Posts: 226
  • Joined: 2012-09-29, 11:45:48
  • Location: Australia
  • Contact:

Post by MaliceX »

neologix: Just letting you know I've made a start to a branch of the current codebase. Think I've gotten most of the skeleton code up there, just need to establish a number of things and then I can make a start with getting the .write() functions working.

Semi-related, I've also rigged Processor to allow YM2203, YM2608 and YM2610 commands for conversion via the existing YM2612.write() function, and seems to work trivially. :) (well...their operator register structure is practically identical!)
-dj.tuBIG/MaliceX
  • User avatar
  • neologix Offline
  • Posts: 211
  • Joined: 2012-04-22, 4:03:45
  • Location: New York, NY, USA

Post by neologix »

MaliceX wrote:Semi-related, I've also rigged Processor to allow YM2203, YM2608 and YM2610 commands for conversion via the existing YM2612.write() function, and seems to work trivially. :) (well...their operator register structure is practically identical!)
In the long run, I'm fine with renaming *YM2612* as *OPN* (possibly even filenames) and generalizing some related stuff (e.g. enhancing the ym2612_op_t to be a full opn_op_t and instead letting the newly relatedly renamed SubOPN::save* methods determine which op params are actually handled, possibly with extra parameter(s) saying what type to parse the op as). Same goes for other family chips like the OPL* series if/when output formats become available for them.

Because I feel I've even confused myself with the above wording, below is a before and after of what I mean:

Code: Select all

bool SubYM2612::saveVGI(const ins_t &ins, const string &fn);
...becomes...

Code: Select all

// N::OpMode is a not-yet-implemented enum : unsigned unless otherwise noted
// Most SubOPN methods would default to OPN2 since YM2612 is my preferred,
// but I can be convinced otherwise if needed
// Look in vgm2pre/common.hpp for namespace N

bool SubOPN::saveVGI(const ins_t &ins, const string &fn, const N::OpMode &mode = N::OpMode::OPN2);
  • User avatar
  • MaliceX Offline
  • Posts: 226
  • Joined: 2012-09-29, 11:45:48
  • Location: Australia
  • Contact:

Post by MaliceX »

On closer inspection, the OPL series is a little tricky compared to the OPN family, particularly with the presence of both switchable rhythm and switchable 4-op modes (for OPL3) during playback which also means the operator data extracted wouldn't always be fully correspondent to assigned channel's operator pair. Additionally, I think only Freq Monster 801, FM-Kingtracker and Lee Ho Bum's Note, are the only few programs that officially support some kind of a file format for utilising 4-op presets. OPLL would be pointless except in the case of extracting the few custom presets that may be present in the song.

I'm probably going to need to incorporate some kind of alternative preset pooling when tracing each command to correspond with a particular preset (ie: separate 2op with 4op presets, and a similar mechanism for rhythm patches).

Anyway, I'll see if I can generalise the existing OPN naming schemes for the time being.
-dj.tuBIG/MaliceX
Post Reply