Replies: 5 comments 8 replies
-
|
Hi up to now TuxGuitar uses a proprietary binary format, which as far as I know is not documented. I think the java code you pointed to is the right one. I don't know what you want to do with tg files, but TuxGuitar can also export files under different formats (see application help). Some formats may be easier to use, but some information may be lost. Note: the question of tg file format is currently open. We will need to modify this format to integrate new features. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the quick response, Should i expect information loss with the MusicXML? I looked at the reference and it looks like everything is there, lyrics, bents hammer on / hammer off. About the "new" tg file format, do you already have some ideas? I wish you the best, with the updates. And I'll give the MusicXML a try, after update-ing to the latest snapshot :p Cheerz, Menno |
Beta Was this translation helpful? Give feedback.
-
It seems MusicXML export was developed quite a long time ago. I updated it very recently so that it's now compliant with last version of xml schema (4.0). But data export is still quite basic, so yes you shall definitely expect some significant information loss (typically lyrics, bends, hammer-on/pull-off...). That still needs to be improved. And thanks for the link about serialization. No idea currently of any solution for TuxGuitar (it's a bit early), but we will have a look at it. |
Beta Was this translation helpful? Give feedback.
-
|
Here is some rust code that uses a serialization framework: #[allow(non_camel_case_types)]
#[derive(Deserialize, Serialize, PartialEq, Debug)]
enum Software {
TuxGuitar_1_6_1,
TuxGuitar_1_2_1,
}
#[derive(Deserialize, Serialize, PartialEq, Debug)]
struct Encoding {
software: Software,
}
#[derive(Deserialize, Serialize, PartialEq, Debug)]
struct Creator {
#[serde(rename = "$text")]
creator: String,
#[serde(rename = "@type")]
composer: String, // should be enum?
}
#[derive(Deserialize, Serialize, PartialEq, Debug)]
struct Identification {
creator: Creator,
encoding: Encoding,
}
fn main() {
let ident = Identification {
creator: Creator {
creator: "John".to_string(),
composer: "composer".to_string(),
},
encoding: Encoding {
software: Software::TuxGuitar_1_6_1,
},
};
let xml: String = se::to_string(&ident).unwrap();
println!("{}", xml);
let mut file = File::create("output.xml").unwrap();
write!(file, "{}", xml);
println!("{}", serde_json::to_string(&ident).unwrap());
}Output: So the struct is kind of class. The derive is something like a python decorator. The underlying serialization framework is Afaik, Java also has the Serialization pattern. Not sure if this is usefull information, if not, ignore :p Menno |
Beta Was this translation helpful? Give feedback.
-
|
Evolution of file format is needed by several pending feature requests. So, let's re-open this discussion : what file format for next TuxGuitar release ? Just a few personal thoughts about this. Mandatory requirements
Nice-to-have requirement
Open points
Also, care shall be taken before introducing dependencies to external libs, and the maintenance costs it could create in the future (see vst, gervill, or even recent issues with SWT). We cannot afford a dependency issue for such a core feature. Considering this:
Documented suggestions are welcome. |
Beta Was this translation helpful? Give feedback.
-
|
i think if the format was going to change then make it future proof. so any syntax it doesn't understand is probably a new feature and it should just be skipped. like how css just drops any declarations it doesn't know and resumes parsing after the next statement terminator. we should write a feature list for including in the file format? do we have one somewhere? |
Beta Was this translation helpful? Give feedback.
-
It's not so obvious... E.g. if we design TuxGuitar version N so that it should be able to read files produced by version N+1 (discarding new data), it means that before releasing N+1 we must check that it works. And then, when version N+10 is released, we must check behavior of all versions N to N+9. This is why I'm not enthusiastic: we don't have any test infrastructure in place to do all these tests automatically. Manually? We will not be able to test everything.
By definition such a list would be unstable, considering possible new feature requests can arrive any time. I identified feature requests needing file format evolution end of April in this post |
Beta Was this translation helpful? Give feedback.
-
|
Without much experience in this environment, I'll try not to take too much of your time.
yes unit testing is painful and crashing should be avoided. I thought there might be an easier way.
yes but I was referring to a document describing the final file format that only gets updated when something changes the way files are created. feature requests would not be part of that until they are committed. thanks, great feedback i'll be of more help one day, soon as i get my head around it |
Beta Was this translation helpful? Give feedback.
-
|
So, finally I've gone for compressed xml: format is already used by TuxGuitar (.gpx, .musicxml) and it checks all choice criteria above. A first version without compression is available in my dev branch. Currently it's a plugin, only built in Linux/SWT version. It uses Automated testing is in place, and proved very useful to guarantee full compatibility. Thanks @profOnno for your suggestions in #303. Still todo, optimize file size: add compression, remove xml indentation (?) |
Beta Was this translation helpful? Give feedback.
-
|
Added compression, still in my dev branch |
Beta Was this translation helpful? Give feedback.
-
|
update, in new dev branch |
Beta Was this translation helpful? Give feedback.
-
|
Link is unavailable , 404. |
Beta Was this translation helpful? Give feedback.
-
|
It was merged into tuxguitar-next branch |
Beta Was this translation helpful? Give feedback.
-
Hello,
Just trying out TuxGuitar, and i like it.
I also like the Godot game development platform. So now i would like to use the tuxguitar file format directly. I was looking for some documentation on the file format but couldn't find it. Is there documentation on the tg file format?
Or should I follow the following locations, to figure it out from there?
https://github.com/helge17/tuxguitar/blob/master/common/TuxGuitar-lib/src/org/herac/tuxguitar/io/tg/TGSongReaderImpl.java
https://github.com/helge17/tuxguitar/blob/master/common/TuxGuitar-lib/src/org/herac/tuxguitar/io/tg/TGStream.java
Kind regards,
Menno
Beta Was this translation helpful? Give feedback.
All reactions