New presentation for ZX Spectrum: "New Wave"

edited March 2013 in Brand new software
Post edited by Yerzmyey on
ZX81/ZX Spectrum/Amiga/Atari music: http://yerzmyey.i-demo.pl/

Comments

  • edited March 2013
    Yerzmyey wrote: »

    Hey! Really cool stuff. And your music/sounds/samples are envyable as usual :D :D :D

    What does mean that gasman fixes soundtracker bugs(in "thanks" section)???
    You did this song with the standard soundtracker for 128k? O_o HOW?! :D :D
  • edited March 2013
    Great stuff! Reminds me of earlier days going 'wow' at similar effects on other computers. Nice to see the Speccy (48k at that) having a good go with graphics and music.
  • edited March 2013
    Excellent work!
    No one important.
  • edited March 2013
    great demo, loved the 3D zombie/soldier things section...
  • edited March 2013
    Thx guys. :)




    DaRkHoRaCe:

    > What does mean that gasman fixes soundtracker bugs(in "thanks" section)???
    After over 20 years of using the program, we found really disturbing bugs relater with order of patterns/positions.


    > You did this song with the standard soundtracker for 128k? O_o HOW?! :D :D
    Yes, this is standard SoundTracker, it just wasn't able to correctly use specific patterns in their positions. Gasman was kind enough to help us and do some tricky cracking.


    PS: SoundTracker is for 48K btw.
    ZX81/ZX Spectrum/Amiga/Atari music: http://yerzmyey.i-demo.pl/
  • edited March 2013
    Does that mean there is now a patched bug free version of sound tracker out there available for use now?... We'd love to hear more! :p

    ..as for the demo... I found myself saying, "..how the heck does he do that?!!..." at least a few times!!!

    Nice music - Even more impressive considering its just plain ol' SoundTracker!!!

    I thought the typical Soundtracker player routines were quite slow for demo use - are you using a modified player routine?...

    Lovely work!

    :smile:
  • edited March 2013
    Kgmcneil:

    > Does that mean there is now a patched bug free version of sound tracker out there available for use now?... We'd love to hear more! :p
    As for the new hacked version, sadly Gasman has no time at the moment, he leads many projects. That's what he wrote about entire subject-matter:

    ******************************
    OK, it took a load of hacking on the Soundtracker internals to figure it
    out, but I think I've fixed it...

    The rule seems to be: if you use high-numbered patterns (15, 16, 17...)
    then the lower numbers MUST be used somewhere in the position list too...
    but it doesn't matter where they are in the sequence. Even putting
    them *after* the looping point of the song works. So, if this happens
    again: just set the patterns after the looping point to be 1, 2, 3, 4...
    before saving the song.

    I think there must be some more complex conditions for this bug to occur,
    because there's no way that such a stupid bug would be undiscovered
    for 20 years - we would see it happening every time we write a pattern,
    play it back and think "hmm, no, that's crap, but I'll keep
    it in case I can use it later" :-) Anyway: I discovered that the lost
    pattern data IS present in the saved data file, so it now seems that the
    bug is in the LOADING routine, not saving... which means that Soundtracker
    and the compiler probably use the same broken code. I have some ideas about
    where the code is failing, but a proper analysis and bugfix will have to
    wait for some other time. One day... :-/

    Greetz,
    - Gasman
    ******************************


    > ..as for the demo... I found myself saying, "..how the heck does he do that?!!..." at least a few times!!!
    Yupp, the coders guys made a good job, and mostly Alone Coder and Lord Vader.


    > Nice music - Even more impressive considering its just plain ol' SoundTracker!!!
    Thx a lot, and yes - I use only a regular SoundTracker for synthetic music.


    > I thought the typical Soundtracker player routines were quite slow for demo use - are you using a modified player routine?...
    Lovely work!
    :smile:
    Converting SoundTracker songs into ProTracker's procedure is very easy and takes maybe 1 minute (the sound sounds then exactly the same like on original STC).
    However this time I was sending to Alone and Lord only regular SoundTracker songs compiled into specific RANDOMIZE given to me by Lord.

    Best regards,
    Y
    ZX81/ZX Spectrum/Amiga/Atari music: http://yerzmyey.i-demo.pl/
  • edited March 2013
    A bit more detail on the Soundtracker bug:

    When you save a song in Soundtracker, it will scan through the 255 'position' slots, checking which pattern numbers are in use. If it finds any unused patterns, it will leave them out of the saved data, moving the later patterns down to 'fill the gap'.

    So, if you have a 'positions' sequence that looks like 1, 2, 12, 11, 3, 2, 12, 11, 10, the saved file will contain the data for patterns 1, 2, 3, 10, 11, 12 - stored consecutively with no gaps.

    When the pattern is loaded back (and also immediately after saving - this "compression" is done in-place, as there's not enough free memory to give the file routines a separate buffer area for the compressed data), the scan through the positions list has to be repeated, so that it knows where to insert the gaps to bring the higher-numbered patterns back to their original locations. This is the part that's screwing up: all patterns after the 'gap' are left blank.

    It's possible that the bug only occurs in more limited circumstances than this: as I said in my mail to Yerz, I can't believe that such a fundamental bug would remain un-noticed for all this time. Either way, our current workaround is to fiddle the positions list so that all positions are used (even if they only appear after the 'end' point of the song), so there are no 'gaps' in the saved file.

    It appears that the bug is in the loading routine, not saving: the 'lost' pattern data IS present in the saved file, as far as I can tell. It fails in the same way when loaded into the Soundtracker Compiler, though, which suggests that the compiler is re-using the same buggy loading routine.

    (My first guess at the cause of the bug was that the loader was only scanning the positions list as far as the end point of the song: so, in the above example, if the song had a length of 6, then the loader would consider pattern 10 to be unused, and add an extra gap for it that shouldn't be there. My later tests didn't back this theory up, though.)
  • utzutz
    edited March 2013
    Great demo with stunning music. Congratulations!
  • edited March 2013
    very good
  • edited March 2013
    Thanks for the explanation there Gasman!... Sounds like the sort of bug Id introduce to anything Id code!... I can't imagine how much hair you must have lost trying to figure this out!... If its only in the loading routines, that does at least imply that a replacement loading/compiling routine could be written without having to ditch the whole SoundTracker music suite... still thats a serious bummer!...

    Id be interested to hear what Vader & alone coder did with the SoundTracker data in the end, whether they used the standard player routines or a modified one (or, as Yerzmyey mentioned, converted it into something else, like PT3 first)...

    Either way, great work guys!... The results were worth the effort!...
  • edited March 2013
    Hi guys,

    just a short&small message - there are now available two soundtracks from the "New Wave" demo (the first in full version - in the demo we had to cut it to 48K).
    http://yerzmyey.i-demo.pl/Yerzmyey-Alone_New_Wave_Full_Version.mp3
    http://yerzmyey.i-demo.pl/Yerzmyey-New_Wave_2.mp3

    Best wishes!
    Y
    ZX81/ZX Spectrum/Amiga/Atari music: http://yerzmyey.i-demo.pl/
  • edited March 2013
    gasman wrote: »
    A bit more detail on the Soundtracker bug:

    When you save a song in Soundtracker, it will scan through the 255 'position' slots, checking which pattern numbers are in use. If it finds any unused patterns, it will leave them out of the saved data, moving the later patterns down to 'fill the gap'.

    So, if you have a 'positions' sequence that looks like 1, 2, 12, 11, 3, 2, 12, 11, 10, the saved file will contain the data for patterns 1, 2, 3, 10, 11, 12 - stored consecutively with no gaps.

    When the pattern is loaded back (and also immediately after saving - this "compression" is done in-place, as there's not enough free memory to give the file routines a separate buffer area for the compressed data), the scan through the positions list has to be repeated, so that it knows where to insert the gaps to bring the higher-numbered patterns back to their original locations. This is the part that's screwing up: all patterns after the 'gap' are left blank.

    It's possible that the bug only occurs in more limited circumstances than this: as I said in my mail to Yerz, I can't believe that such a fundamental bug would remain un-noticed for all this time. Either way, our current workaround is to fiddle the positions list so that all positions are used (even if they only appear after the 'end' point of the song), so there are no 'gaps' in the saved file.

    It appears that the bug is in the loading routine, not saving: the 'lost' pattern data IS present in the saved file, as far as I can tell. It fails in the same way when loaded into the Soundtracker Compiler, though, which suggests that the compiler is re-using the same buggy loading routine.

    (My first guess at the cause of the bug was that the loader was only scanning the positions list as far as the end point of the song: so, in the above example, if the song had a length of 6, then the loader would consider pattern 10 to be unused, and add an extra gap for it that shouldn't be there. My later tests didn't back this theory up, though.)

    Can you share your modded version of soundtracker please?
  • edited March 2013
    DaRkHoRaCe wrote: »
    Can you share your modded version of soundtracker please?

    No, because I haven't made one yet :-)

    All I've done so far is analysed the problem far enough to work out roughly where the bug is, and how to arrange your project so that the bug isn't triggered... I haven't found a fix for the bug yet. When I do, I'll be happy to share a modded version (of both Soundtracker and the compiler - it looks like they'll both need fixing).
  • edited March 2013
    Ok! But, are you talking about this version of S.T.?

    http://www.worldofspectrum.org/infoseekid.cgi?id=0012090

    Because I use this and I've never had those problems.
  • edited March 2013
    DaRkHoRaCe wrote: »
    Ok! But, are you talking about this version of S.T.?
    http://www.worldofspectrum.org/infoseekid.cgi?id=0012090
    Because I use this and I've never had those problems.

    We use this program for over 20 years and never had those problems neither. :) :)
    ZX81/ZX Spectrum/Amiga/Atari music: http://yerzmyey.i-demo.pl/
  • edited March 2013
    A very nice demo, I can hardly believe that such program runs in a 48K machine.

    I made some changes in the BASIC loader of TRD version, so it can also run from Beta 48 interface (the most cloned model in Brazil):
       1 REM NEXT GO SUB {=\ LLIST !?
       2>RANDOMIZE USR VAL a$: BORDER z: PAPER z: INK t: CLEAR c
       3 OUT CODE " DRAW ",NOT PI: READ a$: RANDOMIZE USR VAL "15363+256*(PEEK 15363<>195)": REM : LOAD a$CODE
       4 OUT CODE " DRAW ",CODE "USR ": RANDOMIZE USR VAL "24576": GO TO PI
       5 DATA "initial","tzoom","tride","pila","msh1","msh2","playshpr","swscroll"
    
    Do not edit the first line because it contains machine code.

    You must type the following line in the BASIC editor before saving the program above:
    LET z=0 : LET t=3 : LET c=24575 : LET a$=CHR$ 190+"23635+256*"+CHR$ 190+"PEEK 23636+5"
    

    I admit that typing is cumbersome, but RAMTOP is very low and forced me to use some memory saving techniques.
    My blog (in Portuguese): Cantinho do TK90X.
Sign In or Register to comment.