Increase maximum number of LADSPA nodes

[mawe42]

Following up on https://lists.nongnu.org/archive/html/fluid-dev/2021-03/msg00000.html

The maximum number of nodes in the LADSPA system is currently hard-wired to 100. When using multi-channel outputs and/or many effects or buffers, this limit can be easily reached.

A quick solution would be to simply increase FLUID_LADSPA_MAX_NODES to a higher number, like 500 or 1000. That would increase static memory consumption of FluidSynth by 400 * sizeof(void*) or 900 * sizeof(void*).

Alternatively, we could change the way the nodes are being allocated and move to dynamic allocation and linked lists instead. I would be fine either way, leaning a bit towards simply increasing the limit. Any other thoughts?

[jjceresa]

I would be fine either way, leaning a bit towards simply increasing the limit.

Perhaps the maximum number of nodes could be simply set at LADSPA system creation ?. Then if the limit is reached, the user should destroy/recreate the LADSPA system with an adequate number of nodes ?. The shell command interface (or a setting) could provide this also ?.

[mawe42]

I would rather not burden the user with that choice. It would mean that users would need to understand or at least know about "nodes" and why there is a an upper limit. But that knowledge does not actually help them in reaching their goal, it's simply in their way. Nodes (and the limit placed on them) are an implementation detail, only people trying to understand or change the LADSPA code should need to know about them, in my opinion.

But thanks for that thought JJC, because I think it made up my mind about which way to go! As we can't realistically choose a limit that will not waste lots of memory and still ensure that people will never run in to it, going for dynamic allocation seems to be the way to go. I will draft a PR that handles those parts with linked lists.

[jjceresa]

going for dynamic allocation seems to be the way to go.

I think you are right. As the user have to deal with other LADSPA intricacy , "nodes limit" should not boring them anymore.

[jjceresa]

I will draft a PR that handles those parts with linked lists.

Even if linked lists is wasting 50% of memory it is still a good choice because it is far more easier to implement that using memory allocation/reallocation.

[mawe42]

Even if linked lists is wasting 50% of memory it is still a good choice because it is far more easier to implement that using memory allocation/reallocation.

I agree, linked lists are much easier. And I think they will be beneficial in other ways as well, as they allow easy ordering of nodes and therefore remove the need to keep three separate node lists for host, audio and other nodes.

[derselbst]

I've committed the quick solution on 2.1.x. For master I agree we should go with linked lists instead.