SpectrumAnalyzer playback pause when used on master track

[frescoalfredo]

SpectrumAnalyzer tends to pause playback when used on the master bus (if SpectrumAnalyzer is visible), on playback start. This happens every few times I stop/start playback; there will be a noticeable pause (approximately 1/3 s) before playback starts. My audio device latency is very low (around 5ms RTL) and tested/verified, so that isn't a part of this. I mentioned this to you a while ago on the Reaper forums and since then I've tried this on a few different computers on different operating systems, comparing to other frequency analyzer plugins (the included Cockos one, ReSpectrum). Your plugin seems to be the only plugin that does this. It only seems to happen on the master track, and not on individual tracks or even folder tracks.

[JoepVanlier]

Thanks for reminding me about this :)

I'm still having trouble reproducing this. I've been playing around with it, and on my machine I only see the anticipative FX delay between a channel track and the master bus (the anticipative FX one displaying earlier). I wonder if we are looking at the same effect. For me, the cockos one also has a latency between the folder tracks and master (their Frequency Spectrum Analyzer). What puzzles me is that for you it only happens for this plugin and not for the cockos freq analyzer, since this one is derived directly from it. I want to try and boil it down to a smaller number of things to consider.

Could you check whether you still see the delay when you turn anticipative FX off? Not suggesting this as a fix, but just so I can eliminate things.

Currently, my best guess would be that we have some setting set differently that makes the master wait for the anticipative tracks on your test setup.

One thing I also noticed is that I don't update until I have the first full buffer. I've added in 4.02 that it starts rendering immediately (by setting update to 1 in init).

[frescoalfredo]

I tried the latest version and the same behavior exists.

My Reaper settings are fairly common, nothing odd or "experimental". I recall this happening on a fresh Reaper install as well (default preferences) when I tested it before. Since only a few of my preferences are different in terms of any kind of performance/buffering, I just set those to default and tested again; those settings seem to have no impact on this.

As you suggested, I turned off anticipative fx processing overall in Reaper's preferences, and this behavior stopped. Playback is immediate this way, with the plugin on the master track and with its window open. So I guess that's something. :)

Oh also I noticed a couple things:

1. Apparently new to this version, if the display is frozen with the "freeze" function, and playback is stopped/restarted, some data from the new playback "stream" gets into the display for a moment (making the "frozen" data a combination of both the old "frozen" data, and some new data from playback start).

2. The buttons ">A" and ">B" appear to do nothing whether I click on them after I freeze the display or not.

[JoepVanlier]

So, if it's related to the anticipative FX processing, then the only thing I could do is make an option that lags the ones you have on the tracks by the amount of anticipative FX processing amount that you set (as they are actually ahead). The thing that really confuses me though, is why you're not seeing that difference for the cockos js spectral analyzer, because I do on my end.

As for the other two:

1. Should be fixed now.
2. They probably did something, but I never auto-enabled the MemA and MemB plots whenever those button are pressed. I do think it indeed makes sense to enable them upon pressing >A or >B, since you tend to want to see them when you put stuff in them, so that's added now :)

[frescoalfredo]

Sorry to say that the behavior still exists in the latest version you just uploaded after your last comment. I also tried the Cockos one again just to be sure, and I can't get it to exhibit that behavior (I never was able to get it to do this, on any track including the master).

I hope I don't sound too presumptuous by suggesting this, but ReSpectrum (another JS frequency analyzer) doesn't do this sort of thing, so maybe it would help to compare to its code.

As for the other things:

1. Yes that's fixed, thanks. :)

2. The buttons seem to store what's there on the display, although a couple times I had the stored trace be around 20 dB higher than what was on the display (and a different sort of trace, as though it were measured differently or from a different time, or averaged differently, etc.) I'll let you know if that happens again or if it was just a one-off thing.

[JoepVanlier]

Yeah, the last update was only a fix for 1 and 2. I didn't attempt fixing the other issue since I don't fully understand it yet and can't reproduce it in exactly the same manner it seems.

One difference I see is that I first render to an offscreen buffer. Maybe that has something to do with it? Could you try the following version (just overwrite only that file). It allows you to turn the offscreen rendering on and off:

Test.zip

[frescoalfredo]

I tested the version from "test.zip" from your later post specifically (since the email notifications made it seem as though you'd made a post, deleted, then posted again). With the onscreen buffer at 0 or 1, there is no difference. The same behavior happens. Sorry! :)

[frescoalfredo]

I just tested on my laptop which still has Windows 7, and a fresh Reaper configuration. It seems I can't make this behavior happen on that system.

So I then tried using a fresh install on my Linux system (removing all my configuration files first, and letting Reaper generate all new ones with default settings, then running Reaper without any scripts etc. and just your plugin). At first I thought I couldn't make the behavior happen, but it seems it was just more fault-tolerant (I had to press the spacebar more quickly to start/stop/start the project playback). Some things that seem to make this behavior happen more: anticipative fx processing render-ahead time reduced from default 200ms to 100ms (in "audio"->"buffering"), using lower latency settings for the audio device, and using higher FFT settings in the plugin.

I also noticed when this happens, I get a realtime (RT) xrun being counted by Reaper's performance meter.

So maybe this has something to do with how video displays in Linux versus Windows, or something about RT settings, and so on. I wish I could say. But anyway the Cockos plugin and the ReSpectrum one still don't make this behavior at all, and even while testing under ridiculous circumstances. :)

If you consider this something that's not worth tracking down, I'll understand. I thought maybe I could help narrow it down but at this point I'm not sure that I'm helping you.

Anyway I noticed a couple other minor things while I was testing. :)

1. while zoomed in on the frequency range, stop/restart of playback makes the display zoom "jump" a bit (it zooms slightly out, then in again).

2. after freezing the display and stopping/restarting playback, the "tooltip" for the frequency (and dB) doesn't appear when left-clicking the display (until "unfreezing" the display again).

[JoepVanlier]

The new points 1 and 2 should be fixed now. Hopefully not at the expense of introducing new bugs :D

Reaper's render scheduling is somewhat of a mystery to me tbh.

It's strange though. I do wonder what's bringing this on exactly, but there's a ton of moving parts. How many channels do you typically have active when you're testing and you see the behavior? Maybe it's just an initially not being able to keep up thing. Does it happen for a low active channel count as well?

[frescoalfredo]

When I'm testing this I only have 1 or 2 channels enabled (usually just 1), and I've hidden the sonogram/time view. Having the sonogram/time view visible and having more channels enabled means this happens more consistently when the plugin is on the master track; hiding the sonogram/time view and reducing the number of channels reduces this tendency.

When this plugin is on the master track: if I leave the FFT set to 8192, keep the sonogram/time view hidden, and only have 1 or 2 channels enabled, this tendency is reduced so much that it's difficult to make it happen unless stopping/restarting playback quickly.