• jameslo

    Thanks. I verified that the blocksize chosen under Audio Settings doesn't affect PD's global blocksize, which is surprising. But I'm trying to understand what you mean about jitter. Is this the test you're suggesting?

    image.png

    If so, I get similarly jittery results no matter what Audio Settings block size I choose. But more to the point, isn't this "jitter" irrelevant? It's just a function of how fast the computer processes each block, what else it has to do concurrently, and how frequently it has to fill the audio interface's output buffer. The fact that each block is processed at irregular intervals isn't necessarily reflected at the audio output, right?

    posted in technical issues read more
  • jameslo

    Another thing I don't understand is why the gain reduction is calculated in terms of power instead of amplitude. The next two examples, a compressor and a vocoder, both use amplitude. Is there something special about noise gating? I modified the noise gate to use amplitude instead (by moving the sqrt~ up to just after the sum of squares) and it sounds just as good to me.

    posted in technical issues read more
  • jameslo

    @oystersauce Ah, that's it. I use the 32 bit version (to stay compatible with some old software I can't part with yet).

    posted in technical issues read more
  • jameslo

    @oystersauce 0.49.0 -- my understanding is that this is the latest version for windows, and that the 0.49.1 version just fixes an installer bug for Mac.

    posted in technical issues read more
  • jameslo

    @oystersauce Hmm, Deken finds "moonlib" in both my Windows 7 and 10 installations. I have a faint memory of having to update Deken (using Deken!)--maybe try that?

    posted in technical issues read more
  • jameslo

    Why is 15 a reasonable mask-level value in the example Help->Browser...->PureData/->3.audio.examples/->I04.noisegate.pd? Mask-level multiplies the frequency-indexed average noise levels contained in the mask table before they are used as gate thresholds. I'd expect that 1.5 would suffice and that 15 would exaggerate the gain reduction so much that it would leave unintended artifacts, yet that's not what I hear. For values between 0 and 4 I hear mp3-like chiming which goes away above 6. Miller Puckette discusses the algorithm in Theory & Technique of Electronic Music ch 9.4.1, but there's no mention of scaling the threshold function f[k]. The only thing I can think of is that maybe the distribution of noise powers for each frequency over time is so broad that you need a factor > 6 to include most of them?

    Update: if I bypass the q8_sqrt~ things behave as I expect them to. I don't understand why he's taking the sqrt anyway--there's no mention of it in the gain equation g[m,k].

    posted in technical issues read more
  • jameslo

    @Load074 On my systems, I don't even need that "Test Audio and MIDI" patch open to make it fail, and it doesn't take much fader wiggling either. But if you can't make your system fail, then that's good news for you, no?

    posted in technical issues read more
  • jameslo

    @whale-av Yes, I tried two different ways using a combination of subpatches and abstractions, neither worked. So that's why I tried testing PD with nothing but the parent window open--no patch at all!--and PD still stops responding to MIDI after I move several faders at once quickly.

    I looked at the first fader using MIDI-OX and it is sending on channel 1 as configured.

    posted in technical issues read more
  • jameslo

    It never occurred to me to suspect the nanoKONTROL, so thanks for that LucienR and whale-av. I configured my Yamaha 01V96i to output MIDI to PD 0.49 (yes, vanilla) and everything worked fine, which is remarkable because it generates twice as much fader data as the nanoKONTROL. But I think I'd still rather run my patch on pd-extended 0.43.4 than lug this mixer to my show, unless someone tells me that's a bad idea.

    I tried that tip from Berenger (i.e. using a separate ctlin object for each controller) but PD 0.49 still hung. In fact, I can run PD 0.49 with nothing but the parent window open, wiggle the nanoKONTROL faders vigorously, then open the Test Audio and MIDI window to see that PD is no longer responding to MIDI.

    posted in technical issues read more
  • jameslo

    PD 0.49 stops responding to MIDI if I send it a lot of messages, e.g. the output of a Korg nanoKONTROL2 when I move all 8 faders at once, and it doesn't respond again until I restart PD. It happens even when the Test Audio and MIDI window is the only thing open. It happens on Windows 7, Windows 10, and macOS 10.13. MIDI-OX shows that the Korg controller is fine.

    I temporarily reinstalled PD 0.48.1 on Windows 10 to test, and it happens in that version too. I noticed I had left a version of pd-extended (0.43) on that same machine, so I tested it as well--it was fine! So I guess that's the version I have to run with for now. Anyone else having similar issues?

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!