I'm currently using an oscillator that has high levels of harmonics filtered by several bandpass filters in parallel to generate formants, and that works pretty well. I'm interested in other ways of generating formants. I've seen old references to fof~ and vosim~, but these objects are old and apparently unsupported. Does anyone know of current versions of these? Or other ways to generate formants in Pd?

@porres I'm using Pd 0.56.2. I tried this on both Windows 10 and Windows 11 and I get the same results. What OS are you using?

I don't add externals to Pd's path. Does else/paf~ expect to find something in the path?

I had to multiply else/paf~'s output by 1.3 to match the level of Puckette's paf~. Is that the same for you?

@jamcultur said:

What OS are you using?

masOS Sequoia 15.7 - but I doubt this makes a difference

I don't add externals to Pd's path. Does else/paf~ expect to find something in the path?

not really, if you don't have errors, it's fine

I had to multiply else/paf~'s output by 1.3 to match the level of Puckette's paf~. Is that the same for you?

no, you can see the screenshot above and the patch. You can get it and show me a screenshot of what you see

@porres With Puckette's paf~, the 528hz peak is -6dB. When I don't multiply else/paf~ output by 1.3, the 528 hz peak is -8dB. When I multiply else/paf~ output by 1.3, the 528 hz peak is -6dB, like Puckette's paf~. This image is with bandwidth=10. The peaks are the same with bandwidth=80.

can you confirm this is from the patch I sent? Did you change it?

why didn't you stick to the same parameters I sent with bandwidth = 10, wasn't that showing more changes?

Anyway, same patch, now with bw = 80, same visual results. I don't think this has nothing to do with you being on windows... it just seems the top one stuck with bw = 10....

the patch now with bw = 80!

!paf-test.pd

@porres I had to add paths to your patch. The result is the same as my patch.

Great! No idea what that was needed, but I guess it's not important now.

Next, I'm adding Multichhanel support like my other oscillators, and it'll be easy to add more formants that way with a single object.

@porres Puckette's paf~ and else/paf~ give different results and sound different. As you can see in my last post, all of the harmonics have different volumes. The second and third harmonics are louder in Puckette's paf~. All of the other harmonics are louder in else/paf~. The differences are even more dramatic with lower values of bandwidth.

@porres You can see the problem in my previous post, but it's easier to see and hear the problem with lower bandwidths. Here are the results using your patch with bandwidth=10.

Oh, I misread your post... at least adding to the path makes no difference as I thought (cause it makes no sense).

One way or another, it's still hard for me to believe something is funny, because I simply cannot reproduce as I've shown many times and it also makes no sense to me that it would behave differently on windows...

@porres There is different code running on Windows than on Mac. That must be where the problem is.

FWIW, I made a module using the implementation of paf~ in F13.paf.control.pd, and it works the same as Puckette's compiled paf~, with the same differences from else/paf~.

@jamcultur said:

There is different code running on Windows than on Mac. That must be where the problem is.

what exactly do you mean?

@jamcultur said:

I made a module using the implementation of paf~

what kind of "module"? How did you "do it"?

please be precise

@porres @porres If the code on Windows was the same as the code on Mac, they would work the same. They don't work the same, so they must be different.

Here's the object I made from F13.paf.control.pd:
mypaf~.pd

And here's a version of your patch that uses it:
1767288702629-paf-test.pd

a comparison of miller's original paf (version 0.07), an abstraction based on F13 and my external. The abstraction is the one at the top and differs a bit. My external matches exactly miller's original and it's actually based on it so it's the same code...

we have to stop going around in circles here...

I see you're getting different results on windows. Makes no sense to me, I don't believe there's something in the code. Unless you have a real suggestion and can narrow something down of find the problem, I can't do anything.

I say let's just put a pin on this...

The object isn't even officially included or done. Let me work on it... when it's time to put the update release out I will have a look at it. Try to run on a VM or something.

oops, I didn't post the image of the comparison

@porres If you can't do anything about it, then you shouldn't call it paf~. Miller Puckette invented paf~. His paf~ is the standard. Yours doesn't work the same or sound the same as Miller Puckette's paf~ on Windows.

@jamcultur said:

If the code on Windows was the same as the code on Mac,

why don't you look at the code and point to what you believe is the culprit instead of just making assumptions. My code is the same for mac, windows and linux... I said so. There's no code just for windows. I can't see why it would compile differently for windows as well, which is something else to consider... and this would mean that probably a lot of ELSE objects behave different on windows, maybe, and I think it's unlikely...

anyway, we can't go around in circles forever so I am moving on with this already, like I said... for now, all I can say is "I can't see what might be causing this", and "I can't reproduce it"... and "this is still experimental and I don't have to do something about it just now when we don't have a clue of what is going on, so let's put a pin on that"

@porres I'm not going to try to debug your code for you. Have you had anyone else try it on Windows? Don't you care whether it works properly on Windows?

@jamcultur said:

Don't you care whether it works properly on Windows?

I do and, like I said... I WILL GET TO THAT LIKE I SAID... AS THERE'S NOTHING TO BE DONE NOW... can you take a moment to breathe and read carefully what I've been saying?

I don't feel you're not listening... you're also not being very helpful...

you're being very annoying actually and saying some funny and wild things by the way like what I should do and how I should call the object.

Let me put it in a different way and be done with this. Right now I actually don't care this is not working for you! The object is still not included officially. It is still experimental and not officially distributed. It is not even completed... So you're gonna have to leave me alone please for the time being, unless you can really help. If you can't, leave me alone please... I see it's not working for you, I got it. Like I said a million times, I have no idea what might be going on... ok? Can we move on?

thanks

@jamcultur said:

If the code on Windows was the same as the code on Mac, they would work the same.

One source of confusion here is the difference between source and object code.

Most of the time, humans never look at the object code produced by a compiler. We only look at the source code. So, when porres says there's no difference in the code between platforms, this is talking about source code.

The source code gets compiled into object code. In Mac vs Windows, the compilers are different, and the CPUs (architectures and instruction sets) are different. If the Mac is using an M-series CPU, then it's impossible for the object code to be the same as Windows (Intel or AMD chip), because the instruction sets are completely different. (That's also not considering the differences in OS function calls, which of course will not be the same between different OSes.) So in fact, "the code" isn't the same -- but this isn't porres's fault, and there's no way for the code not to be different.

Ideally, the same source code compiled for different chips should produce equivalent results. Programmers usually take this as a safe assumption. But there are edge cases where it might not work out that way (we just saw one of those over in SC-land, related to floating-point rounding). These cases can be extremely difficult to debug, and at the end of the day, one is at the mercy of the CPU and the compiler's behavior.

In such cases, it isn't helpful to accuse a developer of writing different code for Windows (this is implausible for DSP code in any case, which is mostly math operations that are well abstracted -- you don't need #ifdefs for std::xxx() math functions) or of "not caring" enough.

We want to assume that the compiler and CPU are transparent with respect to the source code's meaning. When that isn't the case, it's necessary to inspect every operation. It's painful, and if porres doesn't have access to a machine where the problem occurs, it can be very slow (test builds, relying on other people to run the specific tests). A little patience goes a long way.

hjh