vgmrips

The forum about vgm files
It is currently 2017-09-23, 4:12:02

All times are UTC + 1 hour [ DST ]




Post new topic Reply to topic  [ 18 posts ]  Go to page Previous  1, 2
Author Message
 Post subject:
PostPosted: 2014-11-19, 17:38:35 

Musicians Musicians
Contributors Contributors
Offline

Joined: 2012-09-29, 11:45:48
Posts: 205
Location: Australia
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


Top
 Profile  
 
 Post subject:
PostPosted: 2014-11-20, 8:18:55 

Staff Staff
Programmers Programmers
Offline
User avatar

Joined: 2012-04-22, 4:03:45
Posts: 203
Location: New York, NY, USA
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:
bool SubYM2612::saveVGI(const ins_t &ins, const string &fn);


...becomes...

Code:
// 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);


Top
 Profile  
 
 Post subject:
PostPosted: 2014-11-21, 7:06:11 

Musicians Musicians
Contributors Contributors
Offline

Joined: 2012-09-29, 11:45:48
Posts: 205
Location: Australia
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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 18 posts ]  Go to page Previous  1, 2

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group