PWM on LED with PureData

Knallberto

Thank you! Now I think I understand how it's supposed to work. I tried to apply it, but I think the problem ist, that the values from r~ star1_amp are really small, so the signal in the end seems to be always below zero. Is there a way to stretch ma signal before the -~ .5 to be really between 0 and 1? Or how would I try to make it work?
Then one question with the first *~ that is supposed to replace the env~. Why exactly do I multiply the signal with itself? To get rid of the negative values?

alt text

lokki

Knallberto Then one question with the first *~ that is supposed to replace the env~. Why exactly do I multiply the signal with itself? To get rid of the negative values?

yes, you eliminate negative values.

try your print on the input and after the *~ what values do you get there? to boost the signal i would try a [*~ 3] (or whatever amount)] right before the "self multiplication" that should give you the possibility to scale the input, as you desire. you could also add a [clip~ -1 1] after the first multiplication to make sure your signal never exceeds the "limits".

Knallberto

lokki try your print on the input and after the ~ what values do you get there?

where exactly do you mean?

lokki

Knallberto after the "self" multiplication (which in effect is like a "input^2"). but as i said i would boost the signal right before that.

so boost right after your [r~ star1_amp] with a [*~ "factor"]

Knallberto

Thank you, it is working a lot better now. But the env~ + line~ seems to give a smoother fade with less CPU usage, because when I do the selfmultiplication I need a lot of lopass filters to smooth it and that seems to be using a lot of CPU.

giuliomoro

how many [lop~] are you using ? what cutoff frequency? You can lower the cutoff to use fewer of them!

Knallberto

I think I used 7 at 20. But is there a real problem with using the env~ ?

lokki

no there is not.
as giuilo said, try with a lower cutoff and one
or two lop~ or if it works, use the env~ solution.

giuliomoro

well, judging from the help file,[env~] is probably :

taking the square of a signal window (N = 1024 by default)
applying a Hann window and summing all the values, which is equivalent to applying an FIR averaging filter with a -3dB point at ~ 32Hz for a 44100kHz sampling rate (if I got my matlab right!)
taking the square root of that, and then taking the log (or combining both in a single operation, I hope)
this happens every "period" (512 by default), which effectively downsamples the signals post-filtering.

So in principle, taking the square of your signal with [*~] and low-pass filtering it should do the same (except better, because the FIR filter described above is not so great and because you have no downsampling).

balandino_dd

giuliomoro I'm using this method for a project with a bunch of LEDs

I'm using 12v RGB strip LED, 1k resistors and N MOSFETs (https://makezine.com/projects/android-arduino-led-strip-lights/)

Below is the Pd patch I'm using to try to fade ON/OFF at 1 Hz frequency for start. My guess is that I did something wrong with the electronics, but maybe also in the code?! Any advice?
alt text

giuliomoro

To check if its the electronics, just do:

[phasor~ 1]
|||
[dac~ 11 12 13 ]

(besides the initialization, that is).

If the LEDs don't turn on/off every 500ms, then your electronics has issues.

Your attempt at PWM there doesn't seem particularly good. Your carrier frequency (50Hz) seems too slow: you would perceive flickering. Also, careful when using sin * sin, as the resulting frequency is going to be twice as high as the one you write in.
I have made this "virtual analog" patch so you can visualize the relevant signals in Pd (and in the Bela scope):

alt text

Source:

#N canvas 1 23 1280 684 10;
#X obj 108 341 tabwrite~ ar;
#N canvas 0 22 450 278 (subpatch) 0;
#X array ar 44100 float 2;
#X coords 0 1 44100 -1 1000 140 1 0 0;
#X restore 512 137 graph;
#X obj 182 261 +~;
#X obj 341 121 osc~ 1;
#X obj 265 64 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#N canvas 0 22 450 278 (subpatch) 0;
#X array digital-out 44100 float 2;
#X coords 0 1 44100 -1 1000 140 1 0 0;
#X restore 517 306 graph;
#X obj 269 346 expr~ $v1 > 0.5;
#N canvas 0 23 450 278 (subpatch) 0;
#X array brightness 44100 float 2;
#X coords 0 1 44100 -1 1000 140 1 0 0;
#X restore 516 466 graph;
#X obj 348 420 lop~ 100;
#X obj 352 530 tabwrite~ brightness;
#X obj 348 450 lop~ 100;
#X obj 348 480 lop~ 100;
#X text 398 399 low-pass filter;
#X text 398 409 corresponding;
#X text 398 419 to limited refresh;
#X text 398 429 rate of human;
#X text 398 439 vision;
#X obj 178 390 tabwrite~ digital-out;
#X obj 251 101 metro 1001;
#X obj 324 198 -~ 0.5;
#X obj 328 160 *~;
#X obj 59 161 phasor~ 300;
#X obj 77 500 dac~ 27 28 29;
#X text 256 303 The signal that is actually sent;
#X text 256 313 to the digital out is thresholded;
#X text 256 323 in the backend.;
#X obj 13 340 dac~ 11 12 13;
#X obj 252 30 loadbang;
#X text 98 461 Bela scope;
#X obj 405 42 s bela_setDigital @hv_param;
#X msg 406 18 out 11 ~ \, out 12 ~ \, out 13 ~;
#X connect 2 0 0 0;
#X connect 2 0 6 0;
#X connect 2 0 22 0;
#X connect 2 0 26 0;
#X connect 2 0 26 1;
#X connect 2 0 26 2;
#X connect 3 0 20 0;
#X connect 3 0 20 1;
#X connect 4 0 18 0;
#X connect 6 0 8 0;
#X connect 6 0 17 0;
#X connect 6 0 22 1;
#X connect 8 0 10 0;
#X connect 10 0 11 0;
#X connect 11 0 9 0;
#X connect 11 0 22 2;
#X connect 18 0 0 0;
#X connect 18 0 9 0;
#X connect 18 0 17 0;
#X connect 19 0 2 1;
#X connect 20 0 19 0;
#X connect 21 0 2 0;
#X connect 27 0 4 0;
#X connect 27 0 30 0;
#X connect 30 0 29 0;

« Previous Page