Radio object issues when used with DAW parameters

[alfonso73]

Latest 78de052 version. Radio send correctly its values to DAW but receives only when DAW send it lower and higher values Here's a video showing the issue https://streamable.com/j5hkbj

[alfonso73]

Ok @Timothy. Found the culpirt...i was not parsing to int the output of radio when controlled by DAW parameter. This is very strange because previous PlugData version before the latest two or three (i lost track) was working right.

Basicly when interacting on the radio GUI, radio spits out integer values (well things like 1.0, 2.0. 3.0 etc.) so the [sel] in the patch here behaves as expected. If radio is receiving floats from the DAW parameter it spits out floats that [sel] don't "understand" in other words intermediate values like 1.2232 or 2.454. That's why [sel] reacts correctly only when the extreme min and max of the DAW parameter are reached because they are "exactly" 0.0 and 8.0.

BTW i think that for this and other reasons we'd need a kind of parameter based on discrete values. Camomile has it. In the Minimock example in Camomile there's in the txt file...

param -name OSC1 Waveform -list Triangular/Sawtooth Triangular/Sawtooth/Square/Wide Rectangular/Narrow Rectangular/Reverse Sawtooth

or

param -name OSC2 Octave -min -3 -max 3 -default 0 -nsteps 7;

So its a parameter based on a list. BTW a lot of parameters managing in Camomile would be useful for significant feedback/interaction in the DAW like the various flags for setting unit labels (hz, db, etc.)

See this line

param -name Modulator Volume -label dB -min 0 -max 100 -default 0;

So things like -nsteps, -label, -list, -default would be great to include in PlugData's parameters pane. And i'd add a way to save/load a parameter pane list.

[alfonso73]

Probably is just as [sel] works. The slower the floats are received from [sel] the better the accuracy of the output. In the following patch if the path from 0.0 to 8.0 lasts 1 second [sel] misses most of its input. Increasing to 10 seconds its better and "understands" all the even values Increasing to 20 seconds it "understands" all the values.

X obj 126 106 hradio 20 1 0 8 empty empty empty 0 -8 0 10 #191919 #ffffff #ffffff 0;

X obj 126 157 sel 0 1 2 3 4 5 6 7;

X obj 46 205 f 0;

X obj 88 205 f 1;

X obj 130 205 f 2;

X obj 172 205 f 3;

X obj 214 205 f 4;

X obj 256 205 f 5;

X obj 298 205 f 6;

X obj 340 205 f 7;

X obj 126 73 line;

X msg 126 36 0 , 8 1000;

X msg 250 36 0 , 8 10000;

X msg 374 36 0 , 8 20000;

X obj 172 282 print post-sel;

X obj 24 157 print pre-sel;

X connect 0 0 1 0 empty;

X connect 0 0 15 0 empty;

X connect 1 0 2 0 empty;

X connect 1 1 3 0 empty;

X connect 1 2 4 0 empty;

X connect 1 3 5 0 empty;

X connect 1 4 6 0 empty;

X connect 1 5 7 0 empty;

X connect 1 6 8 0 empty;

X connect 1 7 9 0 empty;

X connect 2 0 14 0 empty;

X connect 3 0 14 0 empty;

X connect 4 0 14 0 empty;

X connect 5 0 14 0 empty;

X connect 6 0 14 0 empty;

X connect 7 0 14 0 empty;

X connect 8 0 14 0 empty;

X connect 9 0 14 0 empty;

X connect 10 0 0 0 empty;

X connect 11 0 10 0 empty;

X connect 12 0 10 0 empty;

X connect 13 0 10 0 empty;

[timothyschoen]

I guess this isn't really a bug anymore?

And interesting that sometimes it does bang the [sel] for you, it never does for me, but I guess that's just a matter of luck/float rounding. Pd-vanilla has the same behaviour for me.

[alfonso73]

Yeah IMHO is a design error in Pd. Given that radio is conceptually based on discrete values it's kind of useless that spits floats out when receiving float. It should have a simple trunc/floor function for float atoms in....