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?

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

@ddw_music Thanks for the clearer explanation.

To reiterate: the code is exactly the same on any OS. That was the point of my question “what Windows code?” — to indicate that there is no such distinction. I was not asking anyone to debug my code. I was asking for a more careful identification of the actual issue, rather than assumptions about OS-specific behavior that does not exist here.

If you're gonna claim something, you gotta have something to back it up...

I don’t have access to Windows. I haven’t used it for over two decades. This is volunteer work, and I would expect a minimum level of respect and collaboration instead of being blamed because early, experimental code is not yet working on Windows.

Making confused claims without being able to properly test or report the issue is not helpful. It did not feel to me like there was an intent in trying to help; it felt like complaining, while also stating I shouldn't expect people to debug the code for me...

If there is no interest in helping—and not even in supporting the work financially—then it’s better to disengage. So yes, sorry if I wasn’t patient enough in my explanation.

And the most incredible confusion here was to assume I had a different algorithm that wasn't supposed to be called "paf", which was "invented by someone else" (who cares anyway?). So, to be cristal clear, this was simply a bug on windows where, for some obscure reason outside of my reach, the compiled code behaved differently. This was supposed to be evident when I, for multiple times, proved that the object was working as intended on macOS. So it was clearly the same technique/algorithm.

Having said all that, I’ve now implemented multichannel support in the object and asked an AI for hints about potential cross-platform issues. I made a few changes and tested them on a virtual machine, and everything now seems to work.

I honestly don’t know what, if anything, actually fixed the problem. I didn’t really touch the paf source code itself; I only made some minor changes to the buffer.c dependency.

see https://github.com/porres/pd-else/actions/runs/20669314244

And a screenshot

For the record, formant~ was now also added, so I have formlet~, formant~, vosim~ and paf~ (all with multichannel support) already inclued into ELSE, and I'm gonna stop here for the time being...