GXSCC porting over to FamiTracker?

General discussion about tracking, help and support.
User avatar
HertzDevil
Posts: 475
Joined: Thu Apr 23, 2015 7:39 pm
Location: Hong Kong SAR
Contact:

Re: GXSCC porting over to FamiTracker?

Postby HertzDevil » Mon Jul 13, 2015 8:01 am

I don't think anyone here understands that the purpose of the OP is to ask for porting GXSCC instruments to FamiTracker.

For GXSCC you can, but quite a lot of precision will be lost in the process; GXSCC uses very long ADSR volume envelopes (that has higher precision than SCC itself does), and its waveforms are 8-bit (FDS uses 6, N163 uses 4). Assuming Beta 236 is used, The SCC waveforms are located at 0x51158, each containing 8 bytes of what appears to be some average value, 32 bytes of the wave name, and 32 unsigned bytes of the waveform itself (this is how the SCC works). The instrument mapping is located at 0x53DAC, containing 128 integers for each of the 8 instrument sets available in GXSCC; the volume envelopes are located at 0x551B0, each containing 5 integers:
  • Attack duration, in samples; (if you use different sample rates for GXSCC, its volume envelopes will scale with the sample rate)
  • Decay duration, in samples;
  • Sustain level, maximum is 0x0000FFFF;
  • Release duration (after sustain), in samples;
  • Release duration (after note off), in samples.
The GXSCC percussion instruments seem to have been hardcoded.

For GXOPLL it is even simpler: all its instruments are located at 0x50824, 8 bytes per instrument. Because VRC7 is a dumped-down version of OPLL, those patches work immediately when copied into the VRC7 instrument editor from a hex editor. In GXOPLL the instrument mapping for the melodic MIDI instruments is located at 0x5373C; by altering this table it is possible to use custom OPLL patches within GXOPLL, and neither OPLL nor GXOPLL will enforce one single custom patch for all channels since only VRC7 does that.

If you want to use these instruments losslessly, TriloTracker is a native tracker that uses the Konami SCC and the AY-3-8910. (A private beta version exists that uses the OPLL instead of SCC.) In particular, "METAL SIN" has appeared in many places under names such as "Konami Lead" or "Konami Organ".
Attachments
GXOPLL.ftm
All GXOPLL patches, including the 15 melodic patches, and 3 patches for the percussion channel. There might be more percussion patches not included in this FTM.
(939 Bytes) Downloaded 81 times
GXSCC.ftm
All GXSCC waveforms (except "PULSE SQUARE 50%", which is a half-volume version of the square wave), without volume envelopes, since there might be multiple instruments using the same waveform, but each having a different envelope.
(4.04 KiB) Downloaded 108 times
Last edited by HertzDevil on Mon Jul 13, 2015 6:27 pm, edited 1 time in total.
refactoring 0cc-famitracker

User avatar
SamW
Posts: 50
Joined: Mon Apr 20, 2015 6:35 pm
Location: Belfast, UK
Contact:

Re: GXSCC porting over to FamiTracker?

Postby SamW » Mon Jul 13, 2015 12:22 pm

Thank you Hertz for being the only one to make an actual constructive post in this thread.
ym2612 extraordinaire, metal & edm producer, professional weeblord, head over heels for harumi

twitter
soundcloud
super famidev

User avatar
HertzDevil
Posts: 475
Joined: Thu Apr 23, 2015 7:39 pm
Location: Hong Kong SAR
Contact:

Re: GXSCC porting over to FamiTracker?

Postby HertzDevil » Mon Jul 13, 2015 7:42 pm

As an example, here we extract the Harpsichord instrument, that is MIDI instrument 7 (one-based), from GXSCC's "SCC like Full-Set":
  1. The waveform mapping table is located at 0x53DAC, and the map for "SCC like Full-Set" is also at 0x53DAC:

    Code: Select all

    05 00 00 00
    03 00 00 00
    03 00 00 00
    01 00 00 00
    0A 00 00 00
    0A 00 00 00
    06 00 00 00
    ...

    The 7th entry reads 0x06; this is the waveform index we need.
  2. The waveform definition table is located at 0x51158; skipping over the first 6 waves, we have:

    Code: Select all

    64 00 00 00 00 00 00 00
    58 36 20 53 51 55 41 52 45 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 70 70 00 00 80 80 80 00 00 00 00 70 70 70 00 80 80 00 00 00 00 70 70 00 00 80 80

    The first 8 bytes have no purpose; the next 32 bytes read "X6 SQUARE", and the last 32 bytes are the waveform itself.
  3. The waveform is unsigned, so it must be converted into a signed sequence first. Entries larger than 0x7F are subtracted by 0x100, and then 0x80 is added to all samples, so the waveform gives:

    Code: Select all

    128 128 128 128 128 240 240 128 128 0 0 0 128 128 128 128 240 240 240 128 0 0 128 128 128 128 240 240 128 128 0 0

    For the purpose of fitting into the N163, we right-shift all samples 4 times:

    Code: Select all

    8 8 8 8 8 15 15 8 8 0 0 0 8 8 8 8 15 15 15 8 0 0 8 8 8 8 15 15 8 8 0 0

    This will be the waveform being entered in the N163 instrument editor.
  4. The volume envelope table is located at 0x551B0, and the 7th entry gives the ADSR parameters:

    Code: Select all

    00 00 00 00 41 0E 00 00 67 AE 00 00 88 58 01 00 E4 06 00 00

    Which for standard refresh rate (60 Hz) yield:
    • Attack duration: 0x0 ÷ 48000 = 0.000 s = 0 ticks
    • Decay duration: 0xE41 ÷ 48000 = 0.0760 s = 4.5 ticks
    • Sustain level: 0xAE67 ÷ 0xFFFF = 0.6813
    • Release duration (key-on): 0x15888 ÷ 48000 = 1.708 s = 110 ticks
    • Release duration (key-off): 0x6E4 ÷ 48000 = 0.03675 s = 2.2 ticks
  5. In GXSCC volume envelopes are piecewise linear, so it can be easily approximated with a script like this one, written in Lua:

    Code: Select all

    local ENVELOPE = {A = 0, D = 0xE41, S = 0xAE67, R = 0x15888}
    local SAMPLES = 48000
    local MAX_VOLUME = 0xFFFF

    function makeEnv (rate, vol)
      local function level (s)
        if s < ENVELOPE.A then return MAX_VOLUME * s / ENVELOPE.A end
        s = s - ENVELOPE.A
        if s < ENVELOPE.D then return MAX_VOLUME - (MAX_VOLUME - ENVELOPE.S) * s / ENVELOPE.D end
        s = s - ENVELOPE.D
        if ENVELOPE.R == 0 then return ENVELOPE.S end
        return math.max(0, ENVELOPE.S * (1 - s / ENVELOPE.R))
      end

      local div = (MAX_VOLUME + 1) / (vol + 1)
      local t = {}
      for i = 1, 252 do
        t[#t + 1] = math.floor(level((i - 1) * SAMPLES / rate) / div)
      end
      for i = #t, 2, -1 do if t[i] == t[i - 1] then t[i] = nil else break end end
      print(table.concat(t, " "))
    end

    makeEnv(60, 15)

    This gives:

    Code: Select all

    15 14 13 12 11 10 10 10 10 10 10 10 10 10 9 9 9 9 9 9 9 9 9 9 8 8 8 8 8 8 8 8 8 8 7 7 7 7 7 7 7 7 7 7 7 6 6 6 6 6 6 6 6 6 6 5 5 5 5 5 5 5 5 5 5 4 4 4 4 4 4 4 4 4 4 3 3 3 3 3 3 3 3 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 0

    This will be used as the volume sequence in the N163 instrument editor. Notice that it does not use the second release value at all; in GXSCC that value is multiplied with the current volume output, and FamiTracker's release envelope simply does not have this kind of functionality. The Axy effect or a single channel volume will suffice; for 0.5.0 beta 2 or before, within the tracker one could also use the Exx effect:

    Code: Select all

    ROW 00 : ... .. . E08 F01
    ROW 01 : ... .. . E01 ...
    ROW 02 : --- .. . E0F ...

    This is not suggested.
Because GXSCC does not enforce polyphony (some 80% of GXSCC videos would not exist if it does), even a single track of notes can overlap, as in the first pattern below:

Code: Select all

ROW 00 : C-3 00 F ... : ... .. . ...        C-3 00 F ...
ROW 01 : ... .. . ... : ... .. . ...        ... .. A G05
ROW 02 : ... .. 5 S02 : D-3 00 F ...        D-3 00 F ...
ROW 03 : ... .. . ... : ... .. . ...        ... .. A G05
ROW 04 : E-3 00 F ... : ... .. 5 S02        E-3 00 F ...
ROW 05 : ... .. . ... : ... .. . ...        ... .. A G05
ROW 06 : ... .. 5 S02 : F-3 00 F ...        F-3 00 F ...
ROW 07 : ... .. . ... : ... .. . ...        ... .. A G05
ROW 08 : G-3 00 F ... : ... .. 5 S02        G-3 00 F ...

This is rarely necessary, because MIDIs usually have sufficiently many simultaneous notes that no N163 channel could be spared for extra details. In that case constructions like the second pattern above can be used.

***

The act of converting MIDI files into chiptune is not incorrect in itself; Nintendo itself has created Midi2Agb for the MP2K driver which can be found in more than half of all GBA games ever released, and various early video games also used own versions of converters that produce binary music data from MIDIs. But GXSCC has proven to be worthless because:
  • The vast majority of GXSCC users do not know what the Konami SCC is, associating the software with whatever system they desire, usually NES;
  • Very few people "use" GXSCC in the sense that they produce their original MIDIs for use with GXSCC rather than exploiting existing MIDIs by other people then claiming it as their original work;
  • There are persons who upload GXSCC content to YouTube and claim that they produced the music with FamiTracker.
In the end even using primitive VSTi's in any DAW while creating the MIDI is faster than using GXSCC to get any desired result.
refactoring 0cc-famitracker

User avatar
rainwarrior
Forum Staff
Posts: 165
Joined: Thu Apr 23, 2015 8:23 pm
Location: Canada
Contact:

Re: GXSCC porting over to FamiTracker?

Postby rainwarrior » Mon Jul 13, 2015 8:45 pm

HertzDevil wrote:Very few people "use" GXSCC in the sense that they produce their original MIDIs for use with GXSCC rather than exploiting existing MIDIs by other people then claiming it as their original work;

The main reason for this, I think, is that GXSCC is a stand-alone MIDI file player, and not a VST plugin or even something that can listen to live MIDI signals. There's no convenient way to work with it to make music, it's really only good for playing pre-existing MIDI files.

User avatar
Stratelier
Posts: 378
Joined: Sun Apr 26, 2015 7:46 pm

Re: GXSCC porting over to FamiTracker?

Postby Stratelier » Tue Jul 14, 2015 3:10 am

Threxx wrote:GXSCC is a poor emulation of the Konami SCC (which now has a native tracker, making this program entirely useless).

So is that what it is? Like many others, I first heard about it through so many YouTube comments criticizing that "GXSCC != 8-bit".

za909 wrote:It's very easy to recognise its hilarious square-snare.

Usually it's chip to be square 8-) ...just not for drums.


Return to “General Talk”

Who is online

Users browsing this forum: No registered users and 1 guest