Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Request: Configurable tap position in DSP chain for visualization? (Read 2923 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Request: Configurable tap position in DSP chain for visualization?

I have stuff in my DSP chain I don't really want to have visualized in RMS meters or spectra or whatnot. The biggest thing I don't want is a balance control which is a VST plugin, but ReplayGain's attenuation also makes for a less clear peak/rms meter - when I'm using foo_recorder to record an FM station, I usually have to disable all the DSPs to use the peak meter to see if anything is clipping. I'm also not too fond of crossfeed being visualized either.

What would the developers think about, perhaps at the very least, allowing all of the visualizations to tap their data from the start of the DSP chain, as opposed to the end? So eg it is visualizing the input audio as opposed to the output audio?

Request: Configurable tap position in DSP chain for visualization?

Reply #1 –
Let's not forget that ReplayGain (or the non-RG pre-amp scale) is applied before the DSP chain. Or that certain DSPs, such as the DTS decoder, are best applied before the visualization processing.

Request: Configurable tap position in DSP chain for visualization?

Reply #2 –
First I think the visualisation subsystem is quite complex (providing correct data to different consumers or nothing at all when nobody needs it) to be duplicated, secondly a good access to the DSP list of the playback chain would be needed, also it's meant to provide information about what you hear...
But nothing stops anybody from making a DSP component which doesn't change the samples, only provide monitoring visualizations.
Full-quoting makes you scroll past the same junk over and over.

Request: Configurable tap position in DSP chain for visualization?

Reply #3 –
Quote from: Yirkha on
But nothing stops anybody from making a DSP component which doesn't change the samples, only provide monitoring visualizations.
Are you saying that a single plugin can act both as a DSP component and a visualization component at once? Or are you simply suggesting that I create a non-managed window for custom visualizations?

Moreover, how could such a scheme operate to supply data to the existing visualizations (which I'd have no intention of uselessly rewriting)?

That said: I'll admit to obviously not knowing much about the internals of the DSP chain implementation, but it superficially seems as if both your and kode's objections are beside the point. That RG is done before DSP, or that the visualization and DSP chains are complex, does not change the fact that the fundamental data type of the audio data is invariant both before/after DSP is applied, as well as before/after RG+preamp is applied. Perhaps UI interactions in the visualization chain cause side effects which cause trouble when moved around, I dunno. But it's hard to understand why this (grossly simplified pseudocode) wouldn't work:

Code: [Select]
AUDIO_DATA* x;
bool alt_vis;

if (alt_vis) apply_vis(x);
apply_rg(x);
...
apply_dsp(x);
if (!alt_vis) apply_vis(x);


.. if this does:

Code: [Select]
AUDIO_DATA* x;

apply_rg(x);
...
apply_dsp(x);
apply_vis(x);


I'll stop second-guessing y'all now - I just wanted to clarify my lack of understanding of why this is harder than I thought.
 

Request: Configurable tap position in DSP chain for visualization?

Reply #4 –
Quote from: Axon on
Moreover, how could such a scheme operate to supply data to the existing visualizations (which I'd have no intention of uselessly rewriting)?
It couldn't. The visualizations are created externally (i.e. as the result of instantiating a UI element or popup window from a menu command) and request data from the visualization manager. Your idea would only work, if they were instantiated and fed data by the visualization manager. Or to put it another way, unless the visualisaton API and the implementation of the existing visulizations is changed, visualizations will only display the single data feed provided by the visualization manager.

As far as I know, the major problem with visualization is to synchronize the audio playback and the visualization display. Moving the tap position to within the DSP chain or in front of it makes this problem more complex, because a DSP does not need to have a fixed delay. Think of DSPs that insert or remove audio data, for example silence. On the other hand, if you grab the audio data after the DSP chain has been applied, you only need to worry about the delay of the output device.

Another minor problem is that the DSP chain is applied in the same way for playback and for other tasks like conversion where visualization is not desired or even possible (multiple tracks processed in parallel). Using different code to apply DSPs for playback and conversion would be at least inconvenient.