pouët.net

Has anybody else had these kind of problems with 4klang's version 3.0?
- with some instrument settings, 4klang fails to produce an .obj file
- with any kind of inter-instrument modulations with the store component (i.e. "global" modulations instead of "local"), the render() function call crashes.

Particularly the latter was a spoiler, because without inter-instrument modulations, you can't really do any interesting sounds.

I wrote about these things to atz4klang @ untergrund.net, but while waiting for an answer I started digging into the source code, which is available, and I found a couple of possible bugs. I don't know if they're really bugs, but at least with my edited version, it's now working without crashing.

If anyone's interested, reply something here and I'll upload the changes somewhere. Or is everybody still using an older version?

Probably has to do with the modulations, aegis had that problem with the track to Mayos. I don't know how it eventually got fixed though but removing certain modulations from the global channel to an instrument helped.

Ok, here's the modified version.

Changes
- Go4kVSTiCore.cpp / Go4kVSTi_SaveByteStream(): in the long fprintf() part, I added fprintf() lines for writing out the definition for the previously missing struct struc go4kDLL_wrk2, along with %%ifdefs GO4K_USE_DLL_MOD, GO4K_USE_DLL_MOD_PM etc. as far as I understood how they should work. The lack of this struct definition was the reason for 4klang not producing an .obj file with some routings.
- Go4kVSTiCore.cpp / Go4kVSTi_SaveByteStream(): in the long fprintf() part I exchanged the equ values for GO4K_FSTG_ID and GO4K_FLD_ID, 11 <-> 12, because that's how they seemed to be in the "full" 4klang.inc file. This fixed the crashing with inter-instrument routings.
- Commented out the lines which delete the temporary files, so now you get to see the generated . asm and .inc files in %TEMP%. This was necessary to debug the issues.
- Changed the VSTi GUI's font to Comic Sans!!! So it's evident that this is not the original version. ;)

By the way, if you want to debug 4klang's asm code, use YASM instead of NASM, because NASM doesn't generate debug information for Win32. YASM seemed to work as a direct replacement and I got working debug info for Visual C++ 2010 Express by compiling like this:
yasm -f win32 4klang.asm -g cv8 -o4klang.obj

You should change the color theme to pink and add a My Little Pony background as well.

I thought Comic Sans was already awful enough.

For the last 4klang release (3.0) we (Titan) also discovered some bugs:

- Go4kVSTiGUI.cpp, line 307: Must be sprintf(text, "%.2f ms", (float)delay/44.100f); - otherwise the buffer is not large enough
- Go4kVSTiCore.cpp, line 2561: Must be ~ char type[20]; - otherwise the buffer is not large enough and saving of FOP_LOADNOTE will crash
- Go4kVSTiCore.cpp, line 2729: Must be ~ char type[20]; - otherwise the buffer is not large enough and saving of FOP_LOADNOTE will crash

Thanks. Can you post the modified cpp file somewhere, with your edits marked in comments? I'd like to incorporate the changes to my version and then put up a link to the modified binary in this thread.

since i was pretty lazy lately this took a while.
but i finally got around looking into the above issues and proposed fixes.

yzi: yes, dll was missing the wrk2 definition and i had a typo for the fld/fstg ids
neoman: yes.

both changes applied and put into a new package (version 3.0.1)
http://4klang.untergrund.net/
ftp://ftp.untergrund.net/users/atz4klang/3.0.1/4klang_release.zip

thanks for the feedback and feel free to confirm :)

..And suddently comic sans is in the original version too :P

well i'll leave that "customization" for anyone who actually wants that :)

give us neuropol!

From my own experience, these crashes occur in demo-scope (that is, AFAYK not in the VST) when storing values that are out of range to target operators (or when stored values plus values on these operators are out of range). The "out of range" concept differs in each case but for instance a distortion ranging from -128 to 127 cannot have any value that, added to any storing operator out there affecting it, gives a value <-128 or >127.

gopher: Thanks for the fixes. :D

Merry:
normally you should avoid having values out of the valid parameter range, true.
but in the worst case this will fuck up your sound signal giving nan or inf values for the rest of the signal chain.
it shouldnt result in a crash though, neither in the vsti nor in the executable.

Then again, all you need is one delay line somewhere, and a single NaN will fuck up everything for good.

Soundwise yes :)

@gopher: in some situations it crashes, for sure. I have a song somewhere I've sent either to you or pOWL a year ago when I don't remember if 2.8 or 3.0 was released, demonstrating this situation.

Last song I did for Revision was fucked up due to this and I did a very tiring work reviewing all modulation stuff until I got everything working so I'm pretty sure this breaks everything outside the VST.

I'm not sure if Buckethead is using the latest release, hopefully he is, but I'm running into some problems with some Mac OS X object code he output, for a potential port I hope to do.

Not only is the object 32 bit only, but it doesn't observe stack alignment constraints, so my program crashes shortly after rendering the audio.

Also, it would be pretty cool to be able to either have the audio fed out through a callback, or rendered in ticks at a time, to make it possible to shorten the startup time when the intro is running on a system fast enough to render both the demo and the music in real time. Certainly should be possible on any system where the music only eats up 20-50% of a single core, and can be spun off into a background thread with synchronization events for the demo timing. Probably not that useful yet, but I'm putting the cart before the horse and looking for useless things to do to this port.

Hell, I can't even start with just the libraries it already uses, since it's based on framework64k and that doesn't have a working Mac port yet.

Hi Kode54, I used 3.0 ;(
(Will check Mudlord)

No problem, the include data looks compatible anyway.

The real problem looks to be like it will be a bit of a problem to port the player to 64 bit, and also fix up the alignment issues. Latter looks like it may even be as much work as the former, I have no idea.

Thanks for your help, that tune is awesome in the intro.

I just tried the old linux sample sources from 2009 on a more current linux.

Since bascially everything is 64bit now you need all the 32bit dev-libs (SDL etc.). Additionally you will have to fix the makefile, since a couple of things changed over time...

Oh and you need to add -m32 of course.

las: so were you able to get the Linux stuff working back in 2015? I happened to try the Linux example, and managed to compile the main c source with a few tweaks, but my Debian apt skills weren't enough to get the SDL and OpenGL and GLEW libraries to link. Maybe the :i386 libs haven't been updated or something.

Yep, worked back then. But I currently have no Linux installations available to me and I think Linux has unfortunately failed as a platform for demoscene productions where binary compatibility matters. From an organizer point of view I have to add that supporting Linux/Unix systems creates an overhead for most probably something like two "not so great" productions.