32 note polyphony on a PI 4

[diyelectromusic]

This is just experimental at this stage for anyone wanting to experiment with 32-note polyphony on a Pi 4. It has been built and appears to configure 32-note polyphony correctly, but it hasn't really been tested in any significant way.

In particular the performance is currently unclear, so at present, use at your own risk.

Feedback on any experiences is welcome.

Kevin

[probonopd]

Please comment here if you have tested this. If there are a couple of positive feedbacks, I'd like to merge this. Thank you very much @diyelectromusic

[Banana71]

My RPi 4 runs stable and reliably with 32 voices per TG.

[Banana71]

Unfortunately, I found another problem that occurs with 32 polyphony :-(
With Engine Type Mark I, cracking occurs after a very short playing time. I haven't tested Soundengine OPL yet.
Is it possible to query the sound engine when assigning the polyphony?

#if RASPPI == 1
        static const unsigned MaxNotes = 8;             // polyphony
#elif RASPPI == 4
        static const unsigned MaxNotes = 32;
#else
        static const unsigned MaxNotes = 16;
#endif

[diyelectromusic]

That's interesting. Does it degrade over time then? And is it an issue regardless of how many notes are actually sounding (i.e. does the cracking sound on single notes) or is it only when you actually reach 32 notes simultaneously?

I was just going on the definition of the maximum polyphony in Synth_Dexed but it is possible that might only be suitable for a specific engine, or maybe it is a theoretical maximum not a practical one!

It might be worth trying an in-between value, say 24...

[Banana71]

There are several factors that influence the triggering of the crackles. I tested with performances that use all 8 TGs.

• The algorithm has an influence: algorithms 1 and 2 are the most sensitive. I couldn't get Algorythm 21 to crack at all.
• The feedback factor also has a significant influence. Algorythm 2 with a feedback of 0 has no cracks.
  Perhaps that is also the reason why algorithms 4+6 do not work with Engine Type 1.

I would very much like it if we kept the miniDexed playing with 32x polyphony on an RPi4 and Engine Type 1 (Modern).
It would be great if you could set the polyphony for the RPi 4 in the code depending on the sound engine.
The piano sounds in particular benefit from the increased polyphony and they actually only sound good with the Modern sound engine. The short attack times of the pianos produce cracking noises via the Mark I and OPL sound engines.

[diyelectromusic]

I wonder if this is all related to the discussion here #358 (comment) that was never really resolved as far as I can see?

[probonopd]

I'd suspect the same.

[diyelectromusic]

Ok, so returning to the question of polyphony and number of tone generators (see discussion here #557) I think I'm going to go with the following:

On a Pi 4 or 5 allow for a maximum of 16 tone generators and a maximum polyphony of 32, but the defaults will probably be as follows:
Pi 4: 8 TGs, 24 note polyphony
Pi 5: 8 TGs, 32 note polyphony

There will be configuration options for both number of TGs and polyphony but they will be limited to specific values (8 and 16 for TGs; probably 8, 16, 24, 32 for polyphony - although this isn't so critical).

The others will remain with the following settings:
Pi 1: 1 TG, 8 note polyphony
Pi 2+3; 8 TGs, 16 note polyphony

I don't think we should default to 16 TGs as that is just so much extra menu shuffling to do and all the performances are designed for up to 8 TGs.

The approach I'm taking is to choose sensible defaults we know pretty much work in all cases, but allow the flexibility for people to expand and tradeoff polyphony and TGs depending on the performance of their Pi.

Thoughts?
Kevin

[probonopd]

When calculating the available processor power, let's not forget the possibility that someone might want to bring in more elaborate reverbs (think Lexicon 224), choruses (think "Dimension D", "Juno"), etc., so maybe we should leave some headroom and/or (as you suggest) make things configurable.

[diyelectromusic]

I think we can over think it, so I'm all for setting useful defaults, allowing for maximum options and then letting the user find a combination that works for them with what they're trying to do.

[diyelectromusic]

I'm starting to think about this going on the scheme I posted above. Any thoughts on performances and number of TGs?

At the moment, I'm thinking it will load a performance up to the number of configured TGs, but when saving it will save out the configured number.

So loading an 8 TG performance on a 16 TG system should be fine, but if saved it will become a 16 TG performance.

Loading a 16 TG performance on an 8 TG system will only load up to 8 performances., but saving will replace the original 16 TG performance with an 8 TG performance and lose the rest of the previously stored (on disk) information.

I'm not sure we could do much else tbh. Basically - don't mix performances and TG configs unless you know what you're doing! :)

Kevin

[diyelectromusic]

Ok, so all the updates are now happening here: #690

(this one can be closed)