init_debugger_audio: DirectMusic not natively supported

[MaKiPL]

DirectX 6 DirectMusic not natively supported with Unix. What now?
EDIT: I talk about DirectMusic .DTS and .SGT files.
Currently I'm wrapping real DX6 component. Linux may probably require pre-converted OGG sounds.

EDIT:

• Implement loops
• Fix tempo *
• Add curves support
• Investigate WAVE effects
• Implement custom NAudio library for in-memory song writing
• Maintain final quality

*Pulse per note = tick per note; milliseconds = 60 000 / (BMP * PPQ). Now: 120 * 2000 ?

[MaKiPL]

NAudio which we use is capable to forge a Midi messages and is capable of supporting all important messages. Therefore it may be possible to actually convert SGT segments to real buffered Mdi event collections. That may require digging up the deprecated documentation of segments. Question is if it's really worth the probably huge amount of time to introduce DirectMusic converter

EDIT:
Looks like someone already made DirectMusic> Soundfont2 converter:
https://github.com/frabert/libdmusic

[Sebanisu]

cool :)

[MaKiPL]

Got the music working without using DirectMusic by parsing SGT file into sequence and translating to MIDI messages. See example state at:
b3a7785
the all tempo and things like that are constant, I just wanted to play the notes, not caring for the tempo, speed and instruments. Playback would be probably provided with FluidSynth or NAudio for both Linux and Windows just to delete use of the deprecated directmusic at all

[MaKiPL]

some notes so I don't forget:

1. seqt[n].mTime is sorted - that's good, no need for Linq every note as in prototype.
2. seqt[n].mDuration should be put on a list for a note and channel and then noteoff'd
3. seqt[n].dwPChannel has already a channel pointer- that's very good
4. seqt[n].bByte1 is note
5. seqt[n].bByte2 is velocity
6. seqt[n].bStatus is MID event, but it's always 144=noteOn

Tempo is double but it reports weird values. Maybe it's not double or something?

Thread:

• init_debugger_audio on init should create Thread. The thread should get messages from the engine.
• Every PlayMusic should clear the sequence and stop the internal MIDIEvents.
• The thread should also GC pin the unmanaged variables.

Performance:
The segment reading is faster than vanilla DxMusic

[MaKiPL]

segh::mTime

0: 62208
1: 44544
4: 154368
5: 185856
79:329024 (demo)
93:467712 (lasboss)

[MaKiPL]

I wonder if creating a MIDI itself wouldn't be faster and more stable than handling the operations on my own. Currently I have to implement a thread with tempo, curves and all that stuff, but on the other hand I can create a .mid in memory and whole synth will do it on it's own 'their way' (which I'm more than sure is way faster). Afair NAudio has whole MIDI creation class.

[MaKiPL]

DMUS_IO_TIMESIGNATURE may be wrong. The structure sizeof=8, but the algorithm reads actually (sectionLength-4) / 2 where it should be divide by 8. I just got a lot of rubbish in tims and noticed this error. Finally we lack the formulas for converting the time signature events to MIDI like- worth to follow libdmusic code to find out how the tempo and timing is parsed

[MaKiPL]

TEMPO notes:
DMUS_PPQ is const 768
Calcs: 60 000 000 (BPMPPQ)?
Current example: 1202000 = 240 000
QuarterNote is set to 360 for now
Let N= 2000 in (1202000)

N - slower
<N - faster

60 000 000 / BPM = mill->
so setTempo((60000000/BPM) - needs testing

[MaKiPL]

OpenVIII now uses custom NAudio library with my extension: naudio/NAudio#499
to write Midi to memory instead of HDD for fluid_player_add_mem

[MaKiPL]

DirectMusic segments are now played in X64 and linux. It's still WIP, I'm making new issue