| |
Splunkh!
Registered: Apr 2021
Posts: 31 |
Android Goattracker compatible tracker
FakeSID is a FOSS Android chiptune tracker (inspired by LFT's Blackbird). The coder is now considering rewritting the whole thing, basing it on Goattracker! One very nice aspect of this is that Goattracker's .sng-files easily can be converted to SidWizard .swm-files (With Hermit's sng2swm-tool).
According to this thread on Github, the dude mentions he would need a little bit of help with some of the 6510-assembly bits. Anybody here who perhaps would like to point him towards the right direction? In that case leave a comment and more details can be added. Have a look at this thread: https://github.com/2bt/fakesid/issues/1#issuecomment-822011536
Personally I love the idea of punching in a few melodies or beats on my phone whilst being on the bus, and then move the fragments over to the breadbox when at home :) Also the gui on the previous/earlier android installment (FakeSID) is really sweet. Screenshots/apk are available at Github link above or at Play where it has gotten some pretty great ratings: https://play.google.com/store/apps/details?id=com.twobit.fakesid |
|
... 20 posts hidden. Click here to view all posts....
|
| |
DeMOSic
Registered: Aug 2021
Posts: 126 |
Quote: Compiling worked fine here on Linux.
Awesome tool. I'm glad you found it. I started writing a sid2sng tool myself a couple of weeks ago – but guess I can throw that to /dev/null now :-)
lol im a windows user so that means its a linux program? |
| |
spider-j
Registered: Oct 2004
Posts: 498 |
Quote: lol im a windows user so that means its a linux program?
It's a super simple C++ program. I guess it will run fine on Windows. But the add_compile_options params in CMakeList.txt look GCC specific to me. Maybe try building it with GCC from Cygwin on Windows instead of Visual Studio. |
| |
Splunkh!
Registered: Apr 2021
Posts: 31 |
Whohoo!!
All is now solved thanks to Spider Jerusalem & hedning in this thread sid2sng Windows builds
The CSDB entry and the compiled (Win x32/x64) binary is here: sid2sng 1.0
I tried it and it works wonders! But not every single Goat-SID works and sometimes you need to add some parameter to get an output .sng
usage: sid2sng [options...] sid-file [sng-file]
-nopulse
-nofilter
-noinstrvib
-fixedparams
-nowavedelay
I converted sng to swn and am now enjoying analyzing the Goat-SIDs in Sidwizard 1.8 on native C64! :) |
| |
DeMOSic
Registered: Aug 2021
Posts: 126 |
Quote: Whohoo!!
All is now solved thanks to Spider Jerusalem & hedning in this thread sid2sng Windows builds
The CSDB entry and the compiled (Win x32/x64) binary is here: sid2sng 1.0
I tried it and it works wonders! But not every single Goat-SID works and sometimes you need to add some parameter to get an output .sng
usage: sid2sng [options...] sid-file [sng-file]
-nopulse
-nofilter
-noinstrvib
-fixedparams
-nowavedelay
I converted sng to swn and am now enjoying analyzing the Goat-SIDs in Sidwizard 1.8 on native C64! :)
Awesome! |
| |
2bt
Registered: Jun 2021
Posts: 17 |
After a long silence, I finally found the drive to pick up the project again and have made good progress. The goal is an android app that is basically GoatTracker with a different GUI (and some limitations). The curious may check out the source at https://github.com/2bt/GTMobile. The project is not finished but almost usable and maybe close to a test release.
I would like to explain some differences to GoatTracker regarding tables because I could really benefit from feedback at this point. Maybe my idea is bad and that would be good to know.
Let's ignore the speed table for now. Each instrument is presented with its own three tables for wave, pulse, and filter. Under the hood, there are still the global tables but there won't be a way to see or edit the global tables directly. The user won't see jump commands but there's an implicit jump command at the bottom of every (local) table. You can select a table row and make it loop from there. Not being able to jump around is restrictive in theory but perhaps not so bad in practice.
The biggest consequence of not having global tables apply to table pointer commands. Since these commands reference rows in the global tables, this is a bit of a problem. One way to avoid the problem is to just not support table pointer commands. That's not acceptable.
I have another idea. I will change table pointer commands so that they don't reference rows of the global tables, but instead reference INSTRUMENTS, which in turn reference table rows. This means, whenever you want to use a new table pointer command, you first set up an instrument. Setting up such instruments happens automatically during song loading for songs that don't have these instruments set up already. When a song is saved, instrument numbers get converted back to table rows. There is a chance of running out of instrument slots but that might not be a big problem in practice.
So yea, that's the situation right now. The approach seems a but sluggish but maybe that's ok. And perhaps some of you have been able to make sense of this text and have opinion to share, thx. |
| |
Jetboy
Registered: Jul 2006
Posts: 337 |
Why not.making it compatible? What is the point of doing crippled solution? |
| |
RS-232
Registered: Oct 2024
Posts: 2 |
I think as long as the files generated are still loadable in GT2 it should be fine.
Is the reason for not using the global tables due to screen real estate on the android, or some other reason? |
| |
spider-j
Registered: Oct 2004
Posts: 498 |
Quoting JetboyWhy not.making it compatible? What is the point of doing crippled solution?
It's not that far fetched. NinjaTracker uses the same method and if you prepare your tunes in GoatTracker and throw them on gt2nt pattern fx will converted in that way automagically.
I wouldn't be surprised if the GT2 routine did the same or something similar when exporting to PRG / SID, depending on what features were used. Cadaver has a lot of stuff heavily optimized to save RAM and rastertime. |
| |
2bt
Registered: Jun 2021
Posts: 17 |
I initially had global tables in the app but found working with it cumbersome. There isn't a lot of space on a phone screen as RS-232 pointed out. But I also wanted to make the app a bit more intuitive than the original tracker, which might help new users not familiar with it.
A global table has practical advantages. All addresses, including start addresses, can be stored as a single byte. Instruments can share table data with the goal of minimizing memory usage. This happens when two instruments have the same initial table position. The android app supports this. But data could in theory be shared more creatively. For example, instrument A may execute a few initial rows after jumping right into the local table of instrument B. With only local tables shown in the app, you won't be able to do this kind of data sharing. Having looked at a bunch of songs in the wild, I can tell you that this is not very common. Instead, what's common is that wait commands in wave tables are underutilized and space could be saved but isn't. So the app's limitations in this regard should not a big loss. |
| |
2bt
Registered: Jun 2021
Posts: 17 |
I managed to build a web version which you can try out in the browser (on a PC).
https://2bt.github.io/gtmobile/index.html
Not as responsive as the real android app and no way file import/export. But I think it's fine for the purpose of getting some initial feedback regarding UI. Please try it out and let me know what you think. And tell all your friends about it. Constructive feedback will help make the final app better. |
| Previous - 1 | 2 | 3 - Next |
