List of known bugs.

[Banana71]

Shouldn't we have a contact point where known errors are listed in a table with a link to the issue?
This is where talented programmers can let off steam and drive the project forward.

✅ - Performance: "Save as default" overwrites the first performance of the current bank

• - Sostenuto pedal does nothing
• - Modulation Range Error

[probonopd]

hi @Banana71, that's what https://github.com/probonopd/MiniDexed/issues is for. I applied the label "Bug" there to draw attention to them.

[Banana71]

The issues area reminds me more of the Ludofs heap principle (Haufenprinzip) . The bug reports are also difficult to find and are now old.

I just want to show the programmers among us the problems with miniDexed. A summary of the bugs is also interesting for every other user.

[diyelectromusic]

I have quite a much longer list than that, but some of them take time to decide the best way to sort them out (just look at all the performance menu related things)...

But contributors seem much more interested in throwing in lots more new code for additional features than trying to stablise the existing code. I do worry that if we keep adding features (thinking here of the Arturia support, networking, and the new effects code) it will be become quite unmaintainable and a lot more unstable.

There are only so many hours in the day and attempting to anticipate and understand major changes contributed by other people seems to soak up quite a few of those "MiniDexed" hours (at least for me).

It would be a lot easier if we could maintain a stable release and experimental dev branch where things could be accepted more quickly. Then others can then choose if they want to follow the cutting edge or have something a bit more reliable.

I guess I'm saying I'd rather have a prioritised "todo" list for newer features so we can decide, /before/ someone spends a lot of time on something - to actively pursue if this is something we really want in the system or not, or if the penalty for including it is too great.

But it seems to run the opposite way around at the moment - someone comes along with a load of ported code from something else and then the dilemma is do we annoy them if questioning how the code works or how it will impact the existing system; or do we accept the contribution just won't be used as we don't want to risk it; or do we accept it gratefully and hope they will still be as interested (and still around) in six months time when the implications come out and things need fixing, reverting, or otherwise sorting out?

I still think we ought to remain true to the original MiniDexed goals and accept that if someone wants a fully singing/dancing/sequencing/effects/etc system, maybe they should be looking at something like Zynthian on a Pi 4 or 5.

Kevin

[soyersoyer]

Stable releases are already being made from the tagged versions.
Circle needs version branches because there are many projects that build on it that don't necessarily want the latest version, but do want bug fixes.
But I don't think this is the case with MiniDexed. (It doesn't work the way I thought it would.)

[probonopd]

I just would like a system where we can accept PRs more quickly without worrying about breaking a release for inexperienced users.

Would this do?

• Rename the main branch to dev
• From time to time, make tags/releases from it when we think we have known good builds

[diyelectromusic]

Whatever you think gives us a stable version and a "we aren't afraid of breaking it" version :)

As long as all the documents point to the last known sensible release, I think that would be fine. It can stay as "main" if that is the way it works best (as I've said many times, I'm not a GitHub person either :))

The only issue is how long does the branch have to exist with no changes to be considered stable and how do we decide? But if we get it wrong, that is only like reverting back to what we have today anyway, so it's probably not a big deal anyway...

Kevin

[probonopd]

The main additional work would be for someone to determine which builds are considered good enough to be tagged. Ideally we'd make a checklist. Something like

• Test on all RPi models that it produces the intended sound in the default performance
• Confirm that all performances sound as intended by @Banana71
• ...

[diyelectromusic]

Stable releases are already being made from the tagged versions.

@probonopd how do you decide when to do a tagged release? Maybe making those more prominent and some kind of "do not use the continuous build as it could break at any point" type warning gets us a good way there already as @soyersoyer suggests?

Or maybe we need some kind of acceptance criteria for when a set of changes is deemed stable?