Jump to content

rensoup

Members
  • Content Count

    1,066
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by rensoup


  1. 15 hours ago, VinsCool said:

    Also yes this is a 4 seconds loop, 1 pattern to be exact, but I got some ideas for that tune, even more knowing that stuff is confirmed to be stable and reliable :3 

    Great vibe!

     

    (Even though not usually my cup of tea)

     

    Feels like a tune for a platformer or something 🙂

    • Thanks 1

  2. 10 hours ago, Stephen said:

    NeoTracker supports Pokey (I think it may even support stereo pokey) as well as covox. I know with version 1.8 there's an install file you use (actually a configurator) - you select some options and then it writes out the executable.


    Ah... I got confused with the recently released Arkos tracker... Looks like Neotracker has been around for a good 15 years and never really caught up with RMT... plus the editor actually runs on the A8 ? Doesn't look like the future of A8 music to me 😐


  3. 23 hours ago, VinsCool said:

    That was the only reason I tried that out, I was curious to see if there would even be a output at all, and it looks like there was, there program would run into a out of bounds exception, but it would still generate really large sapr files, as well as .lz16 files, but they looked unusable. I also attempted to manually build a .obx by sticking together a dummied out .obx I had around and the .lz16 output, but the tune ended up running in really slow speed... which makes me think it actually did get the data but ran it at the normal speed instead, no idea what I am doing at that point lol

    yeah it should output the file fine, there really isn't any reason for it not too because it's just dumping the raw pokey data and the instrument speed is irrelevant. But it might crash when looking up the string corresponding the speed ("50hz"/.../"200hz") because it isn't there obviously 😏 (or some other equally silly crash)

    Dmsc's original LZSS player would also play it fine, but not my version because it relies on interrupts for efficiency (and that's not entirely possible above 200hz).

     

    Bottom line: Don't do it 😀

     

     

    • Haha 1

  4. 21 hours ago, VinsCool said:

    I had seen this message in the .exe when I was playing with note tables, but I guess now I found how to actually trigger it lol
    Unsurprisingly, this also makes RMT2LZSS crash when I attempt to convert modules with instrument speed greater than 4 :D It outputs sapr and lz16 files, yay for breaking everything doing unexpected things, hahahaha
    image.png.5623da2fa44cffcc4c1bd311e653e6cf.png

    Yeah it's pretty easy to support if the LZSS player just sits idle while waiting for the right scanline before running (meaning it sucks all the CPU time)...

    Like I've mentioned a while back: 400hz is possible, perhaps even 800hz... but I doubt you'd want 4 channels at 800hz because it would be a waste of cycles and also a waste of space (the tune would have to be really short to fit in 64KB). 

    Perhaps a single one and the rest at a lower playback speed. But then it means altering the LZSS compressor to compress Pokey channels individually... a bit of work for something that's not important at this point.

     

     

    That latest sketch sounds pretty good too!

    • Thanks 1

  5. 21 hours ago, Wrathchild said:

    Those were born out of the atari800 emulator and I updated these back in 2005 (a reminder to check your help/about box when running RMT).

     

    What the RMT player actually needs is the Altirra equivalent
    But from what you are saying, surely a C/C++ bridge to your C# code could be rustled together?

    Yes you're talking about the Pokey emulator, would be nice if Altirra was modular and we could use its Pokey emulation but it may not be that difficult to split it... It's not really that important (for now at least) because you can always export an obx and run it Altirra.

     

    21 hours ago, Wrathchild said:

    [Edit] Scratch this - of course it is the 'asm' i.e. code that runs on the A8.

    So that's quite neat then as the resulting executable code on the A8 is dependent on things that the RMT editor 'knows' about the tune.

    e.g. if it is using a 16 bit channel, if you are using a certain effect etc.

    if you aren't then the code isn't generated and so the runtime of the vblank time is overall quicker.

    Yes but I doubt RMT does any "on the fly switch toggling" and rebuilds the xex internally, it probably has all the flags enabled... (easy to check I guess... just output the simplest possible tune and check the xex )

     

    21 hours ago, Wrathchild said:

    Due to speed not being an issue on a PC's processor, I guess you have guess left all the flags in and set them from the header/defines output by RMT and all possible code paths in the asm equivalently available in the C# port?

    That's right I took the player source from the 1.28 release and left all the options enabled (except playSfx and stuff like that) but the code is all cleaned up now so there's none of that stuff left.


  6. 22 hours ago, _The Doctor__ said:

    somethings have to be different though yes?

    Of course...

     

    -The Pokey emulator of course. RMT uses ASAP(Pokey.dll) which was originally based on Atari800 and rewritten later. The same tune exported to an obx will sound different if played in Altirra.

     

    -LZSS simplifies the compressed data if the volume is zero, it seems to cause differences but it can be disabled in RMT2LZSS.

     

    -the way the values are sent to Pokey could potentially cause differences but I tried using the same method as RMT and it made no audible difference.

     

    The RMT player, C# or asm, should output exactly the same data however...


  7. 18 hours ago, VinsCool said:

    Command 6 (never really understood how that one really worked but it manipulates the filter frequencies I think) also dislikes being used with portamento, so that could be related.

    It doesn't seem to do a whole lot:

     

                   //  6    Add $XY value to FILTER_SHFRQ. (Whenever the new note in track is getting started, FILTER_SHFRQ is initialized to $01, so that default join filter generator frequency is higher by 1.)

     

    for each channel:

     When getting a new track line: [CH].FilterShiftFreq = 1;  (emkay asked me to be able to have a custom value, so you can change it in the instrument file )

     

    When updating 
                            [CH].FilterShiftFreq += [CH].envelope.commandArg;

     

     if HP filter is enabled

                    AudF[CH+2] = AudF[CH] + [CH].FilterShiftFreq;

     


    It's pretty simple though I don't know what kind of effect it has on sound

     

    • Like 1

  8. 21 hours ago, emkay said:

    Isn't it that simple?

    it's simple if you only understand half the problem 😏

    21 hours ago, emkay said:

    Let's say, if a game exists with the title and the music is running on the RMT Player.

    What would be the real problem to exchange the parts in the RAM?

     

    It's just: If the RMT Player cannot be "solved", why not changing the player completely? 

    Because the tracker editor interacts directly with the player, it puts your data (notes instruments,...) into the 6502 memory every time you press "play", then runs the 6502 player which in turn, decodes song lines/ patterns/ instruments and turns it into raw Pokey data.

    LZSS is just a decompressor for raw Pokey data...


  9. 23 hours ago, VinsCool said:

    It's crammed into channel 2 and every bit of available space :D I ended up doing some "chords" to simulate that part, which was better than leave the voice sustain a note and would have caused some dissonance (lovelylovelylovely .mod import at 15khz did this on the wrong key too lol)

    I played with the volume offset and I had to set the channels to -10 +15 -5 -10 so that I could hear it, obviously that totally messed up the balance😢

    • Sad 1

  10. 17 hours ago, VinsCool said:

    And finished!
    This was quite a ride I have to say, there was a lot of frustrating sound design.
    The RMT file is a mess, and it really was necessary in order to get things to work at all, the kick drums were especially challenging to get sounding good. :D 

    I do like it, honest! it's a very cool tune on its own but it's not quite like the original right? 

     

    It's missing that slow voice-like sound from the 3rd channel ( in the mod file ), no channel available on the A8 to add that one I guess ?

     

    That said it's another Pokey pusher 👍

     

    Just curious do you think it's possible to reduce it to 100hz without losing resolution on that 2nd channel (I tried it with RMT2LZSS and you can hear the difference)

    • Thanks 1

  11. 4 hours ago, emkay said:

    1st some special question. 

    Is it possible to just switch from RMT Player to LZSS player, to just exchange it in the assembler?

    Hell no... that wouldn't work at all.

     

    It's a lot more involved than that (I mentioned it in the Beyond RMT thread).

     

    Even if the RMT source code was available it would be a sizable job: basically it would involve removing the 6502 emulator and the 6502 asm player. Then include my C# version of the player (which would have to be converted to C++ first) and interface it with pokey.dll (which is actually Fox's ASAP).

     

    The source code not being available, it's an "impossible" task.

     

    The other closest alternative is to rewrite the editor around my C# player (and interface it with pokey.dll), that's a loooong and boring job...

     


  12. 16 hours ago, emkay said:

    Well, I'll try to fix the portamento with additional instruments, but a solution for a bug free portamento would be more than nice ;) 

     

    Well maybe but for that I'd need to understand the problem...

     

    1.Does the problem occur with the original tables ? From your example it seems that's not the case ?

    2.have you got a really simple example with a single channel? 

     

    Quote

    16 hours ago, emkay said:
    The problems still were the tremendous differences inside the RMT editor and the used emulation. So it is a very complicated task, to bring good results to the real thing. 

     

    Hopefully the "Convert again" and auto emulator launch help with that ?

     

    • Like 2

  13. 3 hours ago, VinsCool said:

    Okay so while I was making the Loading cover during some of my free time for the last few days (a surprisingly complex one to get working at all... I'll explain in my thread another time),  I decided to finally try using the custom instruments feature today... and I am not having a great time I must say 😱

    Ok stop punching, new version is up 😃

     

    • Thanks 1

  14. On 3/17/2021 at 3:23 AM, emkay said:

    This video fits somehow to your post ;)

    ouch, I'd forgotten about the ST version 😲

     

    3 hours ago, emkay said:

    People don't know what's going on. 

    Particular the first 35 seconds beat everything you find in the asma (remember that it is real programming of sounds)

    I have no idea what's going on but yeah those 35sec sound good!

     

    3 hours ago, emkay said:

    SID will not be able to replay it without complex software trickery (still will sound muffled). 

     

    I find SID to output pretty clear sound but don't know anything thechnical about it.

     


  15. 4 hours ago, VinsCool said:

    Nice new version rensoup!

    Finally found some time today to test it out a bit, 1.6 works pretty well!
    Automatic emulator launch works perfectly, even in WINE, "Convert Again" also works as expected.
    Looks like the VU Meter is still a little glitchy during the 240hz tune, but it's not as bad this time, playback also seems a bit more stable?

    Not sure if I'm imagining things, but it felt like it was stuttering last time I tried to run the tune, so that's a good improvement to me :D 

    Custom tables still seem to load like intended.
    I have not tried the custom instruments feature yet, but I'll make sure to report my results when I do :) 

     

     

    I didn't fix that VUmeter glitch 😀

    I should have been clearer in the release notes, I tried fixing the 16bit issue where I needed to drop the low frequency byte from being displayed, of course I have no idea if I dropped the right one! But if your tune uses 16bit it could be that it displays less bars now, so there would be enough CPU time.

    I probably never did any NTSC specific adjustments either, and I guess your tune would glitch at 200hz as well... who cares 🙂

     

    Please let me know about the custom instruments, then I can get started on the Envelope AUDCTL !

    • Thanks 1
×
×
  • Create New...