Wohlstand / OPN2BankEditor

A small cross-platform editor of the OPN2 FM banks of different formats (Downloads in README below)
GNU General Public License v3.0
40 stars 8 forks source link

Copy and paste with textual instrument formats #81

Closed jpcima closed 7 months ago

jpcima commented 5 years ago

If it can copy and paste instruments using text formats, OPN2-BE is able exchange to quickly with other software, without needing to involve files in the workflow.

(software: BambooTracker, Mucom88, and mine, as a feature that I will add)

We already have OPM implemented, for which BT has support, I guess it would be an adequate choice.

farvardin commented 4 years ago

which text format do you have in mind? It looks like for OPNA the MML format as used in PMD98 is a kind of standard, you can see some example in the last paragraph of this tutorial: https://www.delmunsoft.com/PMD%20Programming.html

jpcima commented 4 years ago

There exist a multitude of formats, not mutually compatible. The idea is from BambooTracker which list a number of distinct formats, and it's a choice in the configuration.

They are listed starting here: https://github.com/rerrahkr/BambooTracker/blob/c91dfbe5b4a7bb1da11f69f5c00f8019a1f957d4/BambooTracker/configuration.cpp#L65

It will extract a series of numbers from input text, and will assign according to definitions.

A problem is that when instruments contain names with embedded numbers, this extractor will be confused. So we could make a similar thing, except more strict, such that it's more compatible with current files.

Wohlstand commented 4 years ago

To make sure all software able to store all data (include unique features of each thing: OPL3-BE or BambooTracker), this needs to have the TAGGED format that is able to store any alien data are can be taken back with no losses, and let other software use possible for that data.

jpcima commented 4 years ago

I'm a little confused by what you mean, do you mean we should have our custom text format ?

For established formats, it's not recommandable that we add some things which are out of their spec.

jpcima commented 4 years ago

@farvardin also, since this work has a chance to be shared with OPL-BE, are you aware of any text formats which are used with the OPL? (I don't know any)

freq-mod commented 4 years ago

@jpcima there is one - PMD for IBM PC OPL2: https://github.com/NoyemiK/PMD-for-IBM

farvardin commented 4 years ago

@papiezak I've tried to fiddle around with this tool and I discovered it's not supposed to work with OPL2 or OPL3 chips, only OPL(1): https://github.com/NoyemiK/PMD-for-IBM/issues/1

So I don't know any other textual format for OPL2 or OPL3. Probably MML is more suitable for OPN chips.

freq-mod commented 4 years ago

Oh, I see. But OPL1 is 100% compatible with later OPL2 and OPL3, so you can kinda say it is OPL2 format as well 😄 But yeah, I don't understand why it support only OPL1 waveforms while it was meant for PCs with Adlibs or SoundBlasters... there were even commercial games which used this driver...

Wohlstand commented 4 years ago

I don't think it's a good idea to use these formats like this which supports OPL1 only for copy-paste. When speak about OPL3-BE, OPN2-BE, BambooTracker, and something also which is open source: we are really can produce own textual format which will be tagged and will contain all necessary data which will be handled by all software and every software thing will be able to store own exclusive values with no loss when copying data for using with self, and the compatibility for copying between different programs. The format would be like:

D: xxxxx=y; xxxxx=y; xxx=y; xx=y; xxxx=yyy; ....
OP1: XX=YY; XX=YY; XX=YY;....
OP2: XX=YY; XX=YY; XX=YY;....
OP3: XX=YY; XX=YY; XX=YY;....
OP4: XX=YY; XX=YY; XX=YY;....

Where D - common setup, where OPx - setup for each operator (OR raw registers, OR each OPLx related parameter like attack, decay, release, sustain, volume, AM/FM mode, etc...). The format should be tagged to guarantee full backward compatibility between any versions and any software that using this format: any unknown fields will be just ignored, any missing fields will just be set with a default value, etc.

jpcima commented 4 years ago

There are already some established specifications, It's important that we use them. To add our own specification is a possibility, I think of it as secondary.

A generic way how to establish this, it's to put together a kind of meta-grammar to construct custom format specifications, somewhat like BT does.

For an imaginary example

%(name)
OP1: %(TL) %(AR)  %(DR) %(SL) %(RR) ...
OP2: ...

And it permits to work in both directions, loading and saving.

freq-mod commented 3 years ago

Also, I'm having a problem with variation of FMP and PMD - they aren't even regocnized by editor: FMP: '@ 0 ; name '@ 31, 0, 0, 7, 0, 32, 0, 0, 0 '@ 31, 0, 0, 7, 0, 0, 0, 0, 0 '@ 31, 0, 0, 7, 0, 32, 0, 0, 0 '@ 31, 0, 0, 7, 0, 0, 0, 0, 0 '@ 4, 0

PMD: @ 0 4 0 =name 31 0 0 7 0 32 0 0 0 0 0 31 0 0 7 0 0 0 0 0 0 0 31 0 0 7 0 32 0 0 0 0 0 31 0 0 7 0 0 0 0 0 0 0

Wohlstand commented 7 months ago

Closing as abandoned. If something still need to debug/improve, please re-open.