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 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...

@jamcultur said:

F12.paf.control.pd says that there is a paf~ external, but I can't find it. This page by Miller Puckette describes paf:

just use his patch, no need to look for an external,

the max external for example does not support signal input, therefore a custom patch is there also preferred.

@Obineg said:

the max external for example does not support signal input, therefore a custom patch is there also preferred.

why?

only reason I can think is if you wanna do FM, which is unlikely. In the code we have signal ramps by the way and it's more efficient

@porres
it is always useful to have music signal related abstrations in full-signal available.

try to implement something simple and common such as a tremolo or vibrato to the paf~ external using data rate and you´ll see what i mean..

@Obineg said:

try to implement something simple and common such as a tremolo or vibrato to the paf~ external using data rate and you´ll see what i mean.

my paf~ external has 3 signal inputs for that matter