We’ve already seen utilities that have reverse engineered the .pti format, but this was based on trial and error, blood, sweat and tears (shoutout to Jaap Roes for his work on that).
This is a formal request to Polyend, to create a living document that details these files so that community developers could create utilities for the Tracker and / or converters so that Tracker Files could be used in or with other Software Trackers and Tools.
What is the problem?
As of FW 1.7 there is no more importing or exporting to a common file format
There is no official documentation / specification to the Trackers Project / Song / Pattern / Instrument Files
What do you want to achieve?
Allow the community and 3rd party developers to create tools that would benefit the Tracker Ecosystem
Allow the community to create Conversion/Helper Utilties for interoperability with other popular tracker formats or with other tools.
To do this, it would be helpful if we knew the specs/structure/content of the following files:
project.mt - The Project File
pattern.mtp - The pattern files
instrument.pti - The instrument files
Or a changing the file formats to a more open/accessible format (see Any references to other products).
Microsoft Office documents have been open for a while now
Possibly the Deluge? This wish is not about opensourcing the firmware though. This is purely about opening up or documenting the files that make up a tracker project so developers could build tools for them or around them.
I’m not entirely sure, i’ve done some testing and it seemed to work. But you are right, eventually this will become an issue, the further along we go with the updates.
I personally would love if Polyend would open up the Fileformats for the Projectfiles (Song, Pattern, Instrument) so that Devs in this community could actually build tools for the Tracker to enrich the ecosystem.
This could include importers/exporters to the now infamous .mod and .it files, but go even further with support for maybe Renoise or even other software.
It would be a benefit for the community and a benefit for Polyend, since their Team could focus on other tasks, while the community can geek out and build all sorts of funky tools.
Releasing the file format specifications certainly would allow the community to create just about any conversion utility imaginable and move the tracker onto a new level of interoperability with other gear and software.
It would however, hinder Polyend in adding or removing sections and fields in these currently undocumented files to expand the tracker’s capabilities in the future and it might involve more work than they might be willing to invest into this request.
I do think, that I can propose a solution to this. Should all three file types have a built-in version indicator, it would be possible for Polyend to create a GitHub repository with just the C/C++ data structures of the three file formats in question and update these on every major release, including the version identifier in each file format. This would allow them to make arbitrary changes and external tools could include compatibility layers for every version change. Releasing the commented data structures would also be a lot less work for Polyend than creating extensive specification documents and would allow for rapid changes. Releasing these files would also not have any negative impact on Polyend and would not disclose any sensitive or internal information.
In this way both Polyend and the community would greatly benefit from this.
Ich habe weder Programmierkenntnisse ect. oder Ahnung von Python & Co. aber vielleicht findet jemand ja auch mit dem kostenlosen Tracker für Windows “OpenMPT” irgend eine Lösung und Möglichkeit die klassischen .mod Dateien für den Polyend Tracker zu konvertieren?! …zumindest kann man in “OpenMPT” auch sehr viele Einstellungen für sämtliche Parameter einer (.mod Datei) sowie den Instrumenten und Samples ändern und anpassen damit dieser dann irgendwie kompatibel und eventuell mit weniger oder sogar ohne Fehler durch Konvertierung für den Polyend Tracker lesbar und abspielbar ist. ich habe mir den Polyend Tracker eigentlich auch gekauft um meine alten Amiga.mod Songs laden und bearbeiten zu können! …und dann wird man enttäuscht nach dem Update auf Firmware 1.7.1 und zurück auf 1.6 möchte ich auch nicht wirklich da ja 1.7 trotzdem viele neue Funktionen, sinnvolle Verbesserungen und Fehlerbehebung enthalten sind!
I don’t have any programming skills ect. or know about Python & Co. but maybe someone will find some solution and possibility to convert the classic .mod files for the Polyend Tracker with the free tracker for Windows “OpenMPT”?! ".at least in "OpenMPT you can also set a lot of settings for all parameters a (. Mod file) as well as the instruments and samples so that it is somehow compatible and possibly readable and playable with less or even no errors through conversion for the Polyend Tracker. I actually bought the Polyend Tracker to be able to load and edit my old Amiga.mod songs! … and then you will be disappointed after the update to firmware 1.7.1 and back to 1.6 I don’t really want to because yes 1.7 still contains many new features, useful business and bug fixes
Yes, this would be highly appreciated. I just got my first tracker and was actually disappointed, not by the device itself, which is great, but by the missing support for .mod files. Of course, I tried to reengineer the mt, mtp and pti files right away. But this is a long, winding and errorprone road to walk.
Opensourcing the Firmware or parts of it (e.g. Fileformats) does not mean loosing control or ownership. I mean Apples source is mostly Opensource. And they are by far not the community friendly company they like to make us believe they are.
On the contrary, you could actually use the power of the community to drive the product forward but still stay in control by leading the process.
I’ve updated the description for this wish to reflect the recent changes - as in the return of import/export for the Tracker Mini. I will update this again, once it has returned for the OG Tracker as well.
Regardless…
this won’t change my mind and i won’t withdraw this request.
Because i still firmly believe that allowing community developers to build tools that can read/write song, pattern and instrument files would be a beneficial boon for the overall ecosystem.
Also it would open the doors to making applications like this one (for the digi, sold mine to get the play lol) crunch/elk-herd](crunch/elk-herd) which is open sourced also and allows the users to manage their devices through a comfy website