@playinmyblues said:

@jamcultur it is good to see you found your source of the error. Does that tell you why? And I am curious how you found it.

Seeing the code with the error doesn't tell me why the error occurred. I found the code using the findstr command on Windows (similar to grep on Linux). I searched for the code referenced in the error message that was issued to the Pd console. Do you not get the divide by zero messages on your Pd console?

I found the code that has the divide by zero error (in blue).

@playinmyblues I have not edited any of the mimba files. I've used many other Pd patches on my Windows system without any problems, so I don't think it's anything on my system that is causing the problem. I'll try it on another Windows system when I get a chance.

@playinmyblues Yes, that is what I got when I opened main-mimba.pd, but I'm not getting that any more even though I didn't do anything to fix it. Now I'm getting this error message:

expr divide by zero detected - 'sin(w2128)sinh(ln(2)/2$f1*w2128/sin(w2128))'

@hansr @playinmyblues I'm having the problem on Windows 10 with 64GB RAM.

I just installed mimba on Windows 10, and am getting this error:

How do I fix it?
Thanks!

I wanted physical knobs, buttons, and sliders to control my Pure Data modular synth, so I got an AKAI MIDI Mix. It is a reasonably priced controller with 24 knobs, 9 sliders, and 26 usable buttons. Unfortunately, AKAI did not fully document the MIDI Mix's MIDI support. Fortunately, people on the Internet collaborated to reverse engineer the MIDI Mix and document a communications protocol for it. I've written an object (midimix.pd) based on that document to use the MIDI Mix with Pure Data. The help file (midimix-help.pd) explains how to install the MIDI Mix and use it in Pure Data. You can download the files here:
https://github.com/nyponen/AKAI-MIDI-Mix-object-for-Pure-Data

BTW, I thought the MIDI Mix knobs were too short, so I designed and 3D printed new ones. You can download the STL file here, if you want to print your own knobs.
https://www.thingiverse.com/thing:6984802

@solipp Thank you!

@ddw_music This is basically what I ended up doing. It's clunky, but it works. It looks like the feature request on github that @oid mentioned would fix the problem in a much cleaner way.

@solipp Thank you! There is an issue with pp.xypad. When zoomed in (ctrl+ on Windows), the green dot does not track with the mouse. Pd's default text size is too small for me, so I'm almost always zoomed in on Pd patches. I believe I've seen a similar issue with the scroll bars in other Audiolab objects.

@alexandros Yes, I tried enabling Init. It did not work.

I'm using [savestate] to save the state of a toggle in an abstraction. If that abstraction is in the main patch, it works properly. If that abstraction is imbedded within another abstraction, the state isn't saved and restored properly. This seems like a bug to me. Is there a way to save the state of a toggle that is in an abstraction inside of another abstraction?

I've attached a zip with three files that demonstrate the problem. test_save_toggle.pd is the main patch. It has two instances of the test_save_toggle2.pd abstraction. If you set the toggle in one of those and save the patch, the state of the toggle is saved correctly. The main patch also has two instances of the test_save_toggle3.pd abstraction which only contains an instance of test_save_toggle2.pd. If you set the toggle in one of those, the state of the toggle is not save correctly.

test_save_toggle.zip

@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?

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

@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

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

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

@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 I had to add paths to your patch. The result is the same as my patch.

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