Great effort for someone new to Pd!. I haven't tried using it yet, but I see a couple of things that could be changed. First, it also uses the 'unauthorized' library (I assume that's where [spigot~] is supposed to come from. If you want to eliminate that dependency (since it seems you're not using anything else from that library), you could just replace [spigot~] with [*~], which will do the same thing by multiplying the signal by zero or one.

Also, you don't really need 8 copies of the "row" sub-patch; you can make it an abstraction by putting it in a separate file and using creation arguments. You may not have learned about creation arguments yet if you're new to Pd, but they can make your life a lot easier by avoiding a lot of duplicate code. Notice the '$1' in the screen print above. It represents the first creation argument ($2 would represent the second, etc.).

And finally, I had to add [declare -lib ceammc] to the top-level patch, or the objects in the Ceammc library wouldn't be loaded. This may be a quirk of the Windows version of Pd, I'm not sure (I don't own a Mac). But I've found that the [declare] object is needed for some external libraries, although not all. I've never been able to figure out why some libraries require it and others don't. Seems it isn't necessary on a Mac. I like to add it anyway, to make the patch more self-documenting and to remind myself which externals are required.

@Il-pleut Beware of 'academia.edu'. Whatever you do, don't register on their site, or you'll start getting all sorts of spam from them, with subjects like "Are you the author of blah-blah-blah?".

https://www.reddit.com/r/AskAcademia/comments/bsuxe6/what_exactly_is_academiaedu/

https://www.quora.com/Is-Academia-edu-a-scam

https://www.forbes.com/sites/drsarahbond/2017/01/23/dear-scholars-delete-your-account-at-academia-edu/?sh=4fd6e37f2d62

@whale-av said:

@dfkettle That's unfortunate.
Maybe try Asio4All...... https://www.asio4all.org/....... as a universal driver for Pd and Audacity.
It will have a settings window...... individual for each application..... so try to keep them as identical as possible.
It will give you lower latency and allow you to use multiple soundcards so it can be useful anyway.
David.

I don't think that's an option for Audacity, at least not under Windows. It uses PortAudio for all three "hosts" (MME, Windows DirectSound or WASAPI), as you can see in the screen capture above. I have to confess that I don't really understand the difference between audio "host" and "driver", though, as they're called in Audacity. Maybe there's a way to tell Audacity to use ASIO4All, but I don't know how. I already have ASIO4All installed, I use it with other programs.

So I tried a three-way comparison. I played the file back in Audacity, my patch and WIndows Media Player. None of them matched, they all varied in frequency, although Audacity and WMP came the closest to matching. Any thoughts on that?

@ddw_music said:

At this point, I'm pretty well satisfied that Pd's behavior is fine, and your patch is doing the right thing. So the real point of this test is to find out the boundaries of Audacity's correct behavior, not really anything else.

Likewise, although I'm a little surprised, given that Audacity has been around for so long, and since I'm playing back at the same sample rate no interpolation is required. It's just sending the sample data in blocks to the audio driver or host. Maybe something to do with the latency setting? I'm just letting it default, I've never played around with it before.

I'm going to create another file in Audacity at a SR of 48000, then try playing it back at 48000 in both. Maybe I'll have better luck. I'll also try using a different driver (audio host?) in Audacity.

@ddw_music said:

@dfkettle said:

Edit: My audio interface is running at 44,100 (a Steinberg UR22), and so are Audacity and Pure Data.

@ddw_music I ran your test patch and it seems that 'phasor~' runs a tiny bit slow on my machine

Nope.

Pd's control block resolution is 64 samples. [timer] can report only on 64 sample boundaries.

Now... what is 44100 / 64? ... It's 689.0625.

This is not an integer.

Therefore there is no way, at 44.1 kHz, that a number of control blocks can add up to exactly one second.

When I did it in the morning, my internal soundcard supports only 48 kHz... which is a multiple of 64.

Gotcha. I changed the SR to 48000 and now the test shows exactly 1000 ms.

There will be no deviation in pitch based on the divisibility of the sample rate. That isn't how soundcards work.

even though the CPU usage is only fluctuating between 5 and 15%.

That isn't how soundcards work either.

I know that, but I thought maybe the CPU might be too busy and the data wasn't being sent to the audio interface fast enough. So I checked the CPU usage in the Windows system monitor.

@seb-harmonik.ar said:

@dfkettle ok well it seems like other people have had the exact same problem on windows with audacity and you're assuming the only reason why your sound settings are messed up is explicitly changing the sample rate. If you read the posts you'll see that one person had to reinstall some audio drivers. Sometimes OSs and programs don't work together exactly as they should.

So I'm starting to think this could be a driver issue. In Pure Data, I have the choice of using MMIO or ASIO. I was using MMIO (ASIO doesn' seem to work at all). In Audacity, I have the choice of using MME, Windows DirectSound or Windows WASAPI (all of which use PortAudio); I was using MME. Could this explain the problem? It would make sense to use the same host for both, but they don't seem to offer the same choices, so I'm forced to use different ones.

@seb-harmonik.ar said:

Now, the issue is not so much recording in Audacity as it is playing back in Audacity. Did you look at the link I posted above and the link from other David? What is your current system device playback sample rate?
edit: to clarify, it could very well be that audacity is generating plucks for 44,100 samplerate but playing them back at a higher one.

I don't know why it would play back at a higher rate, unless I changed the SR, which I didn't.

Edit: My audio interface is running at 44,100 (a Steinberg UR22), and so are Audacity and Pure Data.

@ddw_music I ran your test patch and it seems that 'phasor~' runs a tiny bit slow on my machine, even though the CPU usage is only fluctuating between 5 and 15%. I ran the test several times, and it consistently reports 999.909 instead of 1000. Would that be enough to cause a perceptible drop in pitch? I'm not sure of the arithmetic to figure that out.

Edit: Actually, I guess this means it's running faster, right?

I'm not sure how many of these comments are addressed to me or the other David, but in any case, I'm getting a little confused. To get back to my original post (and ignoring the issue of guard points, which I know is important but not really relevant to my question), I'd like to reiterate:

1. I didn't use Audacity to record anything, I just used it to create a sound file with one of the built-in UGEN's (create a new track, then click on 'Generate->Pluck...' in the toolbar). Really, the file could have originated anywhere, and whether or not there were timing inaccuracies when it was created is completely irrelevant. I'm just comparing the way it sounds when played back in Audacity vs. when it's played back in my Pure Data patch.

2. Someone asked me "how much is it off by"; I'm not sure how to answer that, except to say that it sounds about one semi-tone higher in Audacity than it does in Pure Data, although I don't have a very good ear for pitch. (If the problem was in Audacity, wouldn't the frequency be lower in Audacity than in Pure Data or is that an over-simplification?)

3. I don't think I mentioned this, but I'm running both on the same computer, a HP-P6230F (with a quad-core processor running at 2.60 GHz running Windows 10 64-bit). I was going to provide a link to the specs on the HP web site, but they seem to have removed the page (it's an old computer). I'm running Pure Data 0.53.2, 64-bit, and Audacity 3.2.5, 64-bit.

4. Also not previously mentioned, I tried running Pd in both real-time and non-real-time mode, but it didn't seem to make any difference.

I appreciate everyone's help, but can we limit the discussion to my original question and ignore other issues like guard points, interpolation (which I don't think applies to my question, since I'm playing the file back at the original speed) and problems related to recording in Audacity? They probably deserve a thread of their own, anyway.

@lacuna said:

clocks are famously inaccurate

As I have been writing, this is what we assumed - and still might be most likely, but as far as I remember Audacity on a Mac has been involved in the post-production, too.

I didn't record the file with Audacity, I used the generate function (Generate->Pluck... in the main menu). So I don't think the clock would even be involved in generating the file. Playing it back would involve the clock, I guess, but the file is only one second long. The clock would have to be very inaccurate to produce a noticeable difference in such a short period of time.

@ddw_music said:

I rebuilt the essential logic in your patch and I get dead-on accurate pitch between Pd and Audacity.

I don't really see any difference between your patch and mine, apart from the fact the you hard-coded the name of the file and replaced the horizontal slider with a constant value of 0.1.

As for the missing guard points (even though they don't explain the difference in frequency), I loaded the file (which has exactly 41,000 samples in it) using [soundfiler] and the "-resize" option. So I guess [soundfiler] doesn't add guard points. Should it?

@lacuna That wouldn't explain the difference in frequency, I don't think. It might cause a click at the start, that's all. And as for the sample rate, both Audacity and Pd were running at 41000. Did anyone try running the patch? Links to the patch and the sample file are attached.

While working on a sample player, I noticed that the sample sounded slightly different when played through Audacity and when played through my Pd patch. It's hard to notice the difference (unless you have perfect pitch, which I don't), but when played through Audacity, it has a slightly higher pitch. If you play them both at the same time, the difference is obvious.

So I extracted just the essentials from my patch to illustrate. I don't know if I'm doing something wrong in my patch, but I don't see any problem. I used Audacity to create the sample in the first place, which is exactly 44,100 samples long, at a sample rate of 44,100.

Anybody see any problem with my patch?

Patch: https://drive.google.com/file/d/151cvF_9_4ViebScR_zOS-IRaQXok0XIJ/view?usp=share_link

Sound file: https://drive.google.com/file/d/18UyB1o6mOfS1oW2OhIUtpA1KdJhHBTm9/view?usp=share_link

Thanks. I was just looking at the examples to try and understand them, assuming they would still work. I'm guessing that some change was made to Pd since they were posted here 5 years ago that caused some things to break. One of the risks of relying on undocumented features, of course. There's nothing in particular I want to do at the moment, except to get a better understanding of how dynamic patching works.

Do the examples in the zip file from 5 years ago still work in the latest version of Pd? I'm getting the errors below when I try '5.examples/2.create_new_abstract.pd'. I'm running Pd v0.52.2 under Windows 7 SP1 (64-bit). (Please don't ask why I'm still running Windows 7!)

Thanks.

@jameslo I guess it's more complicated than I thought. It seems it would also depend on whether you're listening to speakers or with headphones? The article only talks about listening on speakers in large or small rooms. The -4.5dB law uses both square root and sin/cos functions, though, not just the square root, as described in the book I mentioned.

I should have explained what I'm trying to do. I want to develop a patch in which the sounds move back-and-forth across the stereo field, their position isn't static. I want the movement to sound as natural as possible, though. I'll just have to experiment, I guess.

P.S. The square root method is described in "Programming Sound with Pure Data" by Tony Hillerson on pp. 89 - 90 of the 2014 edition, if anyone wants more details. I couldn't find anything about equal power panning in Miller Puckette's book, "The Theory and Technique of Electronic Music". But if anyone knows of any books or articles that deal with the subject, please let me know.

@jameslo Interesting article, but it doesn't say how it's calculated, it just refers to the amount (-3. -4.5 or -6dB). I don't have to be concerned about converting to mono, either. If I wanted a mono version, I'd just create it as mono in the first place. But thanks.