Repository navigation
RFE: Create DSP "configurations" #73
Description
The current "configuration" of DSP1 and DSP2 copies to a great extend the original x32 firmware.
However, there may be a need for different "configurations" with regard to:
- the number of channels with full DYN / EQ / SENDS /etc.
- the number of channels with only basic volume control
- the number of channels with 6-band EQ as it is the case with the original FW
- the number of effects (now DSP2)
- whether or not we have some features such as RTA, sine generations, M/S stereo, etc.
It could e.g. be possible to increase the number of channel between the FPGA and DSP1 and the number of channels between DSP1 and DSP2 by using TDMA16 or even TDMA24 and then use DSP2 for channels with full DYN / EQ / SENDS /etc. exactly as DSP1 does while dropping the effects IN THIS configuration.
For this to happen it would be needed to:
- merge the code of DSP1 and DSP2 into one code base
- create a build system which would have "configurations" in forms of .h files. In each configuration_.h file it would be per #define defined which functions are used on which DSP for how many channels, effects, etc.
- for each configuration_*.h file two firmware binaries would be compiled for DSP1 and DSP2 respectively from the common code-base and a metadata file be generated (with configuration name, description, metadata for the UI with regard to channel numbers, types, effects, etc.). Alternatively, those 2 firmware files together with the metada could be packed into a single binary file
- it would be then possible for the user to choose the desired configuration on-the-flight from the user interface and directly use.
(Actually it would be the best if we could also include the FPGA code as well, but that might be tricky as DSP and FPGA use completely different build environments :-( )
That would allow for more experiments with various kinds of channels/effects/etc configurations. while maintaining a single code-base and an unified UI.
It would make new features possible which would require dropping other features to still be part of the project and not having to stick with one predefined configuration as the original firmware does.
Activity
frenze31 commentedon May 1, 2026
I support this idea. Some might need more channels or more mixbuses, while being okay to sacrifice FX slots. dLive systems have a similar concept wherein you configure how many mixbus/matrices do you need, etc.
Edit: okay maybe not fx slots, since i don't think it's possible anyway since fxs lives in DSP2
DrEVILish commentedon May 2, 2026
A lot of video processor units have a similar philosophy 4K takes up 2 resources while 1080p takes up 1 resource.
Just added an feature request related to this OpenMixerProject/OpenMixerControl#17 that would require the user to have knowledge of the available system resources when adding channels/features. You might not need Gates/Comp etc on multi-channel sources. That would save some processing.
I personally like having a Ducker / DJ Compressor available on my Stereo Channels, Inf-Ratio with ultralong, Hold and Release, which means if the DJ turns themselves up it slowly turns them down.
schulz-alexander commentedon May 2, 2026
the "unDJ"-Feature 👍
otonielpv commentedon Aug 31, 2026
One use case I’d be very interested in for DSP configurations would be trading input channels for additional mix buses.
For example, many X32 users don’t need all 32 input channels but run out of the 16 available mix buses, especially when using the console for IEMs, streaming and multiple output mixes.
Would a configuration such as:
be technically possible with the current DSP/FPGA architecture?
Essentially, instead of having unused input-channel DSP resources, it would be great if a DSP configuration could allocate those resources to additional buses.
I think this would be a very useful example of the configurable DSP architecture proposed in this issue.
butrus commentedon Sep 2, 2026
This is EXACTLY one of the use-cases I was thinking of, while opening this ticket. Thank you!
I suppose yes.
schulz-alexander commentedon Sep 3, 2026
It's possible, of course. We/you/someone can programm whatever we/you/someone want ;-)
otonielpv commentedon Sep 3, 2026
@schulz-alexander On the subject of contributions, what are your thoughts on using programming AIs for this project? Are you actively using them in development? I don’t currently have a great deal of knowledge about programming DSPs, but with the help of AI and by researching a bit, I could give it a go – though I’d like to hear your views first.
schulz-alexander commentedon Sep 3, 2026
You should understand your code and be able to maintain it. That's the main thing. If you or the AI wrote it is not the question. But most people understand self written code better than other code.
schulz-alexander commentedon Sep 3, 2026
We use AI mainly for research, prototyping and optimisation of code.
schulz-alexander commentedon Sep 3, 2026
And writing code is fun in itself and a big part of the time I spend here. Our goal is not a finished product, we want to learn and explore and do cool stuff with computers and audio.
butrus commentedon Sep 24, 2026
I plant to. One problem is however, that you would have to significantly rework the current code base so that you only have ONE code for both DSP1 and DSP2 and then you could just use different configuration that use the same code on either (or both) of the two DSPs, depending on the configuration chosen.
This would need to be well coordinated otherwise we end up with two versions of the project and a complete chaos.
We need a consens before we start such a thing, otherwise we go into the danger that our fixes and new features go to the "old" codebase and it takes a lot of efford to port it into the "new" one.
Regarding the AI: Can we have it in a separate bug / discussion, please?