Any plans adding buffers for each channel?

Started by bass, November 04, 2024, 21:21:53

Previous topic - Next topic

bass

I already asked about 5 years ago, if there any plans to add buffers for each channel so we tracker player programmers could finally add cool visualisation stuff (like oscilloscopes) when using libopenmpt.
This ticket here is from 2017 and it´s still marked as new:
https://bugs.openmpt.org/view.php?id=1042

I don´t know the internals of the library, but could it be possible to add this feature without changing the current mixing routines? Just some kind of extra data, which could be added additionally. It would be enough to add the first 100-200 bytes of each channel into a new bufferlist or something like that.
Are there any plans? The only reason I don't use libopenmpt is the lack of this feature. So I´m still waiting for this :-(
Thx!

manx

Quote from: bass on November 04, 2024, 21:21:53I already asked about 5 years ago, if there any plans to add buffers for each channel so we tracker player programmers could finally add cool visualisation stuff (like oscilloscopes) when using libopenmpt.
This ticket here is from 2017 and it´s still marked as new:
https://bugs.openmpt.org/view.php?id=1042

It's still planned, but (at least for me) somewhat low priority at the moment.

Any relevant updates will be discussed in the issue you linked.

Quote from: bass on November 04, 2024, 21:21:53I don´t know the internals of the library, but could it be possible to add this feature without changing the current mixing routines? Just some kind of extra data, which could be added additionally. It would be enough to add the first 100-200 bytes of each channel into a new bufferlist or something like that.

In addition to forcing a somewhat slower rendering path (because we currently render and mix a channel at the same time, if no plugins are involved, using separate buffers will significantly increase cache pressure and hurt older systems), the most difficult thing is designing the API, for the reasons outlined in the issue: channels can be grouped and routed through plugins, so the waveform per channel will not be what is finally be heard from that channel, and the waveform per-plugin might contain multiple channels. It's also difficult to design the API somewhat future prove regarding even more complex audio routing graphs which might get added sometime.

I would prefer to move further discussion to the issue tracker.