16 TGs on RPi 4

[probonopd]

@diyelectromusic got 16 TGs working on RPi 4, shall we get this into the main branch?

[probonopd]

It built for all RPi models, I don't know whether it still works properly on all RPi models.

Build for testing: MiniDexed_2023-11-02-c9d357b

[diyelectromusic]

This was just my experimental "hey, would it even work" version. To do it properly, I would recommend using my newer more integrated version that also supports 16 TGs across two Pi 3s via the "expander" idea. That is a much more robust (in my view) implementation, but still isn't quite finished...

But I was generally waiting for some views before going much further... well, I'll keep going for me, but before I started to think about how to integrate it :)

Anyway, latest code is here https://github.com/diyelectromusic/MiniDexed/tree/16TGExpander

Kevin

[probonopd]

Hi Kevin, I'd like to separate the idea of using 16 TGs on the RPi 4 from the whole "expander" (using multiple RPi devices) concept if possible.

If we can make the former work (and it seems like it should not be too many code changes), then I think we should merge it quickly. I don't think we need to make the number of TGs configurable in the ini file, just using the maximum each RPi model can support should imho be fine.

The "expander" idea may become less relevant with the advent of the RPi 5, which may well bring us to 32 or even more TGs plus effects. I am not sold on the idea to complicate the codebase with the "expander" idea if it is a very rarely used configuration/use case.

[diyelectromusic]

Well most of the updated code is still required as we're moving from a fixed number of tone generators to something a little more dynamic. I guess we could always just mandate that for a Pi 4, it will always build for 16. That is definitely the simplest, but I wasn't sold on the performance always being ok with 16 without some serious testing, so thought it ought to be configurable with 8 remaining the default.

And I'm afraid I don't subscribe to the view that it is ok to keep assuming people will be buying better hardware when for a little effort, older hardware can be almost as good, and actually sometimes even much more suitable for many circumstances. It is interesting to note that MT32-Pi recommends a Pi 3 over a Pi 4, and my experiences are pretty similar. It is a lot easier to not to have to worry about cooling, fans, and the mechanical side of things like that if it isn't necessary.

So I don't know... but either way, this is still experimental, and the branch you've linked to I can't recommend we use as it is very over-simplistic in its approach (deliberately so as a first experiment).

By the way, the expander support has the interesting side effect that more of the UI becomes directly accessible over SysEx which might open the doors for some interesting new possibilities still to be explored in the future too...

Kevin

[probonopd]

Closing this PR but would appreciate if you could make a new one for 16 TGs on the RPi 4 and later. Thanks for considering this @diyelectromusic. My assumption is that unused TGs are not producing load and should not cause any issues. So, having 16 TGs on the RPi 4 and only using 8 of them should be no worse than having only 8 TGs.

Let's separate the number of TGs on the RPi from the discussion around using more than one RPi. I can see your argument, but I feel like it should be discussed separately.

[diyelectromusic]

My assumption is that unused TGs are not producing load and should not cause any issues.

Yes, I did wonder something similar initially, but I don't think that is true. If you look through the code in ProcessSound in MiniDexed.cpp (the multi-core version - there are two!) the cores are all still running each TG waiting for the EG to trigger and the results (even zeros) are calculated and gathered and mixed using the various getSamples() calls into each instance of Synth_Dexed to be recombined back on core 1 (or it might be 0... can't remember).

And in the MIDI handling, it trawls through all existing generators matching MIDI channels before calling keydown on any that match regardless of how they are used. We can kind of use the MIDI channel as a sort of mute, but it would make a lot more sense to have a proper mute function for each TG...

I've also not looked at how it is affected by memory use. CPU wise it might be fine, but if you have a 1GB Pi 4 you might want to limit the number of TGs in use rather than have them all initialised and ready - I don't know... it's probably fine, 1GB is a lot for a bare metal setup I'd have thought, but we should probably do some checking!

So there are quite a few unanswered questions before we should assume every Pi 4 should support 16 TGs and that is before we get into things like performances - should all the existing performances now include "TG 9-16 disabled" for example? It is certainly quite a pain to scroll past 8 unused menu items if you're using 8 TGs but want to get to the effects...

Kevin

[Banana71]

@diyelectromusic , I was thinking about the Performance.ini with 16TG's. If you assume that the miniDexed is a clone of the TX816 you should stick with the performance.ini with 8TG's. For the 16 TG miniDexed version I would like there to be an upper and lower area, similar to e.g. on the Roland D50. This means you could then load a performance.ini into the “Upper” area (TG9-16)and a Performance.ini into the “Lower” area(TG1-8). The FX settings are taken from the Performance.ini from the Lower area. This would mean that all existing performances would be compatible. What do you think?

[diyelectromusic]

@diyelectromusic , I was thinking about the Performance.ini with 16TG's. If you assume that the miniDexed is a clone of the TX816 you should stick with the performance.ini with 8TG's. For the 16 TG miniDexed version I would like there to be an upper and lower area, similar to e.g. on the Roland D50. This means you could then load a performance.ini into the “Upper” area (TG9-16)and a Performance.ini into the “Lower” area(TG1-8). The FX settings are taken from the Performance.ini from the Lower area. This would mean that all existing performances would be compatible. What do you think?

I think that is pretty much what you get if you pair up two Pi 3s using my expander code ;)

Although if you wanted upper/lower independently then you don't even need the expander, just two MiniDexeds configured for channels 1-8 and 9-16 respectively would be a lot simpler than trying to do it all in a single UI...

Kevin

[Banana71]

I was only thinking about the PI4 with 16 TGs