Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Save file format question #1

Open
MartyLake opened this issue Nov 6, 2019 · 15 comments
Open

Save file format question #1

MartyLake opened this issue Nov 6, 2019 · 15 comments

Comments

@MartyLake
Copy link

🙋 Hey, absolute tracker beginner here :)

Is the SNG format "compatible /convertible" to the MOD one or any of the format that can be used by https://github.com/JarkkoPFC/arduino-music-player
?
thanks you in advance for your answer!

@2bt
Copy link
Owner

2bt commented Dec 1, 2020

Hi Marty, sorry for the late reply! Fake SID's song files are not easily convertible to MOD, unfortunately. An even better way would be to export SID files – I believe SID files can be played on Arduino directly. Alas, I haven't figured out how to export to SID, yet.

@Mangleuz
Copy link

I used to make songs on the good ol' breadbox and I must say that your app looks FANTASTIC.

Yes, sid to mod would be too much of a stretch. But i am glad to read what you say about sid format @2bt !!

The moment i hear that Fake sid will support some form of conversion making songs playable on c64 I am going to throw myself into learning to use the app in depth. (I do not want to risk putting in the hours needed and then perhaps be locked out of c64-heaven). If it is very tough to make a converter in the app, would it perhaps be less diffficult to make a FS --> native c64 song converter for the commandline?

It would be awesome if any of the many helpful oldschoolers from the scene could give you a hand if there is some tricky c64-specific problems in your way. I really wish i could help.

At any rate, having looked at your app, it for sure really is awesome, and has good documentation too. I hope many people that have not yet discovered the app (yet) will find it. Perhaps an included demo song would be a good way for people to get a chance to see it in action right after install.

(I btw also find Linus Åkessons blackbird awesome! and SidTracker64 for ios is also pretty cool. But on android Fake Sid is surely the way ahead).

@2bt
Copy link
Owner

2bt commented Apr 18, 2021

My vision for the app is to remove some of the "fakeness" and to switch to resid for the SID emulation. I will also need to write a player for the 6510. I am a 6510 assembly noob so it will not be amazing.

Some modifications to the song format will also be necessary. Unfortunately, this will break backwards compatibility. I think it will be possible to convert songs to the new format but there will be artifacts in some cases.

@Mangleuz
Copy link

Mangleuz commented Apr 18, 2021

This was the best news i could have imagined. My comment on this:
"Remove some of the "fakeness"" --> by sacrificing (much or all) backwards compatibility = absolutely TOTALLY worth it. It adds good reasons to suspect that your tool will become popular and widely used in the greater community.

Something that might add to this further, and at the same time address the 6510 issue:
The two best open-source resources on native c64 is in my opinion SidWizard and (the less famous but insanely brilliant) Virituoso by Hein Holt. The amount of formats of import and export that SidWizard + its tools, can handle is shocking (Goattracker .sng is perhaps most interesting). If you would build the player on an existing open source native/6510 basis, 'as-standard-as-possible'-player, these, together with some old school-guidance might show the way.

Yay, Resid! Just like GoatTracker + converter tools (that can export .sng to native ninjatracker) and the amazing evolving Sid Factory II (+ converter tools, for GT .sng & CheeseCutter .ct). FOSS projects like this promotes some degree of platform traffic between native c64/emulators and modern tech. Its possible to stand on the shoulder of giants without reinventing the wheel it seems :) Personally i have nothing at all against external export desktop-tools, imagining export functions of various kinds might be tricky to build into an APK version.

I think I'll tomorrow (on my own initiative) add a thread to the CSDB forum, bringing some awareness to this github page. Perhaps someone is interested in adding a few concrete suggestions on the 6510/assembly topic which I myself can not be of any help with.

My old C64 breadbox is back plus I got a Ultimate64 so I can do some testing of your stuff on this hardware if that would be of any help.

@2bt
Copy link
Owner

2bt commented Apr 19, 2021

At the time when I conceived Fakesid, the idea of being able to export songs to sid seemed far fetched. I aimed a bit too low I guess.

When I came across Blackbird, I was intrigued by the way pitch is handled (https://www.linusakesson.net/programming/9bitpitch/index.php). The simplicity of the tracker – the way instruments and effects work – it appealed to me. Fakesid's interface is quite similar, but there are differences which make it a bit easier to use but also break compatibility with Blackbird's player and song format. It's also a lot different from GoatTracker and CheeseCutter.

I guess one possible way forward would be to abandon this strategy entirely and basically build a new front end for GoatTracker, perhaps less powerful but more convenient and easier to use. That would actually be pretty cool, but also a lot of work. There are a bunch of features in GoatTracker that I might not want to support, because I feel like they will make the GUI very difficult to use (and implement), but I might be wrong. For example, tracks can have independent speed and differ in length. Blackbird (and CheeseCutter I guess) are a bit simpler in that regard.

Songs could be stored in GoatTracker's sng format and conversion to sid could be handled externally or by reusing code from GoatTracker.

I am also wondering how if there would be copyright issues. I never had to deal with licenses up until now.

So, there are a lot of questions and I would be delighted about more input from others!

@drfiemost
Copy link

GoatTracker's playroutine is free for any use:

NOTE: This playroutine source code does not fall under the GPL license!
Use it, or song binaries created from it freely for any purpose, commercial
or noncommercial.

It needs Exomizer to be assembled.

You might hit @cadaver for questions, he surely knows better.

@2bt
Copy link
Owner

2bt commented Apr 27, 2021

That's nice to know! On the other hand, the play routine as used inside GoatTracker is actually C code. I believe this is different from CheeseCutter where the 6510 is emulated to run a play routine of your choosing.

I like having the play routine in C/C++ inside the tracker. When converting to SID/PRG, however, the play routine needs to be reimplemented in 6510 assembly. I never got around to doing that for Fake SID's play routine.

The tough decision now is: should I try to implement the current routine in assembly, or rather abandon the current play routine (and with it almost everything else that makes up the tracker) and embrace GoatTracker with its routine as well as SND file format?

The latter option would mean redesigning almost everything about the GUI. Conversion could just be delegated to external programs (i.e., no need to write assembly etc). I am also a little afraid that the user interface will become overwhelming and clumsy to use. I guess I would start out with supporting only a sane, reasonable subset of what GoatTracker can do.

@drfiemost
Copy link

That's nice to know! On the other hand, the play routine as used inside GoatTracker is actually C code. I believe this is different from CheeseCutter where the 6510 is emulated to run a play routine of your choosing.

The C code is used for playing realtime, when exported to sid format the data is packed into an assembly routine:

https://sourceforge.net/p/goattracker2/code/HEAD/tree/goattrk2/trunk/src/player.s

@2bt
Copy link
Owner

2bt commented Apr 30, 2021

Thanks. I have studied the GoatTracker source code a bit and I have kind of an idea how the new tracker could look like. That vision in mind, I will not use the GoatTracker SNG format directly but provide functionality to export (and possibly import) to GoatTracker SNG. This will force me somewhat to stay within the GoatTracker capabilities but allows for certain differences as well. One difference I have in mind is to remove the speed table and instead to have kind of a command table.

@Mangleuz
Copy link

Mangleuz commented May 9, 2021

This page contains the best news on the Internet ;)

Exporting to goattrackish SNG is awesome. I would not miss speed table a bit.

Just asking out of curiosity, did perhaps the thought of exporting to SidWizards .swm ever come to mind?

When some early alpha is available i am happy (or more like overjoyed) to do testing if that would be useful.
Good luck with it all!

@demesos
Copy link

demesos commented May 21, 2021

That's nice to know! On the other hand, the play routine as used inside GoatTracker is actually C code. I believe this is different from CheeseCutter where the 6510 is emulated to run a play routine of your choosing.

I like having the play routine in C/C++ inside the tracker. When converting to SID/PRG, however, the play routine needs to be reimplemented in 6510 assembly. I never got around to doing that for Fake SID's play routine.

The tough decision now is: should I try to implement the current routine in assembly, or rather abandon the current play routine (and with it almost everything else that makes up the tracker) and embrace GoatTracker with its routine as well as SND file format?

The latter option would mean redesigning almost everything about the GUI. Conversion could just be delegated to external programs (i.e., no need to write assembly etc). I am also a little afraid that the user interface will become overwhelming and clumsy to use. I guess I would start out with supporting only a sane, reasonable subset of what GoatTracker can do.

At least from my perspective, I would embrace the possibility to work on tunes on the mobile, but when it comes to exporting it to a C64 player routine, I would have no problem doing this on a PC via goattracker. So I think, being able to listen into the song and saving/opening it as goattracker .SNG would be very fine.

@Mangleuz
Copy link

Mangleuz commented May 22, 2021

I completely agree with @demesos I do not at all mind doing the export on PC through Goattracker. Or as in my own preferred case, use the .SNG through a C64/U64 with hermit's sng-to-swm tool + Sidwizard and later turn the song into a .sid or .prg file for playback.

@2bt in this thread mentions export, but possibly also -import- to Fakesid. I think such reciprocal approach would be fantastic and also give the app a lot of momentum. Not only that the user, back and forth, can write songs "on the go" and also on PC/64, but also that all the sng's that are already created can be imported and studied as brilliant examples from within the android app. This was probably one of the factors of greatness with Sidwizard (through sng-to-swm) due to the many imported goat-songs which educated people further in how to make sophisticated songs.

On another note there was today a new version of Exomizer released. (@drfiemost earlier mentioned it above, in relation to the GT playroutine). Almost half a year has past since the previous version of exomizer.

@2bt
Copy link
Owner

2bt commented May 25, 2021

Thank you all for the feedback, this is very helpful. Let me share with you some more of my thoughts.

I wanted to get a better understanding of which features in GoatTracker would be most essential and which features are rarely used. I was curious how typical SNG files look like and see what's typical and what effects are less common. So I wrote a tool to convert SID files back to SNG. Having looked at a few files, I think I have a better idea now.

Case in point is the song order list which allows for lots of flexibility like repeating patterns and transposition, all independent for each channel. That is useful if you care a lot for space efficiency but I would like to forego this and instead just have a simple table not unlike how Fakesid currently does it. As it turns out, all the files I looked at have a very regular structure where simultaneously playing patterns always have the same length. That's perfect.

So, I do not want to support everything that GoatTracker can do, for example all the song order list stuff or the channel tempo command. That's why some SNG files will cause issues when importing but in such a case I should be able to print out a warning/error describing the issue.

@Mangleuz
Copy link

Mangleuz commented Jun 2, 2021

For the ones of you who posted here and might not know that this topic also has an interesting life at CSDB I share this link:
https://csdb.dk/forums/?roomid=7&topicid=148941

The SID to GoatTracker .sng conversion tool at https://github.com/2bt/sid2sng is really interesting!

@Disonantemus
Copy link

Disonantemus commented Apr 20, 2024

I also would like this.
Maybe this was not easy, but having a music tracker using a format compatible for Android and Linux (GoatTracker) is useful to continue mobile ideas in desktop.
Or at least some kind of conversion with a CLI tool that can do "FakeSID" and export to "GoatTracker" (or SID, Deflemask, Furnace, etc) or any other more common format.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants