CLASS_SIGNALMAININ expects the variable to be t_float, but x_cf is declared as a double! The compiler happily accepts it and you get garbage at runtime! In this particular case, Pd would read the lower half of the double and interpret it as a float.

Actually, there are ways to check the type and prevent such errors. I just opened a ticket on GitHub: https://github.com/pure-data/pure-data/issues/2142

---

As a side note:

In gendyn_new() you seem to hardcode x_cf to 440 Hz:

https://github.com/porres/pd-else/blob/653c23eb7ee0f50799dd2732f0a258fb389726b9/Code_source/Compiled/audio/gendyn~.c#L238C5-L238C19

I guess what you actually want to do is the following (after parsing the flags):

x->x_cf = atom_getfloatarg(0, argc, argv);

But maybe you only did this for testing purposes.

Christof

Hi, this is embarrassing, after coding so many objects that can easily set a signal input via an argument, like an oscillator whose signal input sets frequency and you can also set it via an argument (just like [osc~]), I can't see what's wrong with this code I'm workin on right now.

I am adapting else/gendyn~ to take center frequency so it works more like an oscillator and I am setting it via an argument or loading a default value, and I can see it is printed fine and loaded correctly at "new".

It goes into a x->x_cf variable that is also loaded at setup as via CLASS_MAINSIGNALIN(gendyn_class, t_gendyn, x_cf);

but in the perform routine this becomes "0" for some weird reason I cannot understand, so I have to give it a float or a signal into the inlet so it actually works.

I can't see what's wrong, for me it's exactly the same as other objects from my library, like [saw~], for instance.

Code live in https://github.com/porres/pd-else/blob/master/Code_source/Compiled/audio/gendyn~.c

I wonder if any wizard out there can spot the mistake I just can't seem to grab for the life of me

thanks

_______________________________________________
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev