Bin gerade dabei eine 30W RGB "Mood-Lampe" zu bauen.
Über einen Tastendruck kann ich jetzt zwischen Fading,Veriable Farbe und
um weiter Modus gewählt werden. Der jetziger Code ist soweit OK
Nun hätte ich gerne ein paar Tipps wie ich am besten ein weiches
Flackerlicht, bzw. Kaminfeuer erzeugen kann.
Wäre den im Code Modus 3
Habt Ihr ein konkretes Beispiel ?
Na was ist denn 'flackern'. In zufälligen Zeitabständen verändert sich
die Farbe und Helligkeit mehr oder weniger zufällig.
Wo bleibt denn da der Spass, wenn man nicht selber ein wenig probiert
:-)
Gerade diese Kür Sachen sind doch das Salz in der Suppe, nachdem die
langweilige Pflicht erledigt ist. Also tob dich aus.
Thomas der Bastler schrieb:> Nun hätte ich gerne ein paar Tipps wie ich am besten ein weiches> Flackerlicht, bzw. Kaminfeuer erzeugen kann.
Ich kann zwar nicht mit Bascom dienen aber in PIC Assembler habe ich es
wie folgt gelöst:
Den "weichen" Effekt erziele ich durch eine PWM Ansteuerung, deren
Dutycyclewert über eine Schleife "langsam" verstellt wird.
Eine Kerze ist ja längere Zeit hell und beginnt dann zu flackern, also
mehr oder weniger Schnell dunkler zu werden, ohne aber dabei ganz
auszugehen. Sie soll auch nicht permanent flackern sondern dazwischen
länger Hellphasen haben.
Hierzu wird in der Schleife eine Zufallszahl für die Einschaltdauer
gezogen und eine Pause von 1ms abgewartet. Falls die Zufallszahl über
95% liegt wird eine zusätzliche 100ms Pause eingefügt.
Ist die Zufallszahl kleiner, dann wird dieser neue Sollwert für die
Helligkeit durch die Schleife in kleinen Schritten angefahren. Ist er
erreicht, wird eine neue Zufallszahl für den nächsten Helligkeitswert
gezogen.
Damit die "Kerze" beim Flackern nicht ganz ausgeht habe ich die
Zufallswerte nach unten hin auf ca, 30% begrenzt.
Durch die zusätzliche längere Pause bei hohen Zufallszahlen entstehen
die Hellphasen und durch die kurzen Pausen bei niedrigeren Werten das
kerzentypische Flackern.
Karl Heinz Buchegger schrieb:> Also tob dich aus.
Habe zwar schon herum probiert, aber sieht eher aus wie in einer
Technoschuppen....
Teelicht: ja der Ansatz hört sich mal gut an, mal sehen..)))
Welche Farben spielen hier eine wichtige Rolle, und vorallem welche
Werte, damit es realistisch aussieht ?
Thomas der Bastler schrieb:> Welche Farben spielen hier eine wichtige Rolle, und vorallem welche> Werte, damit es realistisch aussieht ?
z.B. für ein Fensterbild habe ich eine 1W Berstein LED benutzt und ihr
einen kerzenflammenförmigen Lampenschirm verpasst. Dazu habe ich dünne
weiße Schaumstoffolie mit Tesafilm zu einem Kegel zusammengeklebt und
dann die LED von untern hineinstrahlen lassen. Das Ganze mit einem
Kabelbinder unter der LED zusammengeschnürt ergibt die Form einer
Kerzenflamme.
Die Zeiten damit es realistisch aussieht habe ich ja schon genannt.
Die Mainloop, die die Helligkeit moduliert läuft mit etwa 1kHz und falls
die Helligkeit über dem Grenzwert von 95% liegt wird sie mit einer
zusätzlichen Wartezeit von 100ms beaufschlagt. D.h. die Änderung des
Dutycycles erfolgt mit 1% pro Millisekunde.
Aber wie kbuchegg bereits erwähnt hat, musst du mit den Werten einfach
rumprobieren bis es dir gefällt.
Die billigen LED Teelichter die man kaufen kann erzeugen den
Flackereffekt oft durch simple zufallszahlengesteuerte Puls Pausen
Ansteuerung. Oder durch abgelegte Tabellenwerte, die in der Loop
abgespielt werden. Das "Weiche" fehlt dann aber und es sieht wie du
festgestellt hast eher wie ein Dicoblitzer aus.
Ich kann 3 Zufallszahlen nehmen
also irgendwie so :
DIM I-Rot as World
DIM I-Gruen as Word
DIM I-Blau as World
I-Rot=RND(255)
I-Gruen=RND(200)
I-Blau=RND (100)
If Modus=3 then
If I-Rot< 200 then ' sollte nicht zu dunkel sein...
I-Rot=240
End If
Rot=I-Rot
Gruen=I-Grün
Blau=I-Blau
End If
RND ( Max Wert) und als PWM Wert nehmen. Es ist ader noch meilenweit
davon entfernt was ich mir vorstelle...Ein Kaminfeuer zieht irgendwie
ganz anders aus..
Thomas der Bastler schrieb:> I-Rot=RND(255)> I-Gruen=RND(200)> I-Blau=RND (100)
Nur mal so als Gedankengang.
Es wird in vielen Fällen nicht sinnvoll sein, den vollen Umfang an
Zufallszahlen zu benutzen. Das Flackern einer Kerze geht nun mal nicht
von Helligkeit 0 bis Helligkeit 255, sondern sie wird in einem gewissen
Helligkeitsbereich flackern. Ich nehm jetzt einfach mal an von 75%
Helligkeit bis 100% Helligkeit. D.h. du brauchst auch Zufallszahlen, die
sich in diesem Bereich abspielen.
Deine am meisten gebrauchte Formel wird so aussehen
irgendwas = Minimum + RND( Maximum - Minimum )
um also zb Zufallszahlen zu erhalten, die sich im Bereich 75% von 255
bis 100% von 255 bewegen, nimmst du dann
75% * 255 = 191
100% * 255 = 255
Helligkeit = 191 + RND(64)
und kriegst damit Zufallszahlen, die dann nur mehr in diesem Bereich von
191 bis 255 dir eine neue Helligkeit geben. Die so simulierte Kerze kann
dann eben nicht mehr alle Helligkeiten von komplett aus, knapp vorm
verlöschen bis strahlend Hell haben, sondern nimmt nur mehr Werte an,
die eben hell und ab und zu etwas weniger hell ausmachen.
Und genau da musst du eben ein wenig experimentieren.
Genauso mit den Farben. Lass halt erst mal alles auf einem schönen
warmen Braun/Orangeton.
Mittels Zufallszahlen bestimmst du dir die Helligkeit und die rechnest
du in RGB um, indem du
rot = Grundfarbe_Rot * Helligkeit / 255
gruen = Grundfarbe_Grün * Helligkeit / 255
blau = Grundfarbe_Blau * Helligkeit / 255
rechnest. Das du keine vernünftigen Werte kriegst, wenn du dir einfach
für Rot, Grün und Blau Zufallszahlen bestimmen lässt, ist ja wohl klar.
Das hat dann tatsächlich mehr von einer Disco als von einer Kerze.
Genau dasselbe mit den Zeiten. Kerzen flackern nicht beliebig schnell.
Also wirst du dir eben mit Zufallszahlen nicht Wartezeiten von 0 bis
(hausnummer) 8 Sekunden erzeugen, sondern eben nur von (hausnummer) 2
Sekunden bis 8 Sekunden und vielleicht ab und zu mal einen schnellen,
intensiveren Flackerer einstreuen.
Wenn du es noch weicher im Übergang machen willst, dann darf sich eben
die Helligkeit nicht schlagartig von zb 248 auf 196 ändern.
Ist die Helligkeit auf 248 und hast du errechnet, dass die nächste
Helligkeitsstufe 196 sein muss, dann wird die eben nicht sofort auf 196
gesetzt, sondern man kann bei jedem Schleifendurchlauf zb einen Soll/Ist
Vergleich machen und den Istwert langsamer nachführen
1
do
2
3
if IstWert > Sollwert
4
Istwert = Istwert - 1
5
6
if Istwert < Sollwert
7
Istwert = Istwert + 1
8
9
10
... berechne neue RGB Werte aus dem Istwert
11
12
loop
wie überhaupt das ganze Zeitmanagement mittels Wait Mist ist. Aber das
sag ich hier in diesem Forum nicht zu ersten mal. Zeitsteuerungen
bedeuten praktisch immer einen Timer samt ISR und eventuell noch
zusätzliche Variablen die rauf oder runter zählen um so aus dem
regelmässigen 'Ticken' der ISR eine kontrolliert längere Zeitdauer zu
machen.
Die Möglichkeiten sind endlos. Erlaubt ist was dir gefällt und was dich
deinem Ziel näherbringt. Und ja. Manchmal denkt man sich dann eben
Formeln aus, von denen man annimmt dass sie gut aussehen oder die man
sich aus der Beobachtung der Realität zusammengereimt hat.
Wir brauchen drei Faktoren:
- Nächste Farbe
- Nächste Helligkeit
- Zeitdauer in der der Wechsel stattfinden soll
Diese drei Zufallszahlen werden erzeugt. Danach muss der Wechsel
durchgeführt werden (in einer Unter-Schleife) und erst danach werden
drei neue Zufallszahlen erzeugt. So in etwa stelle ich mir das
jedenfalls vor.
Um mal ein anderes Beispiel zu bringen.
Ich hatte mir mal ein Paneel gebaut mit 64 (weißen) LED, die einzeln in
der Helligkeit einstellbar waren.
Einen kompletten Leuchtzyklus einer LED hab ich unterteilt in eine
Hell-Phase und eine Dunkel-Phase. Für jede Phase wurde bestimmt
* wie lange soll sie dauern (Zufallszahl mit Minimum und Variation)
* Helligkeit der LED (ebenfalls Zufallszahl mit Minimum und Variation)
Jede LED durchläuft (natürlich gleichzeitig, Timer-interrupt gesteuert)
ihren Lichtzyklus und wenn der vorbei ist, dann werden neue WErte für
den nächsten Zyklus für diese LED bestimmt.
mit Dunkelzeiten von ein paar Sekunden und 0 Helligkeit (Minimum = 0 und
Variation = 0) und kurzen Hellzeiten (0.5 Sekunden, Variation = 0) und
100% Helligkeit (Minimum = 100, Variation = 0) hat das ausgesehen wie
ein Bild aus dem Olympiastadion, wenn die Hobbyfotografen auf den
Tribünen fotografieren wenn Ursain Bolt zum Weltrekord ansetzt. Ein
Blitzlicht-Gewitter
Mit kurzen Dunkelphasen (minimum = 1, Variation = 0.5) und 80%
Helligkeit (minimum = 70, Variation = 20) und etwas längeren Hellphasen
(2, Var=1) mit mehr Helligkeit (90, Variation=10) sieht das ganze dann
wieder mehr aus wie ein sternklarer Himmel in einer dunklen, kalten
Winternacht.
Mit wieder anderen Werten lassen sich ganz andere Effekte erzielen. D.h.
ich hab mir einen Formalismus ausgedacht, den ich allein mit den
einzusetzenden Werten für jede LED parametrieren kann um verschiedene
Ergebnisse zu erhalten.
Nun bin ich schon etwas weitergekommen, soweit alles OK.
Nun meine Frage wäre folgendes:
Mit einem Poti ( eins von den 3 ) möchte ich für die
Helligkeitssteuerung verwenden. Also mit einem Poti die gesamte
Helligkeit in allen Modus.
Wie mache ich am besten, ohne , daß ich hunderte If - Then Abfragen
einbaue ?
Die Helligkeit sollte also "im laufenden Betrieb" verändertwerden
können.
Anbei mein Code
Thomas der Bastler schrieb:> Mit einem Poti ( eins von den 3 ) möchte ich für die> Helligkeitssteuerung verwenden. Also mit einem Poti die gesamte> Helligkeit in allen Modus.>> Wie mache ich am besten, ohne , daß ich hunderte If - Then Abfragen> einbaue ?
So wie das auch ein Mischpult macht.
Dein 'Masterregler' ist nichts anderes als ein einstellbarer Faktor von
0 bis 1 mit dem alle Werte ganz zum Schluss multipliziert werden.
Jetzt rächt es sich natürlich, dass du keine zentrale Stelle hast, an
der die in allen Modi bestimmten RGB Werte in die Timer Register
verteilt werden, sondern die Zuweisungen überall direkt gemacht hast.
Thomas der Bastler schrieb:> Die Helligkeit sollte also "im laufenden Betrieb" verändertwerden> können.
Entsprechend des Wertes vom ADC einfach mit einem Faktor multiplizieren.
Ich hab' mir deinen Code nicht so genau angesehen, deshalb nur mal ein
Beispiel:
"Einstellungen":
PWM von 0..255 möglich, 8-Bit-ADC
"Berechnung":
PWM_Wert = (PWM_Wert + 1) * (ADC_Wert + 1) / 256 - 1
oder
PWM_Wert = PWM_Wert * ADC_Wert / 255
(Die Variante mit "/256" gefällt mir besser. Ergibt möglicherweise trotz
der Additionen kürzeren Code, weil in Wirklichkeit keine Division
ausgeführt werden muss. - Falls der Basic-Compiler das erkennt.)
Karl Heinz Buchegger schrieb:> Jetzt rächt es sich natürlich, dass du keine zentrale Stelle hast, an> der die in allen Modi bestimmten RGB Werte in die Timer Register> verteilt werden, sondern die Zuweisungen überall direkt gemacht hast.
Genau das habe ich festgestellt...
if - then - else
ist schon erfunden. Auch in Bascom. Wenn Modus gleich 1 ist, dann muss
man nicht mehr abfragen, ob es gleich 2 ist. Modus kann nicht 2 sein,
oder 3, oder 4 - eben weil es 1 ist und das feststeht, wenn die Abfrage
in den zugehörigen then Zweig genommen wird.
1
if Modus = 1 then
2
....
3
4
elseif Modus = 2 then
5
....
6
7
elseif Modus = 3 then
8
....
9
10
...
11
endif
und sieh dir in BASCOM auch mal die Anweisung LOOKUP an. Du kannst
diesen ganzen Teil hier
1
If Modus = 4 Then
2
Rot = 255
3
Gruen = 0
4
Blau = 0
5
End If
6
7
If Modus = 5 Then
8
Rot = 0
9
Gruen = 255
10
Blau = 0
11
End If
12
13
If Modus = 6 Then
14
Rot = 0
15
Gruen = 0
16
Blau = 255
17
End If
18
19
If Modus = 7 Then
20
Rot = 0
21
Gruen = 255
22
Blau = 255
23
End If
24
25
If Modus = 8 Then
26
Rot = 255
27
Gruen = 0
28
Blau = 255
29
End If
30
31
If Modus = 9 Then
32
Rot = 0
33
Gruen = 255
34
Blau = 255
35
End If
mit Lookup in 4 oder 5 Zeilen Code eindampfen. Selbiges hier in der
Modus INkrementierung innerhalb der Sub die für die Tastenauswertung und
Modus-Weiterschaltung zuständig ist.
Übersichtlichen Programmcode zu haben ist nicht einfach nur reiner
Luxus. Das hat auch was mit Codequalität und Fehlerhäufigkeit zu tun.
Code der sich seitenweise dahinzieht ist nicht nur unübersichtlich
sondern auch fehleranfällig - weil man nichts mehr sieht.
Thomas der Bastler schrieb:> Ralf G. schrieb:>> PWM_Wert = PWM_Wert * ADC_Wert / 255>> Multiplikation und Division geht nicht in einer Zeile..
Dann trenn es halt auf in 2 Zeilen.
Die wenigsten hier programmieren in BASCOM sondern in einer
Programmiersprache in der man auch kompliziertere arithmetische
Ausdrücke in einem Aufwasch schreiben kann.
Du darfst hier präsentierten Code nicht 100% buchstabengetreu wörtlich
nehmen, sondern mehr als Anregungen. Dein BASCOM und wie man dann die
Anregung ganz konkret buchstabengetreu in BASCOM umsetzt, das musst du
schon selber kennen und können.
Thomas der Bastler schrieb:> Karl Heinz Buchegger schrieb:>> Jetzt rächt es sich natürlich, dass du keine zentrale Stelle hast, an>> der die in allen Modi bestimmten RGB Werte in die Timer Register>> verteilt werden, sondern die Zuweisungen überall direkt gemacht hast.>> Genau das habe ich festgestellt...
Du wirst jetzt aber hoffentlich draus lernen und NICHT überall im ganzen
Programm die Multiplikation mit dem Masterfader nachtragen.
Sondern:
Du machst dir eine Sub SetRGB, der du die neuen Werte für Rot, Grün und
Blau übergibst und tauscht erst mal in deinem Programm alle direkten
Zuweisungen an Rot, Gruen und Blau gegen Aufrufe dieser Sub aus mit den
jeweilgen Werten.
Zum Beispiel
1
...
2
3
Declare Sub SetRGB( red as byte, green as byte, blue as byte )
4
5
6
7
....
8
9
If Rgb = 0 Then
10
Incr Rot_0
11
Decr Blau_0
12
Call SetRGB( Rot_0, Gruen_0, Blau_0 )
13
Waitms Color_delay
14
15
ElseIf Rgb = 1 Then
16
Decr Rot_0
17
Incr Gruen_0
18
Call SetRGB( Rot_0, Gruen_0, Blau_0 )
19
Waitms Color_delay
20
21
ElseIf Rgb = 2 Then
22
Decr Gruen_0
23
Incr Blau_0
24
Call SetRGB( Rot_0, Gruen_0, Blau_0 )
25
Waitms Color_delay
26
27
End If
28
....
29
30
31
32
Sub SetRGB( red as byte, green as byte, blue as byte )
33
Rot = red
34
Gruen = green
35
Blau = blue
36
End Sub
37
38
...
Dann testest du, ob sich nichts verändert hat und du dir keine Fehler
eingehandelt hast.
Und dann baust du deinen Masterfader in dieser Sub mit dazu. An ÉINER
Stelle!
Wenn man schon ändern muss, dann macht man es gleich richtig. Es ist
nicht schlimm, wenn man drauf kommt, dass man eine etwas andere Struktur
im Programm brauchen würde. Schlimm ist es allerdings, wenn man auf
diese Erkenntnis nicht reagiert und so weiterwurschtelt wie bisher.
Und im benutzen Beispiel sieht man dann auch sofort wieder, dass sich
hier gleich die nächste Möglichkeit eröffnet, den Code zu straffen. In
allen 3 Abfragen lauten die letzten beiden Zeilen gleich. Die können
also auch heruasgezogen werden, weil sie sowieso immer, egal welche
Bedingung zutrifft, ausgeführt werden
1
....
2
If Rgb = 0 Then
3
Incr Rot_0
4
Decr Blau_0
5
6
ElseIf Rgb = 1 Then
7
Decr Rot_0
8
Incr Gruen_0
9
10
ElseIf Rgb = 2 Then
11
Decr Gruen_0
12
Incr Blau_0
13
14
End If
15
16
Call SetRGB( Rot_0, Gruen_0, Blau_0 )
17
Waitms Color_delay
18
...
und so führt dann eben eines zum anderen. Nur machen muss man es!
Programmieren ist nicht nur Codezeilen schreiben, sondern auch sich mal
kritisch zurücklehnen und sich fragen: Wie kann ich den Code verbessern,
wartbarer machen, straffen? Aber dazu muss man eben seine
Programmiersprache kennen, damit man weiß welche Möglichkeiten man
überhaupt hat. Codeblöcke kopieren und ein paar Zahlenwerte austauschen
hat nichts mit "Programmiersprache kennen" zu tun.
Ups...langsam Jungs..muss noch verdauen...
Das erste Problemchen mit lookup Tabelle. Compiler meckert.
------------------------------
If Modus = 4 Then
Rot = Lookup(0 , Farben) 'sollte 255
sein
Gruen = Lookup(1 , Farben) 'sollte 0
sein
Blau = Lookup(2 , Farben) 'sollte auch
0 sein
End If
----------------------------
Farben:
Data 0 , 0 , 0
Data 255 , 0 , 0
Data 0 , 255 , 0
Data 0 , 0 , 255
Data 255 , 0 , 255
Data 0 , 255 , 255
Data 255 , 255 , 0
Data 255 , 255 , 200
Karl Heinz Buchegger schrieb:> Programmieren ist nicht nur Codezeilen schreiben, sondern auch sich mal> kritisch zurücklehnen und sich fragen: Wie kann ich den Code verbessern,> wartbarer machen, straffen?
Vor dem Programmieren kommt das Nachdenken über den geeignetsten
Algorithmus, sonst ist das alles verschwendete Arbeit.
Hier würde man sich eine Funktion bauen, der man Farbton, Sättigung und
Helligkeit übergibt. Daraus errechnet diese RGB-Werte und setzt die PWM
entsprechend, evtl. noch unter Berücksichtigung der Empfindlichkeit des
Auges für die einzelnen Farben und deren Helligkeit.
Die bedienergerechte Einstellung des Farbtons nach HSL ist damit kein
Problem mehr, 3 Drehregler und fertig. Genauso problemlos sind Fadings
im Farbkreis, als auch Simulationen wie Flamme oder Feuer, die dann aus
zufällig variierenden Rot- und Gelb-Tönen erzeugt werden und man sich
dann keinen Kopf mehr darüber zerbrechen muss, wie viel Grün muss zum
Rot, damit's das passende Gelb wird.
Fehler gefunden mit Lookup.
So geht es nicht.
Rot Alias Compare1a
So geht es
If Modus = 4 Then
Rot_led = Lookup(0 , Farben)
Rot = Rot_led
Gruen = 0
Blau = 0
End If
Farben:
Data 0 , 0 , 0
Data 255 , 0 , 0
Data 0 , 255 , 0
Data 0 , 0 , 255
Data 255 , 0 , 255
Data 0 , 255 , 255
Data 255 , 255 , 0
Data 255 , 255 , 200
In meinem Fall würde aber eine Farbenzeile auch reichen..oder ?
Dim Rot_led As Integer
Dim Gruen_led As Integer
Dim Blau_led As Integer
If Modus = 4 Then
Rot_led = Lookup(0 , Farben)
Rot = Rot_led
Gruen_led = Lookup(1 , Farben)
Gruen = Gruen_led
Blau_led = Lookup(1 , Farben)
Blau = Blau_led
End If
Farben:
Data 255 , 0
Thomas der Bastler schrieb:> Ups...langsam Jungs..muss noch verdauen...>> Das erste Problemchen mit lookup Tabelle. Compiler meckert.
Denn Rest muss ich erst noch lesen.
Aber dazu gleich soviel:
Gewöhn dir den Scheiss ab. 'Compiler meckert' ist keine sinnvolle
Aussage, mit der man was anfangen kann.
Dein Compiler schreibt nicht hin "Ich meckere", sondern der schreibt
eine Fehlermeldung hin. UNd das tut er nicht ohne Grund, sondern in der
Fehlermeldung ist (zumindest sollte es) ablesbar, was nach Meinung des
COmpilers anhand der Sprachregeln ein Problem darstellt.
Ich gebe zu, dass manchmal Fehlermeldungen mehrdeutig sind und in die
falsche Richtung deuten (sprich: das Problem ist eigentlich ganz
anders), aber in den meisten Fällen ist die Fehlermeldung ein deutlicher
Fingerzeig darauf, was das Problem ist.
Daher: Fehlermeldungen lesen und kommunizieren.
Mit 'Compiler meckert' hat niemand was angefangen.
Anruf bei der Hotline: Sie ich hab da so eine Fehlermeldung auf den
Schirm gekriegt. Was kann das sein?
Mitarbeiter: Was steht denn in der Fehlermeldung?
Anrufer: Ja, gelesen hab ich die nicht!
Thomas der Bastler schrieb:> In meinem Fall würde aber eine Farbenzeile auch reichen..oder ?
Keine gute Idee.
Warum willst du dir da schon wieder Abhängigkeiten einhandeln?
IN einem halben Jahr kommt deine Frau und sagt: Alles schön und gut,
aber das Rot im Modus 4, könnte man das ein bischen mehr ins Blaue
verschieben?
In deiner ersten Programmversion gehst du her und änderst folgerichtig
1
data 255, 0, 0
ab zu
1
data 255, 0, 10
und alles ist gut.
In deinem jetzigen Vorschlag musst du dich nach einem halben Jahr wieder
daran erinnern, dass es da eine Abhängigkeit gab, weil du 'damals'
wusstest, dass grün und blau im Modus 4 denselben Wert (nämlich 0) haben
und das du das ausgenutzt hast (obwohl ja eigentlich grün und blau ganz
verschiedene Dinge sind).
Ausserdem:
Wenn ich mir deine MOdi so ansehe, dann bietet es sich an, für den Teil
'Auslesen aus Tabelle und Setzen der RGB WErte' gleich mal wieder eine
Sub zu machen, die genau das tut: Eine bestimmte 'Farbe' aus der Tabelle
auslesen und die Farbe als RGB-Wert zu setzen.
Deine Modusverzweigung sieht dann zb so aus
1
If Modus = 4 Then
2
Call SetTableColor( 0 )
3
4
ElseIf Modus = 5 Then
5
Call SetTableColor( 3 )
6
7
ElseIf Modus = 6 Then
8
Call SetTableColor( 6 )
9
10
ElseIf Modus = 7 Then
11
Call SetTableColor( 9 )
12
13
ElseIf Modus = 8 Then
14
Call SetTableColor( 12 )
15
16
ElseIf Modus = 9 Then
17
Call SetTableColor( 15 )
18
19
End If
mitsamt der Sub
1
Sub SetTableColor( AnfangWerte as Byte )
2
Rot_led = Lookup(AnfangWerte + 0, Farben)
3
Gruen_led = Lookup(AnfangWerte + 1 , Farben)
4
Blau_led = Lookup(ANfangWerte + 2 , Farben)
5
6
SetRGB( Rot_led, Gruen_led, Blau_led )
7
End Sub
(wenn die Addition von 0, 1 bzw. 2 wieder Probleme macht, dann musst du
das eben vorziehen)
Aber:
WEnn du dir die Modus Abfrage jetzt mal genauer ansiehst, dann gibt es
da einen mathematischen Zusammenhang zwischen der Modusnummer und dem
Startwert der Farbe in den Daten!
1
Modus Begin der Farbe
2
4 0
3
5 3
4
6 6
5
7 9
6
8 12
7
9 15
Die Moduswerte steigen um jeweils 1, die 'Farbwerte' steigen um jeweils
3.
Zieh mal vom Moduswert 4 ab. Aus 5 wird dann zb 1. Und multiplizier das
mit 3 (weil immer 3 Werte eine Farbe beschreiben). Was kriegst du? Den
jeweiligen Wert aus der 'Farbspalte'.
Der Begin der Farbbeschreibung ist immer bei
(Modus - 4) * 3
Also kann man die ganze Modusaufteilung in die Farben so eindampfen
1
If Modus >= 3 AND Modus <= 9 Then
2
FarbNr = Modus - 4
3
FarbNr = FarbNr * 3
4
Call SetTableColor( FarbNr )
5
End If
Fertig. Das behandelt die Modi 4 bis 9 korrekt (jetzt mal abgesehen von
den BASCOM Syntaxfehlern, die ich gemacht haben könnte) in 5 Zeilen Code
und einer zusätzlichen Sub. In dieser Sub setzt du dann auch nicht die
RGB Werte direkt in den Register Rot, Gruen und Blau sondern du benutzt
dazu wieder die bereits vorher eingeführte Sub SetRGB. Warum machst du
das? WEil diese Sub dann auch noch den Masterfader mit in die Werte
einrechnet! Und das willst du ja haben, dass das passiert. Oder ist es
für dich einsichtig, warum ich bei manchen Modi die Helligkeit insgesamt
einstellen kann, bei diesen fixen Modi aber nicht? Eben, seh ich auch
nicht ein. Zumal es ja programmtechnisch überhaupt kein Problem ist.
Karl Heinz Buchegger schrieb:
Hallole..ein bisschen verstehe ich, aber nicht ganz im Details..
> Call SetTableColor( 0 )
Was ist hier die "(0)"
ich muss die eine Variante erst umsetzten, verstehen, probieren, danach
erweitern, bzw. optimieren..
Diese 0 vom Aufruf steht innerhalb der Sub dann in der 'VAriablen'
AnfangWert. D.h. innerhalb der Sub hat AnfangWerte den Wert 0, weil der
Aufruf mittel
1
call SetTableColor( 0 )
gemacht wurde.
Würde der Aufruf mit
1
call SetTableColor( 3 )
gemacht werden, dann hätte innerhalb der Sub eben die Variable
AnfangWerte für diese eine Ausführung der Sub den Wert 3. usw. usw.
Hier ist der Zusammenhang
1
Sub SetTableColor( AnfangWerte as Byte )
2
***********
1 Argument, welches der Aufrufer angeben muss und egal welchen Wert er
angibt, hier drinn landet er. Und wenn er 99 beim Aufruf angibt, dann
hat eben AnfangWert bei diesem Aufruf der Sub dann den Wert 99
Was wird innerhalb der Sub damit gemacht?
Na es wird hier benutzt
1
Rot_led = Lookup(AnfangWerte, Farben)
2
***********
Der AUfruf
1
call SetTableColor( 0 )
führt also dazu, dass ein
1
lookup( 0, Farben )
gemacht wird. Weil ja die 0 vom Aufrufer in AnfangWerte landet und
dieses wiederrum in lookup eingesetzt dann eben die 0 beim lookup
ergibt.
Und der nächste ist dann
1
Gruen_led = Lookup(AnfangWerte + 1 , Farben)
für grün. Wenn AnfangWerte den Wert 0 hat, und noch 1 dazu gezählt wird,
dann wird da daher ein
1
Lookup( 1, Farben )
gemacht.
UNd genau dasselbe folgerichtig bei einem anderen Wert. Ein
1
call SetTableColor( 3 )
würde also zu einem Lookup für Rot von
1
Lookup( 3, Farben )
für Rot führen, und gleich der nächste danach zu einem
1
Lookup( 4, Farben )
für Grün (weil ja 3 + 1 die 4 ergibt. Und
1
Lookup( 5, Farben )
für Blau.
Lookup 3, 4, 5 das sind aber genau die Lookup Werte, die du im Modus 5
brauchtest.
Passt also alles zusammen. Man muss nur ein bischen rechnen und die
Zusammenhänge sehen. Und was bitte, kann ein Computer schon besser, als
rechnen :-)
Tja, dann kann ich dir auch nicht helfen.
Subroutinen zu machen, denen man die tatsächlichen Werte übergibt mit
denen sie rechnen sollen, sind absolute Grundlagen.
Kopier weiter deinen Code durch die Gegend und tausch Zahlenwerte aus.
Passt schon.
Aber nenn das bitte nicht programmieren.
Hi
>UNd genau dasselbe folgerichtig bei einem anderen Wert. Ein> call SetTableColor( 3 )>würde also zu einem Lookup für Rot von> Lookup( 3, Farben )>für Rot führen, und gleich der nächste danach zu einem> Lookup( 4, Farben )>für Grün (weil ja 3 + 1 die 4 ergibt. Und> Lookup( 5, Farben )>für Blau.
Da wäre aber
1
Sub SetTableColor( AnfangWerte as Byte )
2
Rot_led = Lookup(AnfangWerte*3 + 0, Farben)
3
Gruen_led = Lookup(AnfangWerte*3 + 1 , Farben)
4
Blau_led = Lookup(ANfangWerte*3 + 2 , Farben)
und ein Aufruf mit
call SetTableColor( 1 )
sinvoller.
MfG Spess
Karl Heinz Buchegger schrieb:> Subroutinen zu machen, denen man die tatsächlichen Werte übergibt mit> denen sie rechnen sollen, sind absolute Grundlagen.
Das habe ich schon kapiert..
Karl Heinz Buchegger schrieb:> Kopier weiter deinen Code durch die Gegend und tausch Zahlenwerte aus.
Stimmt nicht aber was solls...bin ja gewohnt...LoL
> ein wahnsinns gezappele und hin und her Springerei im Cod...
Und?
Wen interessierts?
Jede Sub hat eine genau definierte Funktionalität.
Ich muss beim Aufruf von
call SetRGB( Red, Green, Blue )
nicht exakt wissen, wie die Funktion das konkret macht.
Ich muss beim Aufruf von
Call SetTableColor( 3 )
nicht exakt wissen, wie die Funktion das macht. Ok, man könnte die
Farben auch einfach durchnummerieren und die Funktion macht selber die
notwendige Multiplikation mit 3, aber ich dachte eigentlich so wäre das
für dich verständlicher. Wie man sich irren kann. Aber: Hindert dich ja
niemand das so zu ändern, dass SetTableColor eine Farbnummer bekommt,
daraus ausrechnet, wo diese Farbe in seiner Tabelle anfängt und sich
dann die zu dieser Farbe gehörenden RGB Werte holt.
spess53 schrieb:> sinvoller.
Ja, das war eine Fehleinschätzung.
Ich dachte, so rum würde er es leichter verstehen, wenn ich die
UMrechnung nicht in 2 Teile auseinanderreisse.
Alle Programme die ich bisher geschrieben habe, sind mit Sicherheit
suboptimal, aber ich verstehe es.
Versuche aber auf jedenfall die neue Sachen umzusetzten.
Für mich immer die Frage, wenn das Ding das tut was er soll, und es ist
auch jedenfall für mich ein privates Produkt, wiviel Aufwand ich
reinstecke, damit das Ergebinis "sichtbar" gleich ist.
Ganz klar mein aller erster Code war wesentlich schlimmer wie die
heutige.
Habe programmieren in keinster Weiser gelernt, habe ich mir alles selber
durch mehr oder weniger Probirerei beigebracht.
Thread beobachten
Seitenaufteilung abschalten