[ RE:Tracker -- RE:Write ]

Tracker
1

A Call for Openness - The Future of the Tracker OG is in Your Hands

Dear Polyend team,

This is not a complaint made in haste. It’s a considered request, made with full awareness of what your company has built, and what it could still become.

I am a long-time user of the Polyend Tracker OG. My unit shipped with firmware 1.8.0, and over time, I’ve come to appreciate the hardware’s quality, the design sensibility, and the potential that still resides in this device. But with that appreciation comes growing frustration — not driven by emotion, but by patterns that can no longer be ignored.

As it stands today:

  • The Tracker OG is still available for purchase as new, yet lacks any consistent roadmap or communication.
  • Bugfixes have stagnated, with some bugs dating back to version 1.8.0 — or perhaps earlier, though it’s impossible to verify because there is no official archive of previous firmware versions.
  • The changelogs don’t include release dates, and reverting to previous versions is a precarious task that depends on community favors or risky sources.
  • The firmware is locked, with no SDKs, no plugin architecture, no patching support, and no pathway for community improvement.

This isn’t just disappointing — it’s wasteful. A device with strong hardware is being left behind because the software that powers it is frozen in place.

So I’m presenting two paths. It’s not a threat — it’s a mirror. One that reflects what Polyend could be, or what it chooses to remain.

Path A: Firmware Source Release

Polyend releases the source code of the Tracker OG firmware (and only that product), without documentation, toolchain setup, or build guides. Just the code — likely written in C for the Teensy platform.

With it, a disclaimer that clearly absolves Polyend of any responsibility for how it is used: no support, no guarantees, and no liability for potential bricking or flashing mistakes.

That’s it.

This path:

  • Opens the door for passionate users and developers to improve what was left behind.
  • Costs Polyend almost nothing, aside from transparency.
  • Sends a message to the community and the industry: you care.

Even if it’s released without polish, that source code contains value. It’s not a risk — it’s a release.

Path B: Stay Closed

Polyend continues on the current trajectory:

  • No source code.
  • No tooling or SDKs.
  • No way for users to contribute.

This sends a different message: that once a product is “legacy”, it no longer deserves software attention — and that the users who supported it no longer matter.

But that won’t stop the community. If you choose Path B, then the Tracker OG will still move forward — just without you.

An alternative firmware project already exists. It’s called [ RETracker :: REWrite ], and it’s being developed completely from scratch: no reverse engineering, no proprietary assets, fully open-source.

In 2025, powerful tools — including AI — make clean-room development and intelligent firmware analysis more feasible than ever. What was once a daunting task is now just a matter of time.

And if this project succeeds, the Tracker OG will finally have the support it deserves — not from its manufacturer, but from its community.

So here we are.

This is a fork in your philosophy.
You can open the vault — and gain the goodwill, gratitude, and contribution of the users who made Polyend possible. Or you can hold it shut, and slowly be replaced by the very people you left behind.

The choice is yours.

Sincerely,
A developer who sees what’s inside that vault — and refuses to let it go to waste.

Project link: https://github.com/00xBAD/RETracker-REWrite

32 Likes
2

A thoughtful, well measured open letter. I have nothing to add - well done :clap:

I’ll do my part :muscle: and i look forward to where this goes! :heart:

13 Likes
3

Please do that also for play and play+!

3 Likes
4

Interesting proposition. All the developers will be converging to meet in one spot later this summer, and we can have a serious discussion on it then and I’ll post back here afterwards.

15 Likes
5

Please do it… I really love my Tracker but sometimes I wish I could change a few things. I am a software engineer myself, so I am very interested in writing new features for it. It’s my favorite tracker and I wanna make it better! :slight_smile:

3 Likes
6

This does not affect me, as I have a Tracker Mini, but I fully support this. It feels like the right thing to do, low-risk, and will likely spur quicker / quirkier development in the + generation of products. @00xbad for your articulation on this issue, you the real MVP!

3 Likes
7

Sorry, but this project is strictly focused on the Tracker OG — nothing else.

I fully respect your views, but I kindly ask that we keep this thread on-topic. Please avoid posting about unrelated devices. I really appreciate your understanding.

Publishing this Open Letter to Polyend wasn’t an easy decision. It walks a fine line — one that touches on how the Polyend team might perceive it, legal and moral boundaries, and broader questions of business ethics.

Just to be clear: this is not a free firmware service for all Polyend products.
Let that sink in.

Wishing you a good day, Sir.

7 Likes
8

Thank you for the reply :heart: — I genuinely appreciate that the proposal is being considered seriously.

Knowing that the developers will meet later this summer gives me hope that a thoughtful decision will follow. For now, you have my full respect, and I’ll be looking forward to hearing back here, ideally by the end of September.

Wishing all the best to the Polyend team. :rocket:
Thanks again.

7 Likes
9

I’ve always thought Tracker has immense potential, especially given its ability to run NES games. Imagine what could happen if people were given the ability to write their own applications and run them on Tracker.

Bright examples of successful cases include Flipper and Playdate.

I also agree that Polyend significantly loses its enormous potential due to slow updates.

Torso S-4 recently released version 2.0 and made an evolutionary leap, which even convinced me to purchase their product, despite previously not being attracted to it. This shows that all updates and features directly influence sales.

Polyend has huge potential, a mature form, and products beloved by users, but they evolve very slowly and hardly at all in terms of software.

I also understand that you have 100 reasons why this is happening, but you should also remember that you have at least 1000 devoted fans, if not more, a large community that believes in you, is ready to vote with their wallets, and eagerly awaits breakthroughs and development.

6 Likes
10

Great thread, and well handled by both poster and polyend team.

I love my OG Tracker and Tracker +, such a great form factor and the OS is almost perfect, but seeing them both left undeveloped makes me sad.

Definitely two clear choices here, I’m excited for things to move forwards either way.

3 Likes
11

I know maintaining an open source repo is work. So, I am okay with not having a repo and just having a static, no commit history, zip file available to download. I am also okay with just having a one-time release with no additional releases. That should take a lot of burden off the Polyend team.

I’d rather have something to work with than put an expectation of potentially costly maintenance burden on the Polyend team which might cause them to say no. Do not strive for perfection, please.

4 Likes
12

That’s the point — they shouldn’t have to maintain a fully updated open-source repo.

The point is to publish at least a major version like 1.9.0 or 1.9.1 as open-source firmware on GitHub, so we can clearly see the full source code — a solid building block to start from.

In short, it all depends on Polyend and the path they choose.

  1. Polyend fully releases the source code of an actual 1.9.0/1.9.1 version, so the community can fork the repo and maybe create a unified, community-driven Tracker OG firmware project. At least, that’s what I hope — maybe it won’t be me, maybe it’ll be another passionate user with a clear vision of what the new firmware could become. Or maybe we’ll divide the work: coding, UI/UX, design, palette customization — whatever we can think of.

    And this way, we could collaborate with Polyend in some sense.

    I say “in some sense” because I believe forks and “experiments” should not be officially affiliated with Polyend. A brick — or even a soft-brick — is always just around the corner. The final user must be solely responsible for flashing any firmware from a GitHub repo that’s not fully stable. It’s always a risk, and users should be aware of that and not complain if TL;DR = Brick their Tracker.

    That’s why I hope that, after a full source code release, we can achieve a “unified” project with lots of contributors — even if not officially endorsed by Polyend.

    Some open-source projects are born purely from love and passion. I hope the same can happen for the Tracker OG.

  2. Polyend creates an SDK, so we can extend, implement, and overlay the actual firmware or its features. A clear example is Renoise and its Lua scripting tools. But this path clearly has two main issues:

    1. Polyend would need to put in more work to develop and maintain a good SDK.
    2. Software DAWs and firmware DAWs are very different beasts — making something cool while respecting hardware limits can be tricky.

  3. Polyend does not release the full source code or SDKs, so we’d need a “good alternative” — a stable, production-ready firmware. It doesn’t need to be 100% bug-free, but the goals would still be quality and reliability.

    I’ll stop here, because Polyend seems to be heading in a good direction after mentioning a summer meeting to discuss the request. I have hope for now.

So yeah, there’s a lot to talk about. But in the meantime — during these summer days — with a cold beer in hand, I make music with my Tracker. Even if I run into some minor but annoying issues (a simple reboot is usually enough), I carry it with me in my backpack, along with a good 20,000 mAh power bank, and I have a REAL PORTABLE FULLY-FEATURED DAW in my hands that lasts for hours of music making.

That’s why I love the Tracker OG. :heart:

Have a great summer holiday, everyone!

8 Likes
13

Thank you for posting (using very open language, deft touch and kindness), and also thank you for the amount of work/thought that you have put into this. As an OG tracker user, I am excited about a tracker alt firmware.

Overall, it is a complex situation: mainly because the amount of feature requests for the tracker are very overwhelming and underwhelming or whatever…for someone like me.

I also understand the polyend tracker design philosophy (it’s a tracker to make tracks) but I cannot understand the update 2025 intend nor the lack of interesting updates. For example: change colour scheme and so forth is the latest thing I am reading about.

For me personally i don’t experience a massive amount of bugs and I’m not ocd about any crashes and what not.

It’s always about context.

My context for any update, i.e, is about the sampler and wavetable functions.
The tracker is not a DAW for me. Nor a do all synth/effects/midi blar blar.

I’d personally like to see additional sample and granular functions. In the best case scenario akin to taking some of the influence from; the ensoniq asr-10, elektron md/ot, clouds, polyend synth sampler engine or torso s4.
Real time sampling or a looper would be amazing.

Plus a core update could be adding in some interesting new track lane effects or improvements (i.e update of arp, urgghhh).

For any alt firmware developers, I would suggest taking a look at the elektron md alt firmware. Why? Because the md alt firmware was closed off : not about ‘polling’ for ideas/requests and feature creep, but about extending the sound design possibilities of the md.

It is just my opinion but anyways…

2 Likes
14

Yeah, it’s cool, but remember that we can’t cross the boundaries of the hardware with only the firmware. You should upgrade the hardware, too.

However, an alternative firmware that uses all the Tracker OG hardware limits can be created.

It would be like older arcade/retro games that push the limits of cabinets, like Metal Slug, some PSX titles, or SNES ROMs, for example.

Even on modern consoles, they lag because the developers push the hardware to its limits.

You can overclock retro emulators to fix that, but it’s a software thing.

You can hack the firmware to use 100% of the underlying hardware, but then you have physical boundaries, so good firmware design is necessary.

1 Like
15

heya

I’m a software engineer too, in a different industry but one that also has passionate fans who sometimes make requests like this

the request comes from a place of love, but the way it’s presented has a false dichotomy in it - there are many more paths available than these two, and many reasons why the team may be forced to choose a path other than the one you want

there are so many reasons I’ve encountered why existing source bases might not be open sourced, but one way or another they usually come down to one or both of:

  1. packaging a project that was never meant to be released is costly. there would need to be legal sign-off for every line of it, there are probably a few places where maybe some code got copy-pasted and isn’t strictly owned by the company, there may be all manner of personal/secret info in there (it’s amazing what gets checked in!), etc

  2. even if the project itself is unlikely to be developed further, the source code likely contains some trade secrets that are part of the company’s secret sauce. things like reverb algorithms, which cost a lot to develop, but can be tweaked and used for many projects in future

please be prepared for the team to be forced to decline your hopeful request (even if they’d love to grant it) - and please don’t equate that to them not caring about the community

:heart:

13 Likes
16

I appreciate your thoughtful perspective — it’s clear you’re speaking from real-world experience, and I agree that requests like these often come from a place of passion rather than entitlement.

That said, I do think there’s a middle ground worth considering. If full open-sourcing isn’t feasible due to third-party code, proprietary DSP like reverb algorithms, or internal “secret sauce,” then perhaps Polyend could still release partial technical documentation — for example, the internal architecture of the hardware and firmware, without revealing sensitive code.

This kind of transparency could help the community understand how things work under the hood and lay the foundation for a collaborative alternative firmware project, without putting Polyend in any legal or business risk. Even a redacted or modular release — with placeholders where proprietary elements exist — would be incredibly valuable.

Of course, if Polyend decides to keep the firmware closed for valid reasons, that doesn’t mean they don’t care about the community — and I trust they’ll explain their reasoning if they choose to respond. But enabling community-driven development, even in a limited way, could be a huge win for everyone involved.

Just my 2 cents — looking forward to hearing what Polyend thinks.

7 Likes
17

Very awesome suggestion. It would definitely fix my biggest issue with hardware - going obsolete when team has no interest or resources to continue develop it.

1 Like
18

Just wanted to add something to the discussion after thinking it over a bit more.

It’s totally fair to assume the firmware might include proprietary DSP code (like reverb), or internally developed UI libraries, or even third-party licensed code. But that still doesn’t mean the entire firmware has to stay closed.

Polyend could release a partial firmware — let’s say, a kind of “Swiss cheese” version, where the proprietary components are simply mocked or stubbed out. For example:

  • Replace any custom reverb or DSP with a ReverbProcessorMock
  • Abstract UI components into placeholder functions or interfaces
  • Clearly indicate with comments or README sections where proprietary or sensitive code has been removed

That way, the community still gets insight into how the system is structured and can begin building something around it. The empty spaces can be filled with open-source components, or reimplemented by the community in time.

And honestly, for things like digital reverb — these algorithms have been public and evolving for decades. There are plenty of good open-source implementations that can be used as a stand-in. Nobody’s expecting Polyend to open up their “secret sauce” — just to give us the breadboard so we can start prototyping.

This isn’t about demanding everything. It’s about enabling collaboration without compromising the company’s IP or legal footing. That’s how you build a real dev community — by giving just enough access to make things possible.

Let’s focus on solutions — not roadblocks.

8 Likes
19

thanks bunches for all your efforts, 00xbad!! I’m really jazzed to see what comes of all of this!! happy summer to you & yours… -rocco

1 Like
20

Having Polyend release the firmware would be very cool.
Building your own firmware for the Polyend hardware would be very cool too.

But, do you think you can fit more in than is already there? Isn’t there a limit based on the micro controller and chips that are used?

4 Likes