I just learned about the Modified Discrete Cosine Transform (MDCT) and I see that it's not only used in mp3 compression, but is also often applied on overlapped power-of-two windows like an FFT. When I say "learned about" I don't mean I understand it, I just mean "became aware of".

I've always wondered why some of my FFT resynthesis patches, when run under smaller block sizes, have that low bitrate mp3 sound. I would describe it as squeggy bubbling. Are the two transforms related? Is that crappy sound due to something they both share, or is it just coincidence?

@jamcultur I bet the examples are out-of-date, e.g. ch 1.2 of that tutorial says "This tutorial assumes Pd-extended version 0.39 or higher." That was a little while ago!

I was able to fix things by opening up the properties of the magnitude table, changing the size to 32 (which makes more sense than the given value of 100 if it's a real FFT in a default 64 sample block), and saving the patch again. Looking at the before and after using a text editor and you can see that the array declarations are somewhat different.

@ben.wes In my (much less nice) version of the lateral signal pass clone, I didn't use [outlet~]. I just used the final [s~] to get the resulting signal.

@ben.wes That's a great solution to the lateral-signal-pass-among-clones problem, but I would check to see if there is latency at each s~/r~ pair. When I looked into it a few years back I think I found that sending in the opposite direction (i.e. ascending clone index order) was preferable because it had no latency.

@manuels Nice, you beat me to it. Yeah, I thought of the log/exp bit after I went to bed and felt compelled to get up to post it, but then even later in the night I woke up and realized my mistake! When I was working I used to joke that I should bill for the time I'm sleeping.

@inum Here is an example multiplyFactors.zip Please post sound output when you get it running to your satisfaction--I'm curious what you're trying to do.

The efficiency police that patrol this forum will probably arrest me, but here's a very easy way from a coding perspective. Since the [outlet~]s of cloned abstractions sum, it would be great if there was a way to transform summation into multiplication. You're in luck: have each abstraction output the [log~] if its factor, and then on the summed output of the clone, apply [exp~]. In other words, exp(log A + log B + log C + ...) = A * B * C * ....

Edit: aw crap, doesn't work for negative numbers. Can it be salvaged with an extra quadrant signal?

@ddw_music Oh OK, well I redid the test using a 1033.6 Hz sine wave (1.5 cycles/64 sample block) and the result is consistent with a 64 sample shift (i.e. 180 degrees out of phase), plus it goes away when I set plugdata's latency to 0. I'm gonna check on the REAPER forum to see what they say about PDC--maybe the issue is that REAPER assumes a base 64 sample latency for all plugins so plugdata doesn't need to report that portion.

It would still be interesting to see if other DAWs behave similarly. Maybe I have to dig out my old laptop and struggle with Cubase again. 1033.6 Hz sine.wav

BTW, is there a way to set plugdata's reported latency to the host programmatically? I have an FFT resynthesis patch that uses different block sizes. Camomile has that facility.

Update: I think I'm seeing the same behavior in Audacity, but my understanding of Audacity is weak. I also tested an FFT resynthesis patch in REAPER using a 16384 block size and set plugdata's latency to 16320 (16384 - 64) ; that produced the alignment I was expecting. So I'm provisionally declaring that you should set plugdata's latency to the latency of your patch as measured between adc~ and dac~. In retrospect that seems completely obvious, but I was thrown by plugdata's default of 64.

plugdata sets its reported latency to 64 samples by default and appears to tell REAPER about it. REAPER then tries to correct for this latency using its plugin delay compensation scheme. 64 seems reasonable, right? That's what one might expect as overhead just to get signal into plugdata and back out again (e.g. it takes at least one buffer for Pd vanilla to shuttle signal to/from its own [pd~] subprocess).

But that's not what I'm seeing! I made a track that is silent except for a single 1 in the 2nd or 3rd sample, and have inserted a plugdata plugin that connects [adc~] directly to [dac~]. At 64 samples of latency, if I render the track, the output is completely silent. If I change plugdata's reported latency to 0, the output matches the track.

<spooky music/> Um ... wh-wha-what's going on?

What do you see on your DAW? impulse.wav passSignal.pd

@nicnut You could test @whale-av's hypothesis by inserting PocketMIDI (https://www.morson.jp/pocketmidi-webpage/) in between your controller and Pd and watch the traffic.

@ddw_music I think you mean terminator, not status byte. I'm using [fudiformat] to generate the body of the sysex message, so I just omit the -u flag and scan for the colon and newline.

Edit: I just looked it up. The spec lists F7 as a status byte, so I guess sysex has two status bytes. Confusing.

@timothyschoen Well that was fast, thanks! One correction though: as a plug-in, plugdata passes the status byte. It doesn't when running stand-alone.

@oid I can't quite understand what you're asking, but is this useful?

@dreamer Thanks. That looks to be a different issue, but if a no one else points out how my expectations are wrong then I'll file a report on github. Windows 10, plugdata 0.8.3, REAPER 7.16

I love how something from less than a year ago is "very old" Time is definitely speeding up as I age.

It appears that PlugData's version strips both the status byte F0 as well as the terminator F7, whereas vanilla passes both (0.55-0 and 0.54-1). I don't think I'm confusing a vanilla object with an else object, am I? What else could I be overlooking? You can confirm it with this if you want sysex recording test.pd

PS: I tested as standalone as well as a VST3

Agreed, and also check out Pd help, in particular Help->Browser->Pure Data->3.audio.examples->B08.sampler.loop.pd, for pitch control. Start with a frequency of 1 and a chunk size of 100.

FYI, if you want a snake out of tabread4~ but are assigning the source arrays dynamically, do yourself a favor and at least provide dummy table arguments in your declaration. If you don't, tabread4~'s output will always be a single channel, no matter how many tables you try to set afterward.

There! If you are as slow as I am, I just saved you 2 days of head scratching. I would not be surprised if this was also true for tabread~ and tabplay~ but I didn't test. Oh, and I'm running Pd 0.55, although I started this patch a version ago where I probably had the same issue but couldn't hear it due to other even worse issues

@ben.wes Confirmed on Sonoma 14.5 with Pd 0.54.1

@ben.wes That's a super-interesting read, thanks. It made me aware of cyclone/wave~, which in turn made me aware that Pd's interpolator is Lagrange, which appears to be not exactly the same as what's called cubic interpolation? 5 minutes with Google suggests that cubic interpolation is differentiable everywhere, whereas I think Pd's interpolator has sharp slope reversals.

Sometimes when you do time-stretchy/pitch-shifty things like in B14.sampler.rockafella.pd, when you return to normal time/pitch you are left indexing in-between samples using tabread4~. That's gotta introduce some fidelity loss, no? Has that bothered you enough to make you write something clever to get the indexing back to integers? If so, please share!

Here's a little test I wrote to see if I could hear the difference: sound quality test.pd . Load whatever sound you think would clearly expose lo-fidelity playback. You can compare integer indexing with fractional indexing and adjust the fraction. I think I hear a difference but I'd have to do a bunch more work before I'd declare I do and I'd rather ask you kind folks first. Plus I think you'll find it fun to try to hear the difference.

@WEIRD1 Here's one way (which could fail on 100% very very infrequently):