Jump to content
VinsCool

[WIP] VUPlayer (for use with RMT exports)

Recommended Posts

Since this became offtopic, I made a new thread, for this little side project alone :D 

 

So now I got some new visuals (still not all finalised), and more responsive visuals, here, play/pause in action.

Sources: https://github.com/VinsCool/RMT-Patch16/blob/main/dasmplayer.asm

 

  • Like 14

Share this post


Link to post
Share on other sites
1 minute ago, Beeblebrox said:

Cool. Now all we need is GUI mouse control so you can click on the play, stop, pause, etc etc icons. 😉

I wanted to do something like that using playermissile graphics for a cursor!

Or also use the keyboard for faster controls, haha

  • Like 1

Share this post


Link to post
Share on other sites
Just now, Kjmann said:

are you going to integrate this into RMT for the exports? 

Absolutely

  • Like 4

Share this post


Link to post
Share on other sites

Fully functional menu navigation, note that only Play/Pause, Stop and Eject have code, everything else is currently ignored.
Literally my first time ever making some interactive UI code, I think I did a okay job :D 

 

  • Like 5

Share this post


Link to post
Share on other sites

Hey it's been a while!

Since I don't want to make the RMT release thread go offtopic, I'll just post this one here, lol

 

 

I'm having a bit too much fun in the 6502 Assembly code, fucking around with my VUPlayer with the LZSS driver hack I'm working on.

 

So yeah, Subtune support has been added tonight!

All tunes are indexed LZ16 streams which are loaded using the associated pointers, and voilà!

The Seek buttons are fully functional too, and so are the FF and RW buttons, although I used them to set the playback speed :D 

Everything works very well so far, rensoupp's runrolled LZSS driver has survived my patches, and my VUPlayer is becoming less crap and more fun to use! lol

 

Here's the binary, region is intended for PAL but it will work perfectly fine in NTSC too ;) 

VUPlayer + POP Bank2 LZSS.xex

 

When I'm done properly porting my XASM code to MADS I will make a stand alone repository with this LZSS version of my VUPlayer.

I changed a lot of things in the code after I took away most of the RMT parts in favour of the patched LZSS driver.

I've also adapted the POKEY writes timing to match RMT's, so things will sound virtually identical.

  • Like 6
  • Thanks 1

Share this post


Link to post
Share on other sites

- Ported the VUPlayer code to MADS, allowing a much more tight bond with the LZSS driver
- Looping support added, press the L key to toggle!

- Fixed out of bounds index between subtunes, using a dummy subtune at the end of the index, should be proper with and without loop enabled

- Seeking subtunes left or right will ignore the loop flag, allowing subtunes to always play properly from the start to the loop point

 

Yes, flexible subtunes index, and perfectly seamless, and optional looping! All from using the LZSS data and driver.

Are you sure you want to try proving me wrong again?! 🤪 

I know ivop will understand the reference, you know I am just kidding! 

 

VUPlayer + Few MM2 Tunes LZSS.xex

 

Look for subtune 7 and 8 specificlly, they do have full looping functional, the other ones were set to a dummy index for now since I literally just added the feature...

Also no video this time since I just realised it's like 5:40 AM so that can wait their turn later lol

I will add better navigation later too, the Left(+) and Right(*) keys are awkward to use on an emulator setup, compared to the real thing...

  • Like 5
  • Thanks 1

Share this post


Link to post
Share on other sites

Very nice player!

 

With Altirra emulator, joystick is mapped on arrow keys.

To move cursor up/down/left/right on Basic editor I use ALT+arrow keys.

But with the player it doesn't work.

I have to press + and * keys that on my Swiss keyboard are SHIFT + 1 and SHIFT + 3.

Would it possible to enable ALT+arrow keys like Basic?

  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)

forgive me for possibly hijacking the thread but can I ask is there a decent current music scene for Atari 8-bit ? The thread mentions RMT exports - is that a regular thing?

 

Aside from Poeut for Demos I tend to use DemoZoo for Music prods (- for Amiga at least - as it seems to be better oriented for that than Poeut. Checking today I found 23 Atari 8-bit Music prods for 2021 - not bad - but only 1 so far for 2022. Is there somewhere I'm missing for current 'RMT exports' or other current POKEY music stuff maybe ?

Edited by andyhants

Share this post


Link to post
Share on other sites

Hello andyhants

 

4 hours ago, andyhants said:

forgive me for possibly hijacking the thread but can I ask is there a decent current music scene for Atari 8-bit ? The thread mentions RMT exports - is that a regular thing?

 

Why not open a new thread?

 

Sincerely

 

Mathy

 

Share this post


Link to post
Share on other sites
Posted (edited)

Here's the complete Mega Man 2 conversion, compressed to LZSS, played back using a much better VUPlayer version this time!

 

 

I never want to hear a single person telling me "subtunes", "looping" or "fading out" is impossible using a LZSS driver.
So yes, there was a lot of memory that could be to saved, I was RIGHT!

VUPlayer + Mega Man 2 POKEYfied LZSS.xex
XEX size (including the LZSS subtunes, the driver itself, and the VUPlayer data): 33.2 kB (33,185 bytes).
Not bad, eh? :D 

 

I'll post the new VUPlayer sources + modified LZSS driver later today once I get some cleanup in the code (lots of comments and jank from testing every bits pretty much).

 

Notable improvements so far:

- Much improved subtunes indexing method, very easy to organise, and very easy to actually use!

- Fixed looping detection, infinite loop flag can be toggled with the L key like before

- Fadeout! Any tune with a 'loop' point will loop once, then fadeout on the second play, if the tune is shorter than the fadeout timer, it will simply loop infinitely until the volume fade is done

- Dummy subtune detection. Allows tunes that have a definite 'end' to immediately go to the next one, or if used as the 'intro' tune, it will only be 1 frame long, virtually invisible on a new subtune

- Some debug data, mainly, current LZSS player position, as well as the Song Start and Song End pointers addresses.

- Fixed many bugs related to play/pause/stop flags and looping/fadeing out, now the entire player actually feels like a real music player!

- Added more keys for input: 1-2 for Seek Back/Seek Next, 3-4 for Playback speed modifyier, A-D for Left and Right, P for Play/Pause, and O for Stop

- Allows the Music Player buttons navigation to wrap around, so now you can go from 'Seek Back' to 'Eject' and Vice Versa

- Added a Rasterbar colour change between subtunes, because of course I had to do it as well lol

 

Also this binary is intended to run on a NTSC setup but it will work in PAL just fine too.

Edited by VinsCool
Linked the video
  • Like 5

Share this post


Link to post
Share on other sites
Posted (edited)

I did not have as much time as I expected today, so I did not finish cleaning up/re-organising the code/data I was editing.

I did find a few more bugs related to indexing, and found a better way to get dummy tunes to be skipped entirely now, leaving the illusion of perfectly balanced looping and/or intro sections being played in their respective indexes.

This should also have fixed the subtunes wraparound jumps for good, hopefully.

Also found another dumb bug related to the stop command... another instance of doing certain actions in the wrong order, causing the play/loop count flag to be incorrectly reset, but this should be fine now.

 

LZSSPLAY backup april 23rd.zip

 

Messy .zip aside, there are plenty of .lzss conversions I had generated from the currently not released future RMT 1.33 with its own LZSS XEX exporter, that's precisely why I am trying to organise the index in such a way, to make it easier to edit in batches!

indexing tunes should be simple enough, also put in the DUMMY when a subtune intro or loop is not needed, in order to save as much space as possible in every tunes converted.

once the player is assembled using MADS -c lzssp.asm, all the indexed tunes should work as expected, automatically, for loop, and fade.

Press L during play for setting the actual player Loop flag, if desired.

I cannot guarantee everything will work, but I have been tracking down bugs 1 by 1, since I was the cause of most of them, obviously I must find what I did wrong lol

 

 

Anyway, enjoy!

I want to ideally try to separate the VUPlayer part a bit more cleanly so then the driver could be its own thing while also keeping the benefits I have added, such as the alternative subtunes indexing, looping support, volume fadeout, etc.

These experimental features may hopefully become something that could be very useful in more projects like demos, or games :) 

I really originally did them for the player's own use, and maybe prove a point or two, but now I do believe there is many things left that could be done now.

 

[edit] once I get a chance to properly clean up everything I did, I will make a Github repository for the VUPlayer and the LZSS driver I modified for the things I wanted to do with it.

Edited by VinsCool
forgot some details
  • Like 7

Share this post


Link to post
Share on other sites

Brrr, inline uploaded videos on AA really hog my browser (latest Firefox).

 

Anyway, nice work! :thumbsup: :)

 

I could not make out if you do per pattern compression (AUDC/AUDF) or still full stream?

 

Per pattern compression could be problematic. I thought of an edge case. If you play patterns 1, 3, 2, 3, pattern three is not necessarily exactly the same. If either pattern 1 or 2 leaves a note playing when it enters pattern 3, and it's a different note, or no note at all, pattern 3 is not the same.

 

  • Thanks 1

Share this post


Link to post
Share on other sites
6 hours ago, ivop said:

Anyway, nice work! :thumbsup: :)

Thank you!

6 hours ago, ivop said:

I could not make out if you do per pattern compression (AUDC/AUDF) or still full stream?

Right now this is still full stream compression, what I did do however was splitting the streams into "sections" of songs to play, which is not that much savings, but still enough to cut out a lot of repetitions, and ultimately allow songs to fully loop too, without any extra data involved.

Pushing this concept into per pattern size could definitely work, however. I simply did not yet attempt this one, since I mainly focused on subtunes playback for now.

6 hours ago, ivop said:

Per pattern compression could be problematic. I thought of an edge case. If you play patterns 1, 3, 2, 3, pattern three is not necessarily exactly the same. If either pattern 1 or 2 leaves a note playing when it enters pattern 3, and it's a different note, or no note at all, pattern 3 is not the same.

I agree, this definitely will be a bit tricky to do.

Most of the same could be taken from how looping is achieved, too, to creatively work around that.

 

The only issue remaining is the indexing itself.

The way I tweaked it was from taking the SongStart pointers when called, and take the pointers immediately after for the SongEnd pointers.

That definitely does work, but it must then be adjacent data always.

 

This is pretty much the only issue left, even if it probably won't hurt much, it does make a difference in case the idea was to load pointers from existing data in a different spot.

In this case, the original method for indexing would be required, which by itself would require twice as many bytes since the index for SongStart would also need a SongEnd equivalent, which is also including the LoopStart/End addition that would also have to be done there as well 😨

This is not technically more difficult to do, but yeah, 2x more pointers to work with, in this case.

 

I had the idea of attempting "pattern" format in a very loose way at the moment:

 

1- Use the same code for dumping SAP-R like before

2- Dump from any location, like the song start, and initialise a secondary counter that will keep track of how long a pattern is

3- Now dump data just like it was done before, and leave the pattern size counter do its thing while the code keeping track of looping also does its own

4- Once a dump completed, simply splice every pattern using the size counter at every interval of pattern size, giving an outout of as many songlines there are

5- Convert all the individual patterns to LZSS

 

And from there, what would be needed is a way to properly identify which patterns are identical when re-used so they can be taken away from the index construction, and replaced by a reference to the identical pattern instead.

I know it can be done, it will simply become trickier to do 😅

 

I was going to work a bit more on this tonight so I can properly clean up my code and all the stuff I screwed around with, so that will be the priority before I attempt a per pattern format and code that dump method into RMT once that is possible...

I really want to not let down programmers using RMT this time, so I will do my best to allow those kind of things and easily use the data generated for the music driver :) 

  • Like 1

Share this post


Link to post
Share on other sites
15 hours ago, VinsCool said:

what would be needed is a way to properly identify which patterns are identical when re-used so they can be taken away from the index construction

There. That's the solution. Comparing all the dumps of the same pattern is trivial :) Good luck!

 

  • Thanks 1

Share this post


Link to post
Share on other sites
26 minutes ago, ivop said:

There. That's the solution. Comparing all the dumps of the same pattern is trivial :) Good luck!

 

Thank you!

It's just a matter of time until this idea comes into being, I am not worried I will be able to make it happen :) 

 

In the meantime, I still haven't fully cleaned up all my edited code but made a considerable amount of progress last night.

I fixed a handful of tiny bugs here and there, solidified the subroutines I added and/or modified, optimised several things to a much better version of itself, and re-organised most of the code I was doing with VUPlayer.

It's not enough to be as good as I like, but it is getting a little better now.

 

At the moment I am still about to cleanup and fix issues I may notice in the process, and then I will find a way to cleanly split some of the VUPlayer features I made up to become native driver subroutines that could then be incorporated into projects that could make use of the driver sometime in the future :D 

I'm pretty happy of where it is going right now.

I can say with much confidence that Subtunes, Intro/Loop indexing, Fadeout, Play/Pause/Stop, can all become their own thing with a bit more work.

The only thing left would be to call the driver subroutines at the developer's discretion.

 

I will make sure to document as much as I could within the VUPlayer so this could then be used differently when it would be needed :) 

Anyway, since I did not yet post anything, I will simply post my most recent progress up to this post, and try to squeeze more time today to finish what I am doing.

Right now I am extremely satisfied of what the Player+Driver combo can do :P 

LZSSPLAY backup april 24th 2022-3.zip

A lot has been done, and a lot is left to finish, but it's really taking shape, and it's so satisfying, because I know there are way more possibilities that can be exploited at a future time.

  • Like 3

Share this post


Link to post
Share on other sites

There is a lot to cleanup still, before I can get a full separation between the VUPlayer and the Driver features I am trying to add, but this is some progress, now I think is in a good enough shape to share on Github 
https://github.com/VinsCool/VUPlayer-LZSS 

Note: this is still work in progress. 

  • Like 2

Share this post


Link to post
Share on other sites

In the meantime the next RMT version is still getting the final touches for a new release, I've updated VUPlayer and added some interesting new features :)

 

https://github.com/VinsCool/VUPlayer-LZSS/commit/1c902ac545672684aaf6765714d2fcfd4b260fb5


- Version bumped for the upcoming RMT release
- Stereo support through a flag, exports run the exact same code regardless of the parameter
- Two-Tone Filter through Volume Only bit, $Fx reserved for Volume Only Proper
- Bug fix for graphics display list related to VSCROL buffer
- Re-organised a bunch of code around
- Quick and dirty SAP initialisation patch added for RMT exports
- Few misc changes here and there for optimisations and fixes if that applies

 

So yes, you read this right: Stereo and Two-Tone are part of the game now, and despite being both kind of hacked up, they are fully compatible as far as I could tell

Of course, subtune indexing, seeking and the other functionalities are still present.

Currently, RMT exports won't allow exporting separate subtunes or even modules in batch, but that will be for another time... ;) 

A complete tune playback+loop is what will be offered, however, and optionally, the VUPlayer driver can be patched to run as a SAP Type B file, if desired. 

 

This version will be bundled with RMT 1.34, otherwise.

If any of the code I added/edited could be useful for a project, feel free to borrow from the repository :D 

  • Like 9

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...