You are not logged in. Please login or register.
The 1-Bit Forum → Sinclair → 1tracker v0.47
New engines, very impressive!
Someone I know has found a way to compile 1tracker for 64 bit. He made a (linux) script to fix this. Basically it retrieves the original angelscript code, change a few words, and recompile everything (because I think some code was precompiled for 32bit in angelscript. How could be the right way to fix this upstream? Through a patch or a new makefile? (_x86 should be replaced by _x64 in the makefile for example)
Wow wow wow... massive thanks for all the work, Shiru! And sorry for the radio silence, I had no internet access for the past 5 weeks. Now catching up with all the stuff I've missed. Will write more later.
I think it should be possible to fix the makefile to handle 64-bit compilation. Though as a lazy fix, I guess forcing 32-bit compilation on 64-bit systems would do, as I doubt 1tracker will benefit much from having access to >4GB of RAM.
Added more engines without changing the front end version. Mostly old classic engines. Music Box (Wham) - unlike Beepola it is complete with drums, Music Synth 48K, QChan, Tritone, and its new flavour called Tritone Digi (with sampled drums). Also a very basic YM2413 engine LLBasic, in case you're interested in other formats.
Awesome, thanks Shiru!
Forgot to mention, I did apply a few changes to the source last time. All of them cosmetic, but Clang will have a fit about these.
gui.h:9
int put_str(int x,int y,char* str,unsigned char col) =>
int put_str(int x,int y,const char* str,unsigned char col)
gui.h:42
void put_str_file(int x,int y,char* str,unsigned char col) =>
void put_str_file(int x,int y,const char* str,unsigned char col)
main.cpp:641
int put_str(int x,int y,char* str,unsigned char col); =>
int put_str(int x,int y,const char* str,unsigned char col);
select_engine.h:34, 104
if (dp = opendir(engineDirectory)) =>
if ((dp = opendir(engineDirectory)))Also added -fPIC flag in makefile. Position-independant executables are now the default on most Linux distros, but the Angelscript JIT compiler doesn't like that idea, it seems.
More critically, since a few versions there is still a bug that will cause random "engine provided no data" errors. I cannot get a reliable way of reproducing it though. It mostly happens after applying a marker and then entering something on the first row of the new block. Though sometimes it will happen in the middle of a block as well. Usually the problem starts occuring only after editing for a while (though it will then persist through restarts), but I've occasionally had it happen on an almost blank tune as well.
Thanks, will add these changes.
To me there is no such issue with frequent 'no data' error, at least as far as I tested all newly added engines in a few months. One or two engines had this issue, but it happened very ocassionally, but wasn't able to figure it out yet - thought it is engine related, and it is not repeats too often, so I thought maybe other fixes changed that too. Situation was partially similar - by editing the first row, with almost blank tune. Alright, will keep the eye on it.
A new engine added without changing the version, Ear Shaver.
Anyone made a demo track with it ?
No, not yet.
I finally found a way of consistently reproducing the "Engine not provide any data" bug that I mentioned above.
To reproduce:
1) load the attached .1tm
2) F5 to play, F5 to stop again
3) Move cursor to last column, press 1
I don't know if it is reproducible under Windows, if not then probably some memory is not being initialized to 0.
Some more info: Bug happens regardless of the engine used. As mentioned, it almost always happens when trying to enter something at the beginning of a block. Once it occurs, it is persistent, ie no data that would trigger a row play can be entered at this position anymore regardless of any further actions taken.
Thanks for report. Will take a look and figure it out whenever I'll get time to do another chunk of updates.
anyone know if theres an undocumented limit on length of track? i have a .1tm work in progress at the moment that doesnt seem to export to tap successfully. rather it gives a .tap but with opening 1st note only.
There are various limits, of course, but if a song plays in the tracker, it should be exportable - the tracker creates an AY file internally in order to play the music. So it is some bug, I guess, will take a look soon.
Edit: tested it, the export works fine, TAP plays correctly, so the issue is not confirmed. Update to the latest version, perhaps? (tested in 0.29)
looks like it was the emulator (fuse) that i was using that was the issue after all, tried the .tap export on a different one and it seems to work ok. thanks for looking into it though! ive had a lot of fun with this software.
A little feature request. Would it be possible to break long data lines in the asm output (such as the ones produced by wav import)? Some assemblers choke on these, including sjasmplus.
Sure, but this is done on per-engine basis, so no quick fix. Some engines do break long lines, while others (Tritone Digi?) not. Will handle this a bit later.
A minor update to v0.3, libs updated, some issues fixed, SquatE added. Windows x64 build introduced.
There is an unofficial fork of Game_Music_Emu that is still maintained. However, I ran into a weird issue with it that it works properly only in Debug build, but glitches all around in Release (mostly cuts playing after a very short while). Wasn't able to figure it out, so I decided to stick to the latest official version, even though it is kinda old.
Looked into getting v0.3 running on my machine today.
First, a couple of changes to the makefile:
-I./libs/angelscript/angelscript_jit -> -I./libs/angelscript_jit
1tracker: libs/angelscript_jit/virtual_asm_x86.o -> 1tracker: libs/angelscript_jit/virtual_asm_x64.o
virtual_asm_x86.o: libs/angelscript_jit/virtual_asm_x86.cpp -> virtual_asm_x64.o: libs/angelscript_jit/virtual_asm_x64.cppI'm also building with clang instead of gcc. Anyway, building fails with a number of errors.
./gui.h:447:7: error: no matching function for call to 'draw_menu_item'
x = draw_menu_item(x, (editStyle != EDIT_STYLE_CHOPPED)?"~F1~-Chop":"~F1~+Chop");
^~~~~~~~~~~~~~
./gui.h:409:5: note: candidate function not viable: no known conversion from 'const char [10]' to 'char *' for 2nd argument
int draw_menu_item(int x, char *str)
^
./gui.h:449:7: error: no matching function for call to 'draw_menu_item'
x = draw_menu_item(x, !quietMode ? "~F2~-Quiet" : "~F2~+Quiet");
^~~~~~~~~~~~~~
./gui.h:409:5: note: candidate function not viable: no known conversion from 'const char [11]' to 'char *' for 2nd argument
int draw_menu_item(int x, char *str)
^Easy fix, change gui.h:409 to
int draw_menu_item(int x, const char *str)./select_engine.h:34:9: warning: using the result of an assignment as a condition without parentheses [-Wparentheses]
if (dp = opendir(engineDirectory))
~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
./select_engine.h:34:9: note: place parentheses around the assignment to silence this warning
if (dp = opendir(engineDirectory))
^
( )
./select_engine.h:34:9: note: use '==' to turn this assignment into an equality comparison
if (dp = opendir(engineDirectory))
^
==
./select_engine.h:120:11: error: use of undeclared identifier '_fileno'; did you mean 'fileno'?
fstat(_fileno(file), &fileStat);
^~~~~~~
filenoOk, change select_engine.h:34 to
if ((dp = opendir(engineDirectory)))and :120 to
fstat(fileno(file), &fileStat);Not sure about the latter one. Anyway, now 1tracker builds (with a number of warnings, mostly from angelscript, nothing too serious as far as I can tell.
So I proceed to fire up 1tracker and start a new SquatE song. On entering the first note, this happens:
Z80Ass error: label already defined!
281: .loop
[1] 6479 segmentation fault ./1trackerWhoops! Same thing happens on the old Squat, but not on wtbeep, for example.
Thanks for report. Turned out there is a metric ton of various issues in the v0.3 release, working on fixing them for a while now.
song_editor.h:979
if(key>=SDLK_KP_0&&key<=SDLK_KP_9)That looks like a bug to me, because SDLK_KP_0 = 0x40000062 and SDLK_KP_9 = 0x40000061.
Yeah, by some reason SDL designers decided to not go in order, like ASCII or VK codes, and I didn't notice it.
All,
Have just noticed - version 0.3 no longer works on Windows XP.
v0.29 does, and am still tinkering with it.
Just wanted to give a heads up. Not that anyone else in the world still uses XP other than myself.
Cheers,
I don't think I did anything that would break this compatibility. It is an SDL2 app, maybe something happened with the lib in lastest updates. Will check it out sometime later, thanks for report.
v0.31 is out. Many fixes in the front-end and many engines. Minimal examples and docs for each and every engine. The classic two-channel engine from Robin Hood is added, in all of its original glory.
Yay for new docs, and for Robin. Does that one predate Tim Follin's first engine, actually?
SquatE engine still segfaults on entering a note. It does not segfault in v0.29, so the bug is somewhere in 1tracker itself, not in the engine.
./instrument_editor.h:646:187: error: use of undeclared identifier 'FALSE'
...set_input_string(instrumentGuiParamXOff, instrumentGuiList[instrumentGuiCursor].y + PATTERN_YPOS + 1, instrumentGuiList[instrumentGuiCursor].max_len, MODE_INSTRUMENT_INPUT_DONE, FALSE, (char*)&module.instrument[curInstrument].data[...Should be "false", I suppose?
Also, gui.h:72, char is always < 128, so the "||c>=128" is redundant.
Compiler is also throwing a lot of warnings about strncat ("the value of the size argument in 'strncat' is too large, might lead to a buffer overflow"), doesn't seem to be an actual problem though.
Thanks for report. Yeah, just noticed there is still issues with that, even though it does not do segfault to me. Damnit. Alright, more work to do!
Robin of the Wood game is from 1985, Follin started to do his stuff including Vectron the same year, so it is difficult to say, but it is sure one of the earliest. Also features kinda unusual channel mixing with a single out per loop, take a look (guess that's where ZX-3/10 and Squeeker roots are?).
The 1-Bit Forum → Sinclair → 1tracker v0.47
Powered by PunBB, supported by Informer Technologies, Inc.