Ship example minidexed.ini files for various devices

[probonopd]

[ci skip]

[diyelectromusic]

If we start going down the route of including bespoke minidexed.ini configurations in the repository then that will open the floodgates somewhat - I mean how would we choose who's files to include?

And should we be testing and maintaining every shipped configuration option (answer: yes) - if its included, we need to make sure it keeps working)? That would be an awful lot of work...

Maybe this should be something more for the wiki?

(and considering I don't think I know what DT-DX is, then this suggests the bar is being set pretty low...)

Kevin

[probonopd]

Well, the DT-DX is a hardware device that uses MiniDexed as its firmware.

It needs a certain pin configuration to work, which is different from our default minidexed.ini.

But I don't want to maintain multiple minidexed.ini for different hardware setups, especially since new keys may be added as MiniDexed development progresses.

So I guess I will write a small script that applies the pin configuration "on the fly" using sed or something like it.

[diyelectromusic]

To be honest, a bespoke minidexed.ini is probably a lot more preferable to a magic build step - but the outcome is essentially the same - you are updating the firmware to include a custom configuration for a particular device.

As I say, I don't think that should be part of the firmware.

I wouldn't expect to include custom minidexed.ini for my own PCBs for example, even though they are fully open source, freely available, not for commercial gain, and others have already built and used them in addition to me.

Surely the proper way to do this, if necessary at all, especially for a commercial device, would be for the company to fork minidexed and then they maintain and test their own version of the firmware, getting updates as they deem fit from the main repository?

Kevin

[probonopd]

I respectfully disagree here, I think we should include manufacturer-provided configuration for off-the-shelf MiniDexed compatible devices upstream, so that users of such devices have everything needed right in this repository. Similar to how e.g., the Linux kernel includes hardware drivers. This of course is open to all manufacturers of compatible hardware.

[diyelectromusic]

The Linux kernel is designed to run on the widest range of hardware possible so lots of people make the effort to maintain drivers and so on to ensure that is the case. In fact many manufacturers will develop, test, maintain and ship drivers for their own bespoke hardware.

If the manufacturer of a commercial device wishes to use open sourced MiniDexed firmware, developed by a wide range of people freely giving their time and effort, then it would be my opinion that they should maintain the updates required to make it work themselves, and not the project itself. We should not be maintaining firmware on someone else's behalf or directly supporting someone else's configuration and build.

Maybe a solution is to create a "contrib" directory for third-party contributed configurations?

Although it is only a configuration file, so I'm not clear why they don't provide it as part of their own build instructions? They are going to have to say "copy the special minidexed.ini for DT-DX over the original" anyway, so why does it have to be in the main repository to do that? And then as I say, maintaining the changes as the code base changes is their concern (as it should be).

In fact if it was me, I'd want a fork that I manage and formally issue anyway, otherwise they'll be at the mercy of an ever-changing codebase whether they like it or not and support for their commercial system will get... complicated... (especially as we don't do formal releases or have a properly managed dev branch like circle does).

It is great that others wish to build hardware to run MiniDexed, but I don't think that should be the concern of those attempting to maintain the code in the core repository.

Anyway, as I say, maybe making it clear that this is something not specifically supported by the core project, but maintained by someone else might be a way forward?

Kevin

[probonopd]

I think the key is to separate out hardware related configuration from everything else. So that we don't have to touch the hardware related configuration for every device each time we add something to the minidexed.ini file. A small shell script can apply the hardware configuration to the default (template) minidexed.ini on the fly.

[github-actions[bot]]

Build for testing: MiniDexed_2024-11-16-d7dc3f4 Use at your own risk.

[probonopd]

I'd like to merge this if you have no grave objections @diyelectromusic.

[github-actions[bot]]

Build for testing: MiniDexed_2024-11-16-9618a2d Use at your own risk.

[diyelectromusic]

I'm still not sure it needs the override/scripting setup over just a directory of alternative configs, but if that's how you'd like to do it, then I guess so.

Either way, having a subarea of configurations like this looks like a good way forward to me.

Kevin