gopher-atz / 4klang Goto Github PK

In 4klang.asm, the lines 251-253 are:

fld1
fadd	st0	
fyl2x

I believe they do absolutely nothing to the stack and can be removed. To see this, I added some comments:

         ; Stack: x
fld1     ; Stack: 1 x
fadd st0 ; Stack: 2 x
fyl2x    ; Stack: x*log2(2)      ... which is *drumfill* just x

I think they are a left-over from a time when the power function could compute any power, not just 2^x. Also, I'm just learning x86 assembly so there could be something I'm missing here; however, I just ran some regression tests after deleting these three lines and all my regression tests seem to pass.

Also, the comments seem to be completely off, I think better comments could be:

              ; x
fld1          ; 1 x
fadd st0      ; 2 x
fyl2x         ; x // until this line could be completely removed?
fld1          ; 1 x
fld st1       ; x 1 x
fprem         ; mod(x,1) 1 x
f2xm1         ; 2^mod(x,1)-1 1 x
faddp st1,st0 ; 2^mod(x,1) x
fscale        ; 2^mod(x,1)*2^trunc(x) x
              ; Equal to:
              ; 2^x x
fstp st1      ; 2^x
ret

https://github.com/hzdgopher/4klang/blob/e28554120325fcaaebbe8189eef16b57fd83f0a8/4klang_source/4klang.asm#L1497

My understanding is that this short jump to next line is unnecessary.

I've attempted to port the player to macho64, and it plays, but it has some glitches here and there.

My attempt is part of porting the the-emoji-demo to 64 bit, so it will live on on current and future macs, at least until they decide to pull another architecture swap on us.

kode54/the-emoji-demo@a9f61ed

For some of the builds 4klang will reliably crash on either this https://github.com/hzdgopher/4klang/blob/e28554120325fcaaebbe8189eef16b57fd83f0a8/4klang_source/4klang.asm#L930 or this https://github.com/hzdgopher/4klang/blob/e28554120325fcaaebbe8189eef16b57fd83f0a8/4klang_source/4klang.asm#L962 lines just 10-20 seconds into synthesized music. eax looks unreasonable.

It seems like go4kDLL_wrk.index value gets corrupted. Not sure where, when and why exactly.
Padding it with 256 bytes (not tried other values really) prevented crashing for at least one of the tunes on a slightly older version of 4klang (doesn't seem to help the latest version from this repo):

struc  go4kDLL_wrk
+       .padding resd 64
        .index          resd    1
+       .padding2 resd 64

The crash may happen on both Windows and Linux for binaries built with their default linkers.
The crash rarely happens if the binary was linked using Crinkler, but everything else was exactly the same.
In rare cases it is possible to randomly tweak e.g. asm/C source of the intro in such a way that a "debug" (not linked using Crinkler) binary won't crash.

Almost all of jetlag 4k intros are affected by this problem :D.

Working on the current master branch.

When exporting a song with a global store and without a glitch, in the exported .inc file GO4K_FSTG_ID is set to 13 but should be 12, because there is no glitch op code and thus _go4kFSTG_func is at index 12 in the go4k_synth_commands table. See here

The 'else' branch (that adds filler in case glitch is not used) was removed on purpose to maintain compatibility with pre-glitch songs, but the current exporter always exports GO4K_FSTG_ID as 13.

The 4klang.asm version in Go4kVSTI/win directory works by adding the filler but in the process breaks compatibility.

Short term solution is to export GO4K_FSTG_ID as 12 if glitch is not used, and 13 if glitch is used.

However, would it be possible to not include the function pointers in the go4k_synth_commands in case a particular unit is not used? This should even save a few bytes, right? And then give all units IDs accordingly in a running manner in the exported .inc file, in case the unit was used.

This would be useful for coders to avoid having to search for the exact 4klang commit able to play the track in the demo without crashes/compiler problems.

Hi,

I'm wondering why is the gate oscillator low-pass filtered. Specifically, I'm referring to these lines. I rewrote the comments to understand what is happening:

fld     dword [WRK+go4kVCO_wrk.gatestate] ; g x, g is gatestate, x is the input to this filter 0/1
fsub    st1                               ; g-x x
fmul    dword [c_dc_const]                ; c(g-x) x
faddp   st1, st0                          ; x+c(g-x)
fst     dword [WRK+go4kVCO_wrk.gatestate] ; g'=x+c(g-x)
;
; Another way to look at this (remembering that c~0.996)  
; g'=cg+(1-c)x
; output g'

That is a low-pass filter / exponentially decaying moving average of x. I'm looking at the waveforms outputted by the gate and for sure they low-pass filtered versions of the input (gate bit).

Why generate an interesting gate signal and then filter all the interesting details away? Maybe gate was meant only for LFOs and this is to slightly smooth the signal?

Or maybe the point was to have a highpass filter i.e. to remove DC-offset? Then the code should return x-g' instead of g'.

Finding particular versions of 4klang.asm is somewhat inconvenient as the workflow involves matching timestamps of release posts made on the Pouet prod page of 4klang with 4klang's commit timestamps (the urls in the release posts usually go to the master branch, which makes identifying older tags difficult).

I suggest creating release tags for the 4klang versions commonly used. Bonus points if VST binaries are added :)

Using the current 4klang 3.2.2 from master, recording fails when exporting a local STORE command (target: LOAD) in a global instrument.

Steps to reproduce: Load the offending patch (attached) in 4klang, try recording anything. I used 16-bit output if that has any significance.

Expected behavior: The .inc file is created as expected.

Observed behavior: 4klang crashes and takes the host with it. The last lines in the exported .inc file are:
...

GO4K_BEGIN_PARAMDEF(Global)
	GO4K_ACC	ACCTYPE(AUX)
	GO4K_DLL	PREGAIN(128),DRY(128),FEEDBACK(96),DAMP(64),FREQUENCY(0),DEPTH(0),DELAY(19),COUNT(1)
	GO4K_FOP	OP(FOP_XCH)
	GO4K_DLL	PREGAIN(128),DRY(128),FEEDBACK(96),DAMP(64),FREQUENCY(0),DEPTH(0),DELAY(19),COUNT(1)
	GO4K_FOP	OP(FOP_XCH)
	GO4K_VCF	FREQUENCY(76),RESONANCE(32),VCFTYPE(BANDPASS|STEREO)
	GO4K_FLD	VALUE(65)
	GO4K_FOP	OP(FOP_ADDP)
	GO4K_FST	AMOUNT(128),DEST(14*MAX_UNIT_SLOTS+0+

...that's it, that's where it ends. Looking at the source, I assume it crashes here. Wtf? modes.c_str() returns an invalid string?

Running on windows 10, 64-bit, inside renoise 3.2.1.

offending_patch.zip