Open-source / Community firmware

General
,
23

While I’d love to see the codebase, I dont think its in Polyends interest to open source, maybe when the products are nearing or do go end-of-life.

E.g. I’d really like to see the Medusa firmware open sourced, I know Lukas was the last to add features for it, and that there wasn’t any headroom for anything more, but with it being a retired product, seeing under the hood would be awesome as a developer.

As for what could be open sourced, could we perhaps get the binary file formats from Polyend?

I started down the road of creating a Renoise xrns ↔ Tracker project converter (since we lost mod support), but only had the (excellent) exisiting reverse engineering work of Jaap Roes to jump off from, so decided to put that project to one side for fear of firmware updates leaving it incompatible in the near future.

3 Likes
24

Oxi team is super responsive and receptive, they make updates based on user feedback and request VERY quickly. Would love to see some similar sequencing and workflow features added to the Play

2 Likes
26

Sorry, that was definitely not what I meant to say. I rather meant that there is hardly any talk about the trackers on YouTube, for example - or if there is, it is extremely critical. I have adapted my post to make this clearer. I actually think Polyend’s communication is great.

1 Like
27

i personally feel exactly the same way as you do. While i’d love to tinker around with the codebases, i also believe that these living and expanding ecosystems do not need to be open sourced.
In the same vein though - i would have loved to see legacy products to be opened up to the community.

The last point you mention, is the thing i am most interested: to have the ability for the community to build tooling around the existing ecosystems that does not interfere with the actual devices.

Which is exactly why i created this wish a while ago:

While this was created in reaction to the removal of .mod and .it support. The intent of this request goes beyond that and is meant to benefit the overall ecosystem.

5 Likes
28

I think, this is also an interesting idea!

1 Like
29

I believe it boils down to this:

Open source development works for commoditization, and Polyend is in the business of innovation.

Open source development can also work for innovation but for platform development, and Polyend is in the business of product development.

So no, even with all my free-as-in-freedom software love I would not try to sell open source development as a strategy to improve Polyend’s business and products. I do think they could improve their brand - aura - cult and maybe their products with moves like making every single pad, knob and button MIDI-mapable on the Play or have a developer program for the Trackers where selected community members get some access and opportunity after signing some agreement. Mapable, hackable… powerful tools for music tinkerers. I’d go this route.

3 Likes
30

There is no need to open source, it’s better to hire more developers and update the firmware more often! Sales will increase and everyone will be happy :slight_smile:

4 Likes
31

Wouldn’t making software open source be negative for Polyend as a company?

It would eliminate the need for their hardware and boil them down to a software developer?

Renoise exists and is way more powerful.

I don’t know, I’m not a business man or a coder.

1 Like
32

According to Frederick Brooks’ “the Mythical Man-Month” adding more programmers to a project causes it to take longer.

33

I like Sandroid’s ideas, looking at the votes in their poll there’s a good amount on developing the Ecosystem.

One thing that comes to mind for me is that there are ways to extend the ecosystem without open-sourcing the core of the firmware itself. I’m new so I hope that’s not taking the thread too much off the original topic (maybe better to create a new thread?)

There could be a software development kit (SDK) that would allow the community to write plugins without the need to have access to the whole firmware. Polyend would be in control of what is available to the plugins and the types of plugins possible via the SDK, open sourcing the parts of the SDK and some examples but keeping the firmware itself closed source (or making the SDK available only after registration or other approach).

It’s not a silver bullet tho, an SDK has to be developed, maintained, extended with new features. Having worked on one in the past I know they’re not to be taken lightly or as a one and done. Then there’s how to deal with plugins and keeping the device safe, there’s a lot of ways to approach to plugins:

  • The naive approach plugins are complied by 3rd party and run on the device (usually avoided because of security issues, you don’t want a bad plugin to break your tracker/play)
  • The plugins run in a sandbox to limit what they can do and protect device, users could add them to their SD card (not unlike a nes file), that said sandboxing isn’t easy to implement well (WASM might be interesting)
  • Plugins submitted to Polyend and they compile or sign them and offer them as plugins from certified developers, e.g. Apple/Google Play stores… But that’s even more work for Polyend to handle, not to mention it goes less in the open source direction
  • Probably wont work for all Polyend devices, but plugins could run externally and communicate over a channel (e.g. connected via usb/wifi/bluetooth/…)

Polyend wouldn’t need to solve it all at once and could add plugins types over time, starting with sample playback plugins or effect plugins, then other areas could be reworked to support different types of plugins. Although it would result in a new category where more feature requests will likely come up.

3 Likes
34

I’ve only just gotten started with development for constrained platforms like the PT hardware, so I may not know what I’m talking about - but would running infrastructure for plugins to hook into even be feasible on this hardware?

35

Hah, i thought of the same a while ago and still like the idea. but with DSP (digital sound processing) adding these types of hooks to a processing loop can become costly very quickly.

Technically i think it is possible. But i also question the feasiblity. How much refactoring would be required and what kind of overhead does that generate performance wise?

While i don’t think the performance hit would be drastic for that itself… the moment you would allow 3rd party devs to create transformers/processors for instruments/steps etc, how do you make sure they don’t hog all the performance with their code? :laughing: On the other hand, if all step effects etc, become “plugins” you’d only have to process/load whatever has been actually used.

It’s all very much dependent on the actual codebase and of course hardware capabilities.

2 Likes
36

What would help with that is if the only “plugins” they’d allow is offline effects. Which would be kind of cool, actually, though those aren’t necessarily all that safe either (managed to tender my PTM unusable several times EQ-ing long samples, requiring a reboot).

1 Like
37

Open sourcing won’t magically attract competent developers and I think that endeavor would use up polyend resources.

Any time someone wants to open source, I think they are just voicing that they want bugs fixed and features introduced at a quicker pace.

Knowing that polyend has finite resources, all I can voice is that bug fixes should have priority and that they should be released on their own (more frequent) schedule separate from new features.

We shouldn’t have to wait for bug fixes because management wants to wrap up bug fixes alongside new features.

1 Like
38

Agreed. I’m all for open source, but in this case I want it so we can have a more stable Tracker, not a bunch of pointless “features.”

More incremental bug fixes between feature releases. If they can’t do that, there’s a fundamental flaw in how they are developing software.

1 Like
39

You confuse a product line build with branches.

The roadmap for what Polyend wants to do has little importance at that point, if the code is open. As everyone can make their own branch and add features as they fit. Ever heard of Github? Then you should see how many forks are there for certain projects, which do not affect the original project in the end.

Instead of thinking about consumers asking for features, think about developers writing those features. I can write mine and then decide to share them if I want to, or keep them for myself if it is something I only use. Then once in the wild, the dev team can decide if they want to port those changes into the main branch or not… That does not affect in ANY way neither roadmap, scoping or features, so I really don’t get your points here.

The only reason why they don’t want to go open source is because others may get the code, change it a bit and sell it as if it was their code; making their own device. Just look at what happened with many trackers or synths on the market: They use open source libraries, they make a product and SELL it (which is illegal following the standard licensing for those open source libraries). IF I was Polyend and I spent time and efforts to make my own code and hardware, I would think carefully about what type of value would I get, if I would go open source… And most small companies find no value in that sadly.

1 Like
40

Another reason just as important and more immediate is that open source development easily needs more time and resources for the maintainers of the code. Especially true when you need to publish an SDK, there is hardware integration, there are different hardware products to test against for every patch, there are hardware products in the pipeline that haven’t been announced but already define the company roadmap…

That’s the technical part. On the social side you need to spend time time creating public documentation and guidelines, code of conduct that then you need to enforce, you need to give feedback for any patch you receive, patches easily won’t meet the standards and you’ll need to explain why, some volunteer developers will push back and you will spend way more time and energy than if you would write the code yourself…

I’m talking about the daily realities of open source development beyond the romantic idea. As I have mentioned above, the open source model is well tested for commoditization and platform development, not for innovative commercial consumer products.

42

To a point, yes, but that is the whole point of OS.

If you have 10 people on your payroll, you can get only so much done. If you outsource to hundreds or thousands of developers for free, that do the job for you, you have to monitor the repository for stability and that is way more convenient than hiring 10 more people to work on your firmware.

Maybe you don’t realize that but Linux has been basically written for most part by others; as many products that are basically ubiquitous at this point. So the hardware integration part is really relative in the end.

Way harder is to make documentation and keep it updated. That is a problem that large corporate have to constantly deal with, and no matter how careful you are, docs and guides end up becoming obsolete after not too long.

I am well versed in the field; been doing this professionally in the silicon valley for close to 30 years now. Open source is not a solution but there are many aspects that push even large corp like Google for example, to use plenty of open source components and projects. Those people must be idiots right? :slight_smile:

43

Great maybe we are not that far apart. :slight_smile: For more than 20 years I work professionally for commercial and non-profit organizations developing open source software. Desktop, mobile, embedded, and web, including brands known by anyone in this forum and probably all your relatives and friends, and projects known by any Linux developer and most conscious Linux users. I have lived and worked in the SF Bay Area too, I have many former colleagues and other people I know working in Google open and proprietary projects, etc. I’m really familiar with all the context you describe.

Ok, back to the topic. Your point doesn’t enter in contradiction with mine. Google invests in Android, Chromium and also OpenStack, the Linux Foundation and many pieces of the stack they have underneath because they are a) open source platforms that support their products (which aren’t open source), and b) wheels of commoditization to compete with Apple, Microsoft, and Nokia (if we remember how was the world when Android was launched), and anyone else getting in the way without partnering with them.

Are they running an open source project for their Google Pixel array of products? Not at all.

That’s not the situation Polyend would be in if they decide to opensource their software. Not even remotely. Music gear is a niche product compared to servers, PCs, and mobile phones. And Polyend is a niche within that niche. And each of the hardware product families Polyend has is a niche within the niche of that niche. That is the reality at a code repository level.

44

Nice to see a fellow neighbor :smiley: And considering that beside Apple, Google, Facebook/Meta and few others, those are the companies most of us work in, we have probably worked in the same places too. Small world in the end

My point was not in counter what you said, just in pointing at one specific section of your reply:

“open source development easily needs more time and resources for the maintainers of the code. Especially true when you need to publish an SDK, there is hardware integration, there are different hardware products to test against for every patch, there are hardware products in the pipeline that haven’t been announced but already define the company roadmap…”

Specifically to your point, hardware compatibility and evaluation of patches was what my reply is related to.

A company may invest in open source and still keep projects as closed source and secret. That makes sense as you have IP to protect. You can do both of course, but if you sell a product/service and use open source products, it is nice if you eventually port back your work to the original repo, so others can benefit from it too as you (corp or individual), got a benefit from it.
Will we see schematics for the Pixel or for the Meta Quest 3? Of course not, those are products that fill the bank account reservoir, and did cost a ton in R&D and engineering/design time… But are we getting benefits from what is released as open source, once parts of these projects are considered to be low in terms of revenues? Totally.

I may remind you that most open source projects are made by small teams in niche environment, not only by large corporation. Niche or not, that is tangential to the open source line. Historically when you need more workforce and you don’t want to pay or maintain something, you make it open source. It is a small “price” to pay, in exchange for a large benefit on many aspects.
Just look at the M8 device: it is a Teensy with some extra hardware on it, and a fork of LSDJ with upgrades… You can find those pieces on multiple repositories, but the author made the work to patch everything together and give it a “shape” and sell it as product. That is a niche product too and yet it was made thanks to even smaller and more niche projects that were open source in the end. And there are plenty of other projects (especially related to FPGA), that ended up being born as mix of other open source projects at their core, with a variable amount of efforts to create the final product.

So in my opinion the statement

That’s not the situation Polyend would be in if they decide to opensource their software. Not even remotely.

Is that I don’t believe that it is the case; on the contrary, open source would give Polyend the chance to offload most of the extra work for free, while they focus on new products and innovation. As you know, it is not the initial 80% of the work that takes time, money and efforts, but the remaining 20% :slight_smile:

Polyend releasing a 1.0 products involve a lot of efforts, but that 20% left to make a device a great device with updates and optimizations is where you get lower ROI, as you already sold your devices, and can’t sell updates as DLC, like you do for games for example. So you can offload this work to others for free, making the product or part of it as open source; and in return you get more sales, as people want to buy your product as it is updated often, improved often and not perceived as abandoned.

Then of course if Polyend goes for the route of making a device every few years and abandon it, the whole setup I described goes in the drain, as their income is based on the 80% of the efforts, so they trash the remaining 20% and wait for other customers to buy the newer device.

2 Likes