IR loader plugin issue about pipedal HOT 16 CLOSED

from pipedal.

I've been fiddling with some of them, but till now no luck as said above. Anyway, if something like that could be implemented into pipedal, the whole thing would be just awesome. Or maybe a side panel to load custom files/parameters, that then would be available as presets in the pipedal interface. Just a thought...

from pipedal.

Now there are :-) The new 1.1 release of PiPedal includes the TooB Convolution Reverb, and TooB Cab IR plugins.

There's also support for file selection and upload for 3rd-party plugins that have atom:path properties. The plugin you mentioned does not; but there may be other plugins that do. You would be looking for an a rdf:property; with rdfs:range atom:Path.

e.g.:

toobimpulse:impulseFile
         a rdf:property;
        rdfs:label "File";
        rdfs:range atom:Path.

Probably not that common, but it is a part of the LV2 standard, and at least three plugins support it (two of them mine).

from pipedal.

Thank you very much for your effort to bring the idea to life!!!!. But as far as I can see the plugin seems ...CPU hungry? Easily, it hits over 70% CPU power... Is this OK, or am I missing something here? Also, I had to increase the buffer,
as I had serious Xruns issues...

from pipedal.

Yes, it's monstrously CPU hungry. On a Pi 4, it should be ~20-30%. And you ideally want to limit the length of the impulse to < 2 seconds using the MAX T control. What are you running on?

from pipedal.

I'm on a pi4B and interested in loading mostly instrument IRs, so short IR lengths are not much of a problem, indeed. But I also have some good reverb IRs here which the plugin loads just fine, albeit with the CPU averaging at about 85%.

from pipedal.

It depends. If you're using the CPU use displayed by PiPedal, I would be alarmed. It shouldn't be that high. If you're measuring CPU use using htop, or an external utility that is completely expected. If you're using an external utility, that would be 85% of 400% (since there's four cores). There's a flurry of huge FFTs going on in background threads; the only thing that matters is whether the audio thread has time to breath. And conveniently, that's what pipedal reports: what percentage of CPU is being used on the audio thread. I have seen the Convolution Reverb run stably at 150% CPU use with my longest reverb IRs, which are probably not as long as yours.

Also, cranking Max T much beyond 4 seconds is unexplored territory. What I would expect: Max T= 2 seconds: uncomfortable... 4 seconds: survivable; beyond that: not explored, but it may not be pretty. Convolution reverb is a hungry beast.

Furthermore, if you truncate the IR, TooB Convolution Reverb uses feedback to approximate the rest of the reverb tail. I think you'll find that most of the character of a reverb IR is well-captured in the first 2 seconds, and that truncating it will not make a lot of difference. In my experience. In fact, using just 0.5 seconds of the IR produces nice reverbs, although they don't necessarily reproduce the original faithfully.

If that doesn't address your issue, I have some questions. It may not. Scheduling of the background FFTS is -- to be honest -- a bit fragile, and perhaps excessively tuned for my Pi 4.

• How long are the reverbs?
• have you increased Max T?
• Is your Pi4 running at 1.8GHz or 1.5ghz? (The CPU frequency is displayed at the top of the settings dialog).

from pipedal.

OK... running at a lower sample rate seems more realistic. I was running the sound card at 96KHz with CPU averaging @85% with 3sec tails. At that point, I had to increase the buffer to at least 256/4 as I had lots of Xruns. Also, I had the feeling that the pi (1.8GHz) was running toward its thermal limits... Now @48khz, things are a lot better and 44100 seems rather an easy task for the pi, with CPU maxing @ about 15-20%.

from pipedal.

Also, turning MaxT down @about 0.8sec, or even 0.5sec seemed to make no real difference to instruments IRs, which by nature are mostly short. However, in doing so, the CPU usage was far better.
And by the way, while using Calf reverb, I noticed several VUmeters popping up around the panel... This was not happening with the previous version.

from pipedal.

That would be the "Displays LV2 output ports" feature of the 1.1. release. :-)

Running at 96000hz: yep. Mystery solved. That's not going to work with this effect, unfortunately.

Re thermal limits: That's why the temperature is displayed on the bottom of the screen by default. The thermal limit is either 70C or 80C (I'm not sure which). If you don't have a fan. It's a $5 investment, that's totally worthwhile. I'd recommend buying two or three, because the bearings wear out in a year or two.

If you don't have a fan, try orienting the pi so that the board is vertical. I've seen reports that doing so reduces CPU temperatures almost as well as a fan. With a fan, I'm running at between 50C (any of the default presets) and 60C, with Convolution Reverb maxed out.

from pipedal.

Yes, a fan seems a good investment. (...) I wonder what your soundcard settings are. I assume you use 48KHz, but do you mind if I ask about the buffer you use and the resulting latency?

from pipedal.

I'm currently running 48k 32x3. I haven't had time to incorporate the convolution reverb into my stage rig yet. I suspect I might have to bump it up if I do. If those measurements are still accurate, I'm getting 4.8ms latency, which is ok. Anything under 10ms is theoretically imperceptible.

You can find actual latencies, measured using cable loopback, here: https://rerdavies.github.io/pipedal/AudioLatency.html Those figures might depend on what sound card you're using. I'm using a Motu M2, which is pretty much top of the line. Beside latency, SN/R and noise rejection really count when you're using guitar plugins The M2 has insanely good SN ratios and noise rejection ratios.

Cable loopback is the gold standard for latency. Most latency figures measure only the software buffering time. So you should not compare those figures against others, unless they are also using cable loopback. Using a cable to measure latency includes all of the OS and hardware latency, which is not insignificant.

As the table shows, the relationship between buffer time and actual on-the-guitar-cable latency is not straightforward. According to ancient Linux lore, USB audio buffers should be a multiple of 48, because USB audio is transported in 48-byte packets on the USB cable. Under older versions of Linux, USB audio flat out would not work if you didn't use x3 buffers. However, the entire USB audio stack was rewritten in Linux 5.15, and it's not clear that the x3 rule means anything anymore. I suspect not.

The page above gives instructions on how to do your own latency testing if you're obsessively interested. In my experience, guitar players always are. I would be interested in the results if you do run the test.

from pipedal.

Thank you for the above!! Also, I noticed that by bypassing the convolution plugin, the CPU remains high. Wouldn't that be extremely useful if bypassing an effect, this particular effect stops consuming resources from the CPU?

from pipedal.

I do agree. Unfortunately, LV2 plugins don't have a way to reset the plugin without recreating them from scratch.

The downside of a hard bypass without reset is that when you un-bypass the reverb effect, you get the tail of the reverb from before it was originally bypassed it, which is pretty dramatically unpleasant. (Been there done that, the current implementation reflects that)

To do it, I'd have to rebuild and restart the effect chain, which causes an even worse discontinuity.

I'll take it under advisement, but my current leaning is that it's not a good idea. The priority for bypass is minimal glitches when bypassing an effect while performing, I think. I'm not sure if I do pop-elimination when switching bypass. If I don't, I definitely will in a future release.

from pipedal.

ps. it might be a good idea to switch this discussion to the discussions thread. I need to close the this issue, at which point it will more-or-less disappear from view.

from pipedal.

Thank you!!

from pipedal.