Różnice
Różnice między wybraną wersją a wersją aktualną.
Poprzednia rewizja po obu stronach Poprzednia wersja Nowa wersja | Poprzednia wersja Nowa wersja Następna rewizja po obu stronach | ||
konwerter_svg_oscyloskop [2020/11/22 14:27] hamsterking [WORKLOG] |
konwerter_svg_oscyloskop [2020/11/22 21:15] hamsterking [WORKLOG] |
||
---|---|---|---|
Linia 1: | Linia 1: | ||
- | ==== Konwerter obrazu na sinusa/rysowanie na oscyloskopie ==== | + | ==== Konwerter obrazu na sygnał/rysowanie na oscyloskopie ==== |
^Zamieszany|[[user>hamsterking]] | | ^Zamieszany|[[user>hamsterking]] | | ||
^Rozpoczęto | 2020-10-24 | | ^Rozpoczęto | 2020-10-24 | | ||
Linia 32: | Linia 32: | ||
* 22.11.2020\\ | * 22.11.2020\\ | ||
Po miesiącu walki z SVG oraz PWMem (gdzie zamiast robić waveshaping z sygnału trójkątnego jest robiony DAC) udało stworzyć się stworzyć program, który tworzy plik .wav oraz łuk eliptyczny parametryzowany z użyciem końcowego punktu. | Po miesiącu walki z SVG oraz PWMem (gdzie zamiast robić waveshaping z sygnału trójkątnego jest robiony DAC) udało stworzyć się stworzyć program, który tworzy plik .wav oraz łuk eliptyczny parametryzowany z użyciem końcowego punktu. | ||
- | {{ projekty:ellipse_arc_svg.png|}} | + | {{ projekty:ellipse_arc_svg.png |}}\\ |
+ | Umarłem - okazuje się, że dla SVG, oś Y rośnie w dół :) To, że wychodzą mi teraz dobre łuki, jest tylko efektem mojego kodu do kreowania punktów, a nie faktycznie poprawnie działający interpreter. Odkryłem to, gdy zauważyłem, że wg. standardu SVG, gdy dla linii podaje co raz wyższą wartość Y, to ta spada jeszcze bardziej. |