Page 1 of 1

Universal tracker

Posted: Fri Nov 10, 2017 11:57 am
by jede

If someone is interested :)

Re: Universal tracker

Posted: Fri Nov 10, 2017 12:18 pm
by ibisum
Looks pretty cool, sounds cool .. but I don't see anything specifically for the Oric in the release. Is there going to be a player for it, I guess, released on the Oric at some point?

Re: Universal tracker

Posted: Fri Nov 10, 2017 1:59 pm
by iss
Very nice indeed! I tested Windows and Linux versions.
It supports many input formats and exports them perfectly to YM.
Attached TAP/DSK versions of the same song from youtube video for Oric, using ym2mym+mym_player (of course) ;).
(43.07 KiB) Downloaded 153 times

Re: Universal tracker

Posted: Fri Nov 10, 2017 5:55 pm
by Dbug
Ideally, a native 6502 player would be nice to have: The mym format is not particularly compact, and the replayer itself is not specially fast either.
I wanted to port the Vortex tracker replayer... but that was when Twilighte was starting to fade away, kind of killed my motivation.

Re: Universal tracker

Posted: Thu Nov 16, 2017 11:07 pm
by Targhan
Hi all, this is Targhan/Arkos, the creator of Arkos Tracker.
As the tracker is still in alpha, I didn't want to spread the word about it too quickly, as I am already drowned in feature requests (and bug reports, yup :)) for the CPC users :).

DBug kindly notified about this thread. I don't code in 6502 so I won't code the players by myself. I *could*, but it wouldn't be as efficient as what an experienced coder would do.

However, I have already two Z80 players ready with each their own formats (all documented): AKY and Lightweight. AKY is a very very efficient format CPU wise, yet remains quite interesting memory-wise. It is some kind of clever register dump that use the full knowledge of the song to find patterns and encode only what is necessary. As an example, a complex song of 4-5 minutes, with very few repetitions is encoded in less than 17kb. So a more simpler song could be encoded in much much less.

So I think the AKY format would be the way to go, at first. The other players are more CPU consuming, and also more complex to adapt.

Anyway, don't hesitate to ask for anything you need, I'll try to do what I can :).

Re: Universal tracker

Posted: Fri Nov 17, 2017 9:30 am
by Chema
Hi Targhan!

Thanks for popping up here and for your fantastic tracker. I once had a look a Vortex too, as Dbug did, but never continued with the project. These trackers (yours looks incredible!) produce really good music, but I always found impossible to spend >10 K for the music and player only, and not counting the CPU usage.

However, if the outcome is so good and it is possible to keep memory and CPU usage somewhat lower, it will be a great tool for future productions!

I don't really have time now, but in a near future would love to have a look at an Oric player. Dbug also knows quite a lot about this topic, and could have something better than me. What do you think Dbug? It could be an interesting project!

Re: Universal tracker

Posted: Fri Nov 17, 2017 9:44 am
by Targhan
So 10kb is too much for an Oric production? What is the average for a music+player in your demos/games?

If only a few kb max, then AKY is indeed not for you. My Lightweight player would be more appropriate (less possibilities in the music (still better than Vortex), but lower memory footprint for both the player and music). It is however more complex to convert from Z80 to 6502.

What would be interesting would be that one of you convert any song from the Arkos Tracker 2 package (look at the .SKS songs) to Lightweight (you can use the command line tool SongToLightweight to compile the song) and see if the output of the binary is tiny enough for you. The Z80 player has a size going from #360 to a kb and a helf, according to the options. I can't do less! :).

Re: Universal tracker

Posted: Fri Nov 17, 2017 6:40 pm
by Dbug
The idea is to first check the memory size/cpu usage of the AKY format compared to MYM.
If it's better, it's a no brainer, they are conceptually identical, and replacing the less efficient by the more efficient is the way to go.

Then I can take a look at having the native player converted to 6502 :)