Hello,

When running mthe master stereo output of my patch into [writesf~ 2], I don't hear any crackling while running the patch itself, but I do hear it when I playback the .wav file (at the same volume). Looking at the task manager during the recording, I'm not exceeding 13% CPU or 31% memory usage. I've tried recording 16-, 24- and 32-bit .wav files. Otherwise, I can note that the sounds in question are contrabass sounds run through a [vcf_bpc~] filter. The crackling appears at the height of dynamic envelopes, although, according to the main window's monitor bar (and in-patch vu-meter), I'm not hitting the amplitude limit. Also, I'm using a step=wise cue-list to control the patch's progression by pressing the spacebar. Any idea what the problem might be? I wonder if it's related to this post:

http://forum.pdpatchrepo.info/topic/4749/writesf-range-issue

Thanks in advance,
Elliot

@s.elliot.perez Yes, some of the other post talks about this. All values for audio have to be between 1 and -1 to avoid crackling (digital distortion). There is no soft clip in digital audio so if you have output that swings beyond those limits the best solution is [limiter~]..... but only for extended.
If you are using vanilla you could write the file first to an array, and then send the message [arrayname normalize n( where arrayname is the name of the array, and n is the range to normalize to (usually 2). That will do the same as normalize in any other audio program..... adjust the gain of the whole track so that it does not exceed the limits, and is a better solution if you want to preserve the dynamics..........
Then write the contents of the "normalized" array to [writesf~]
If you write the output to an array, or use "edit" "magic glass", you might see better where the problem is than with a vu meter. Maybe there is a big dc component to your audio? Also try the vu meter with [puv~ 10 400] which will give a quicker response than [pvu~].....
There might be some other solution for vanilla........
David.

@whale-av said:

@s.elliot.perez Yes, some of the other post talks about this. All values for audio have to be between 1 and -1 to avoid crackling (digital distortion). There is no soft clip in digital audio so if you have output that swings beyond those limits the best solution is [limiter~]..... but only for extended.
If you are using vanilla you could write the file first to an array, and then send the message [arrayname normalize n( where arrayname is the name of the array, and n is the range to normalize to (usually 2). That will do the same as normalize in any other audio program..... adjust the gain of the whole track so that it does not exceed the limits, and is a better solution if you want to preserve the dynamics..........
Then write the contents of the "normalized" array to [writesf~]
If you write the output to an array, or use "edit" "magic glass", you might see better where the problem is than with a vu meter. Maybe there is a big dc component to your audio? Also try the vu meter with [puv~ 10 400] which will give a quicker response than [pvu~].....
There might be some other solution for vanilla........
David.

I'm using Extended. Interestingly, I had the same problem with a limiter, but I'll try your other suggestions. Thanks.

@s.elliot.perez Hello again......
(Just in case)......... when I first used [limiter~]........ because it created just fine I assumed that it would do what it says and limit the signal......... I never looked at the help file....... and it didn't work.
The arguments and external delay are necessary to make it work and I was surprised that they were not built into the object itself..........
David.

@whale-av I use an abstraction taken from an old professor of mine. limiter.pd

@whale-av

As before, I still get the clicks in the .wav file, even when the limiter in the above attached abstraction is activated. I have tried monitoring the output with [prvu~ 10 400], setting up print objects with [unsig~] and [env~], and using [tabread~] to examine the output (post limiter) in an array (pictured above), but it looks fine (though I'm not really an expert on using arrays). I'm not sure what you mean by a "big DC component". I don't hear the clicks when the music is being produced in PD, only on the .wav file... and I'm really at a loss.

@whale-av Alright, I tried to isolate the problem and, apparently, it has something to do with freeverb~ (dry 1, wet 0.2). When I bypass it, the .wav file doesn't have any clicks on it. Does anyone know anything about this?

@s.elliot.perez Hmm... and windows! I know that osx can have automatic level adjustment applied to its audio api........
Is your patch simple enough to post? or would you rather not do that?
I was about to ask you to post a little of your recording, but it will not tell us much.
Have you set a samplerate for [writesf~]?....... because it gives the file a header but does not re-sample........ so if you tell it 48k but Pd is running at 44.1k any playback (on another program) will be very distorted........ probably not..... you said distortion only on the peaks of the envelope which was what made me think "overload".
I will build a patch with [freeverb~] to see what might be going on..........
... so with a track normalised at "1" I am getting peaks over "2" at the output of [freeverb~] with the dry at "1"....... could you try it with dry 0.5... wet 0.1.......
It says in "more info" in the help page that wet and dry cause clipping at high levels as they are added together.........
David.

@whale-av
I haven't set a sample-rate for [writesf~].

The patch is not very simple, I don't think, but I've stripped it down to a single part (where the problem is at its worst). You'll get some error messages due to missing files, but that shouldn't affect the problem. Unzip the files into one folder. Open "@layout.pd". Press "r" to reset, then spacebar to start the patch. Give it a moment to stabilize (this isn't normally the beginning of the patch). Then click the bang (as noted) to start recording. recordingglitch.rar

Thanks for your help.

Edit: Ah, I just saw your reply. It's still strange that the clips aren't audible in PD, but only on the .wav-file... but yes, I'll experiment with different levels tomorrow.

@s.elliot.perez so........your limiter does some weird stuff.... there are conflicting messages to set its parameters and if I compare the "limited" output to "unlimited"........ apart from them sounding completely different........... they look like this...........
limiter off... with the (input) signal at about 0.5 maximum......

limiter on... with the (input) signal at about 0.5 maximum......

...... same input!.........(at different times obviously) but there is something wrong. I will try to look into that! i.e. I will take a really close look at your limiter!!.....tomorrow!...........

However, I think that despite your playing all of your samples from ram ([soundfiler}) you have a very large patch that carries a heavy load, and when you try to write the output through [writesf~] your computer (maybe) starts to have some timing issues.

The files that I have recorded on a MacBook pro I7 @2.3Ghz+ have no "crackling" issues, and your patch reports cpu usage in the range 0.1 to 1.5...... (the [cpu] object)......rather than 13%.... but sorry.......I have no idea what that really "means"!

Can you try it on a more powerful computer? Be aware that any redrawing can be a problem... on my computer I have some "crackling" when I drag some of the faders In your "modules"........ even in the "live" sound output.
ALL screen interaction is BAD in Pd........
David.

NEWEST EDIT: Very strange stuff. I don't get crackling with the values "dry .6, wet .1" OR "dry .5, wet.2", BUT I do get crackling with the values "dry .55, wet .15". I went back to an older version of the full patch, where I have the limiters off, GUIs showing and I amplify the final output by 1.5. In this case, "dry .5, wet .1" works but "dry .6, wet .1" does not. [cputime] shows low values.

The GUI faders aren't meant for usage during "performance" or recording, but rather for testing different parameter variations more easily and visualizing the cue-list actions (to help me see mistakes). However, I can make versions of the modules without GUI if needed. I've heard before that it can slow things down. However, the clicks appear on my .wav files even when no changes in the GUI are occuring (except for the [vu] meters and number boxes).

EDIT: Question; do currently non-displayed graphical objects affect PD's efficiency? I.e., is it enough to uncheck "Display on Parent Patch" (and not open the abstraction) or do I need to remove the graphical items completely from each abstraction?

EDIT: I'm using a Lenovo with an Intel i7-3632QM @ 2.2GHz, 8 GB ram. and a solid-state drive. The [cputime] object mostly shows low values, but at one point as high as high as 60-71%, although Window's Task Manager's CPU did not approach these heights. I unchecked "graph on parent", closed and re-opened the patch and the [cputime] object again showed low values. However, I'm not sure what to make of this. Putting the sound through [freeverb~] still causes clicking on the written file and bypassing [freeverb~] still removes it.

It looks like I have to retract my previous hypothesis that the problem is only present when [freeverb~] is used. I presently have found the recording error to occur without it as well. It does seem to be related to cpu and possibly amplitude. While the cpu ([cputime]) generally stays around 20 or lower, there are occasional leaps up to the 40s/50s.

@s.elliot.perez I have almost the same system as you then.. I have half the ram and a hard-drive.... so not as much performance, but still I cannot replicate this recorded crackling...... unless I seriously overload the audio out.
So, could it be simply that Pd is giving priority to your sound card and dropping bits that should be sent to the recording....... ? I really do not know.
You could try really relaxing the setting for the buffer (delay setting in audio settings) for your sound card....... bump it up to a big number... 100, 200, 300?
"Clutching at straws" in English.......
David.

@whale-av Well, something's different on my computer if [cputime] shows 1.5 for you and 50 for me (see my previous post). The strange thing is that the Task Manager doesn't show such high values.

@s.elliot.perez No you can leave the graphical items....... it is mainly arrays that cause problems, but only when in a visible window.
Yes, task manager never shows the same values, especially as Pd is usually 32 bit and using only half of the core. Also it is supposed to be a percentage of Pd's dsp capabilities (I think) rather than cpu usage...........
Also I am missing some of your sounds (although that will make little difference) and some of your patch?
What is your sound card?
How are you playing back the file? Through the same sound card? Does it make any difference if your patch is closed while you play it back? Wrong sample-rate for playback? Can the player not cope with 32-bit playback?.........
David.

@whale-av Oh no. I've been playing back the files with VLC. I just tried with Windows Media Player and I can't hear the crackling.

It looks like I've wasted your time, I'm horribly sorry. I'd never had such a problem with VLC, so I hadn't considered the possibility. I'll have to see if I need to adjust VLC's settings, or just stop using it altogether.

@s.elliot.perez No time wasted ever with Pd......... just a lot of things learned!!!
I am very pleased though that it can be marked as "solved"..... it was a hard one!
Enjoy your patch!
David.

@whale-av Thank you for your kind words and your helpfulness. It's true that I learned a few things. I still don't know why this error happens with VLC, as it doesn't occur with other .wav files not made with PD. But it must be a VLC limitation, as WMP playback is unaffected.