![]() |
wieder konvertierungs problem
Hallo
Habe wieder ein umsetzungs problem von c++ nach Delphi 2x zeilen ;)
Code:
meterlphi :=(meterlphi<0.0)? 0.0: (meterlphi>128.0)? 128.0 : meterlphi;
Code:
wie müssen diese nach Delphi konvertiert werden ?
lphi+=13.5
Komme da mit dem Fragezeichen nicht zurecht. gruss Emil |
Re: wieder konvertierungs problem
Hi
Wenn das ":=" ein "=" ist, würde es so in der Art aussehen:
Code:
meterlphi :=(meterlphi<0.0)? 0.0: (meterlphi>128.0)? 128.0 : meterlphi;
Delphi-Quellcode:
if meterlphi < 0.0 then
begin meterlphi := 0.0 ; end else begin if meterlphi > 128.0 then meterlphi := 128.0; end;
Code:
lphi+=13.5
Delphi-Quellcode:
Angaben ohne Gewähr. :stupid:
lphi := lphi + 13.5;
Edit: Das mit dem Fragezeichen ist eine verkürzte Schreibweise einer if-Anweisung: Wert = <Boolscher Ausdruck> ? <wenn Ausdruck wahr, wird das hier zugewiesen> : <wenn falsch, dann das hier> Edit 2: @RavenIV Ich kaue generell nichts vor und bin auch dafür, die Leute selbst auf die Lösung kommen zu lassen, da so der Lerneffekt groß ist, aber bei so trivialen und kleinen Dingen ist eine Lösung in Ordnung. Das ist was anderes bei aufwändigem Code. Das oben hätte wohl jeder umsetzen können, der weiß, was ? und : bedeuten. :roll: |
Re: wieder konvertierungs problem
der ?-Operator in C ist gleichzustellen mit einer if..then..else Anweisung.
a<1?b:c => if a < 1 then b else c; a+=5 => a := a + 5; da gibt es nichts vergleichbares in Delphi. /edit: Mist, da war einer schneller /edit2 Kaut den Leuten doch nicht immer alles vor. Sie sollen nur einen Denkanstoss bekommen. |
Re: wieder konvertierungs problem
@Matze
Danke werde es mal testen ;) @RavenIV Jo .. aber wie von Matze beschrieben geht's schneller In VB wäre ich mir sicher gewesen ? = IIF In Delphi lern ich's noch. gruss |
Re: wieder konvertierungs problem
Oder ganz elegant als Einzeiler:
Delphi-Quellcode:
meterlphi := Max(Min(meterlphi, 128.0), 0.0);
|
Re: wieder konvertierungs problem
Zitat:
Nur so nebenbei. Habe noch ein problem bei der For Schleife Hier mal die Schleife in C++
Code:
for (lphi=0.0f; lphi<=189.0f; lphi+=13.5f)
{ z=-9.0f; x=(float)(-sin((lphi+45.0f)*M_PI/180.0f)*2.0f)-2.5f; y=(float)(-cos((lphi+45.0f)*M_PI/180.0f)*2.0f)+yposition; glTexCoord2f(0.0f,0.0f); glVertex3f(x-hd,y-hd,z); glTexCoord2f(0.0f,1.0f); glVertex3f(x-hd,y+hd,z); glTexCoord2f(1.0f,1.0f); glVertex3f(x+hd,y+hd,z); glTexCoord2f(1.0f,0.0f); glVertex3f(x+hd,y-hd,z); x+=5.0f; glTexCoord2f(0.0f,0.0f); glVertex3f(x-hd,y-hd,z); glTexCoord2f(0.0f,1.0f); glVertex3f(x-hd,y+hd,z); glTexCoord2f(1.0f,1.0f); glVertex3f(x+hd,y+hd,z); glTexCoord2f(1.0f,0.0f); glVertex3f(x+hd,y-hd,z); }
Delphi-Quellcode:
Var
lphi : GLfloat; rphi : GLfloat;
Delphi-Quellcode:
jetzt meckert der compiler über diese zeile
for lphi := 0.0 to 189.0 do lphi := lphi + 13.5;
begin z := -9.0; x := (-sin((lphi+45.0)*M_PI/180.0)*2.0)-2.5; y := (-cos((lphi+45.0)*M_PI/180.0)*2.0)+yposition; glTexCoord2f(0.0,0.0); glVertex3f(x-hd,y-hd,z); glTexCoord2f(0.0,1.0); glVertex3f(x-hd,y+hd,z); glTexCoord2f(1.0,1.0); glVertex3f(x+hd,y+hd,z); glTexCoord2f(1.0,0.0); glVertex3f(x+hd,y-hd,z); x := 5.0; glTexCoord2f(0.0,0.0); glVertex3f(x-hd,y-hd,z); glTexCoord2f(0.0,1.0); glVertex3f(x-hd,y+hd,z); glTexCoord2f(1.0,1.0); glVertex3f(x+hd,y+hd,z); glTexCoord2f(1.0,0.0); glVertex3f(x+hd,y-hd,z); end;
Delphi-Quellcode:
for lphi := 0.0 to 189.0 do
Zitat:
Es muss doch möglich sein in einer schleife GLFloat zu verarbeiten.! Hier sagt er
Delphi-Quellcode:
lphi := lphi + 13.5;
Zitat:
|
Re: wieder konvertierungs problem
Hallo Emil,
mein Vorschlag:
Delphi-Quellcode:
Freundliche Grüße
for i := 0 to 14 do
begin lphi := 13.5 * i; // ... end; |
Re: wieder konvertierungs problem
Zitat:
ja würde super passen wenn nicht wieder ne meldung mit Zitat:
Also so gut wie ich mich bisher eingearbeitet habe das konvertieren der Variablen nervt erheblich. Der compiler motzt wieder weil 13.5 = single und i = integer gruss Emil |
Re: wieder konvertierungs problem
Deklariere lphi als Extended
|
Re: wieder konvertierungs problem
Zitat:
Hatte ich ja als Integer deklariert da es mit GLFloat nicht ging. Danke für den Hinweis gruss Emil |
Re: wieder konvertierungs problem
Alternativ gänge auch eine repeat- oder while-Schleife.
Delphi-Quellcode:
lphi := 0;
while (lphi < 189.0) do begin ... lphi := lphi + 13.5; end; |
Re: wieder konvertierungs problem
Hallo Mario,
sobald du Float-Werte zur (Schleifen-)Steuerung benutzt, arbeitest du nicht mehr mit exakten, sondern mit Schwellwerten. Darüberhinaus musst du dann wegen der möglichen Abbildungsfehler oft eine Epsilon-Umgebung betrachten. Es ist wirklich besser Integer-Werte zu benutzen, wenn es irgendwie möglich ist. Freundliche Grüße |
Re: wieder konvertierungs problem
Aha, eigentlich logisch, aber gewußt habe ich es noch nicht. Danke für den Tip. ;)
|
Re: wieder konvertierungs problem
Zitat:
Delphi-Quellcode:
for lphi : = 202.5 to 229.5 do
Zitat:
Das würde ja dann nicht mehr funktionieren!
Delphi-Quellcode:
habe es so gelößt
lphi := 13.5 * i
Delphi-Quellcode:
gibt bestimmt eine intelligentere methode(berechnung)
glColor3f(1.0,1.0,0.0);
lphi := 202.5; for i := 1 to 2 do begin if not (lphi = 216) then lphi := lphi + 13.5 * i else lphi := lphi + 13.5; gruss Emil |
Re: wieder konvertierungs problem
Direkt aus der Abteilung Transferwissen:
Delphi-Quellcode:
Freundliche Grüße
for i := 15 to 17 do
begin lphi := 13.5 * i; // ... end; |
Re: wieder konvertierungs problem
Zitat:
so einfach doch so umständlich(von mir) gruss Emil |
Re: wieder konvertierungs problem
ein prob hab ich noch dann läufts..
Code:
lmax=0;
rmax=0; for (i=0; i<576;i++) { ltemp=abs(wavedata[i]); if (ltemp>lmax) lmax=ltemp; } for (i=0; i<576;i++) { rtemp=abs(wavedata[i+576]); if (rtemp>rmax) rmax=rtemp; } lphi=(float)lmax; rphi=(float)rmax;
Delphi-Quellcode:
Die beiden Wertelmax := 0; rmax := 0; for i := 0 to 576 do begin ltemp := abs(wavedata[i]); if (ltemp>lmax) then lmax := ltemp; end; for i := 0 to 576 do begin rtemp := abs(wavedata[i+576]); if (rtemp>rmax) then rmax := rtemp; end; lphi := lmax; rphi := rmax;
Delphi-Quellcode:
müßten wieder nach single konvertiert werden da sonst integer angenommen wird.
lphi := lmax;
rphi := rmax; Dann sind die werte aber zu hoch und die VU ist auf anschlag. ;) PS: Gibt es eigentlich keine Grundregeln wie Integer zu single konvertiert werden kann? Ähnlich wie FloatToStr usw... Float wäre doch auch in Delphi single warum gibt es dann nicht sowas wie IntToFloat gruss Emil |
Re: wieder konvertierungs problem
Hallo Emil,
wenn wavedata ein array of Integer ist, dann geht es auch so:
Delphi-Quellcode:
Eine Konvertierung von Integer nach Float kann der Compiler automatisch vornehmen. Umgekehrt ist es wegen des Informationsverlustes in Pascal (Pascal ist nicht Basic oder Perl - alles ist strikt) nicht erlaubt, sodass du Trunc() oder andere Funktionen benutzen musst.
uses
Math; var lphi, rphi: Single; wavedata: array of Integer; begin lphi := MaxIntValue(Copy(wavedata, 0, 576)); rphi := MaxIntValue(Copy(wavedata, 576, 576)); end; Freundliche Grüße |
Re: wieder konvertierungs problem
Zitat:
Habe mir erlaubt dir eine PN zu schicken. Aber hier die Deklaration von wavedata
Delphi-Quellcode:
Daten werden so eingelesen!
Type
TWaveData = Array[0..576] Of byte; PWaveData = ^TWaveData; end;
Delphi-Quellcode:
In der PN habe ich mal näher geschildert (als ich die Antwort hier noch nicht kannte)
wavedata := @This_Mod^.WaveformData[0][0];
wo das problem liegt. Ich denke die berechnung über 'abs' so wie ursprünglich aufgeführt kann nicht funktionieren da die variablen ganz anderes deklariert sind in c++ Bekomm auch unabhängig jetzt von der konvertierung immer einen wert von 255. Was noch erschwerend hinzukommt ist halt das die konvertierung nach Single kläglich scheitert. Deine Variante habe ich mal geprüft geht aber wegen dem Array nicht.. Werd mal versuchen die umzustricken. EDIT: geht nicht wieder wegen konvertierungs problemen.. Danke wie immer Emil |
Re: wieder konvertierungs problem
Muss das nochmal aufgreifen.
Irgendwie will das immer noch nicht. Sieht aus wie ein schleichendes irgendetwas hat aber nichts mit der Visualisierung eines realen VU Meters zu tun. Niemand ne Idee wo oder was da falsch sein könnte ? Der Quelltext ist im SourceCode Forumsbereich. gruss |
Re: wieder konvertierungs problem
Hallo Emil,
wenn ich mir die Doku zur BASS.DLL anschaue, dann kommt mir der Verdacht, dass du mit deinem byteweisen Zugriff falsche Werte verarbeitest. Wenn du die Samples nicht explizit umschaltest, dann werden 16-bit Integer-Werte (SmallInt) geliefert. Prüfe das doch erstmal. Freundliche Grüße |
Re: wieder konvertierungs problem
Zitat:
Ja habe ich schon. Du darfst nicht von Bass ausgehen Sondern was du nicht wissen kannst du mußt von Winamp ausgehen dort werden die Wavedaten als byte übergeben genauso wie in meinen Plugin Wrapper für Winamp Plugins.
Delphi-Quellcode:
Deshalb habe ich auch die beiden Datentypen >
TWinAMPVisModule = record
Description : PChar; hWNDParent : HWND; hDLLInstance : HINST; sRate : Integer; nCh : Integer; LatencyMs : Integer; DelayMs : Integer; SpectrumNch : Integer; WaveformNch : Integer; SpectrumData : array[0..1,0..575] of byte; WaveformData : array[0..1,0..575] of byte; Config : procedure(This_Mod: PWinAMPVisModule); cdecl; Init : function(This_Mod: PWinAMPVisModule): Integer; cdecl; Render : function(This_Mod: PWinAMPVisModule): Integer; cdecl; Quit : procedure(This_Mod: PWinAMPVisModule); cdecl; UserData : Pointer; end;
Delphi-Quellcode:
als byte declariert.
TSpectrumData = Array[0..575] Of byte;
PSpectrumData = ^TSpectrumData; TWaveData = Array[0..575] Of byte; PWaveData = ^TWaveData; Ich habe das problem das die berechnung des exakten Bogenmaß irgendwie nicht mit den übergebenen werten von WaveData verglichen werden. Der effekt für das richtige Pendeln soll über
Delphi-Quellcode:
emuliert werden..
meterlphi := meterlphi+(lphi - meterlphi)*(dt*10.0);
wobei dt
Delphi-Quellcode:
eine art zeitverschiebung bewirken soll abhängig von
dt := currenttime - lastcurrenttime;
Delphi-Quellcode:
function GetTimes: single;
begin if (StartMilliseconds = 0) then StartMilliseconds := GetTickCount(); CurrentMilliseconds := GetTickCount(); Result := (CurrentMilliseconds - StartMilliseconds) / 1000.0; end;
Delphi-Quellcode:
danach wird das rendern ausgeführt.
specdata := @This_Mod^.spectrumData[0][0];
wavedata := @This_Mod^.WaveformData[0][0]; lastcurrenttime := currenttime; currenttime := GetTimes(); So wie es zur zeit ist funktioniert es zwar aber wie schon gesagt hat das nichts mit einen VU Meter zu tun. Das Teil schleicht nur so vor sich hin und reagiert nicht wirklich auf die übergebenen Sample Daten. Das originale Plugin 'StarflightAnalyze' (Quelltext habe ich vor Jahren vom Author bekommen(Marc Schneider)) funktioniert einwandfrei und wurde eigentlich auch richtig nach Delphi portiert. Verstehe nicht das es hier nicht richtig läuft. gruss Emil |
Re: wieder konvertierungs problem
Hallo Emil,
diese Player-Projekte sind nicht so richtig meine Welt, deshalb musst du alles was ich so von mir gebe sehr kritisch betrachten. Auf deinen Bildern erkenne ich, dass du für jeden Stereokanal ein 270-Grad Rundinstrument einsetzt. Der Grad-Winkel phi gibt dann zwar den Ausschlag an, aber der "echte" Winkel ergibt sich ja erst durch Addition auf den Startwinkel des Rundinstruments (225 Grad). Ob du diese Umrechnung zu Fuß richtig gemacht hast, das kannst du mit der Rechentechnik (DegToRad) aus diesem Beitrag überprüfen: ![]() Die Schwingungsdämpfung (Pendeleffekt) habe ich noch nicht ganz durchschaut. Ich stelle mir das so vor, dass der Wechsel zwischen diskreten Skalenwerten durch interpolierte Werte weich-gezeichnet wird. Ist das alles schon Bestandteil der C-Lösung, die du portierst oder ist das jetzt Neuland? Diese GetTimes-Routine kommt mir etwas seltsam vor. Stammt die von dir? Kannst du beschreiben, was du damit erreichen möchtest? Beim ersten Durchlauf wird 0 geliefert, später ein gebrochener Sekundenabstand. Der einzige Aufruf von DrawMeters() geschieht wohl in GLDraw() - und diese Prozedur wird vom Timer-Event alle 25 Millisekunden aufgerufen. Damit wird aber immer alles gezeichnet. Kann man denn das Zeichnen der Nadelausschläge und des eigentlichen Rundinstrumentes nicht voneinander trennen? Freundliche Grüße |
Re: wieder konvertierungs problem
Zitat:
Das weichzeichnen ist Bestandteil der C-Lösung wird aber durch GetTimes routine wieder aufgelößt dt .. der gebrochene Sekundenabstand wie du es nennst(Single) 0,xx werte wird zu den ausschlagwerten multipliziert dadurch entsteht der effekt das der Pendel in der zwichenzeit wieder auf 0 sinken kann. Durch den Schub dt*10.0 (dt=gebrochene Sekundenteil) bekommt das Pegel wieder eine aufwärtzbewegung plus der WaveDaten die in den moment ankommen. Dies geschieht aber nicht! Ob das nun an der berechnung des Winkel liegt muss ich nochmal prüfen. Da ich den Source in C++ persönlich vom Author bekommen habe werde ich ihn mal hochladen. Kannst dir das mal anschauen wenn du die zeit dazu hast... Wieder gelöscht ! Kann ihn bei bedarf über PN zusenden. Wie gesagt da funktioniert alles! EDIT: Die berechnung lass mal hingestellt sein ob sie richtig ist!
Delphi-Quellcode:
geschieht eigentlich schon im vorfeld beim c++ source
lphi := (lmax/270.0*128.0*13.5)/20.0;
Ich habe sie nur deshalb eingefügt weil ich lmax nicht zu single habe konvertieren können. original gibt es nur lphi := lmax; Nix anderes .. da sind der effekt des Pendelausschlag und die Daten für Wavedata schon enthalten. PS: Das zeichnen kann man nicht trennen muss man auch nicht da OpenGl schnell genug ist damit fertig zu werden. gruss Emil |
Re: wieder konvertierungs problem
Achtung!
Code:
ist nicht das gleiche wie
for (i=0; i<576;i++) // Stelle "A"
{ // }
Delphi-Quellcode:
sondern entweder:
for i := 0 to 576 do // Stelle "B"
begin // end; An Stelle A das schreiben:
Code:
for (i=0; i <= 576;i++)
Code:
oder an Stelle B das schreiben:
for (i=0; i < 577;i++)
Delphi-Quellcode:
;)
for i := 0 to 575 do
|
Re: wieder konvertierungs problem
Zitat:
Habe ich schon geändert in Delphi :) Sind ja ansonsten 1 byte zuviel. Gruss Emil |
Re: wieder konvertierungs problem
Moin Emil,
nach einer kurzen Diskussion mit Waldteufel komme ich zu dem Schluss, dass du die Wave-Daten eventuell falsch interpretierst. Du müsstest ein array of ShortInt definieren und nicht ein array of Byte. Nur so ist uns erklärlich, warum deine Portierung einen ständigen Vollausschlag produziert. Eine fehlerhafte Interpretation eines vorzeichenbehafteten Bytes würde genau diesen Effekt produzieren: Leise Passagen (-5 < 0 < +5) liefern Datenwerte bei 250, die du auf 128 begrenzt und laute Passsagen liefern Werte bei 128. Deshalb hatte ich dich nach der Mittellage bei 128 gefragt. Nachdenkliche Grüße |
Re: wieder konvertierungs problem
Zitat:
Waldteufel ? Wer ist das kenne ich nicht. Aber auch dahin viele grüße Das ist interessant werde umschreiben und vom Erfolg berichten. gruss Emil |
Re: wieder konvertierungs problem
Liste der Anhänge anzeigen (Anzahl: 1)
So!
Erst mal danke an alle die sich mit dem problem beschäftigt haben. Dank der info ShortInt .. funktioniert nun alles Top so wie es sein soll.
Delphi-Quellcode:
TSpectrumData = Array[0..575] Of ShortInt;
PSpectrumData = ^TSpectrumData; TWaveData = Array[0..575] Of ShortInt; PWaveData = ^TWaveData;
Delphi-Quellcode:
Es muss nichts extra berechnet werden da nun die richtigen werte in lmax,rmax enthalten sind.
lmax := 0;
rmax := 0; for i := 0 to 575 do ltemp := wavedata[i]; if (ltemp > lmax) then lmax := ltemp; for i := 0 to 575 do rtemp := wavedata[i+575]; if (rtemp > rmax) then rmax := rtemp; lphi := lmax; rphi := rmax; meterlphi := meterlphi+(lphi - meterlphi)*(dt*10.0); meterrphi := meterrphi+(rphi - meterrphi)*(dt*10.0); meterlphi := Max(Min(meterlphi, 128.0), 0.0); meterrphi := Max(Min(meterrphi, 128.0), 0.0); Auch das Oscilloscop sieht nun ganz anders bei der Visualisierung aus. Hier ein kleines Pic aus meiner Desktop collection (ich kann auch malen) Gruss Emil |
Re: wieder konvertierungs problem
off-topic: Malst du solche Bilder wirklich selbst? Entschuldige den mitschwingenden Zweifel, aber bei mir entartet immer alles in naive Kunst, sobald Fauna, Flora oder gar Menschen das Motiv bereichern sollen.
Beeindruckte Grüße |
Re: wieder konvertierungs problem
[OT]
@marabu: Ich äußere hier mal den sehr vorsichtigen verdacht, dass das das Album-Cover ist. Ansonsten muss ich dir sagen: 5 jahre am Gymnasium helfen einem sehr, insbesondere der Deutsch-Unterricht. Ich bin inzwischen so weit, dass ich Menschen malen kann, die ganz akzeptabel aussehen. Es gibt aber in meinem Umfeld mindestens 2 leute, die wirklich verdammt gut zeichnen können und sowas mit links hinkriegen würden. Mei, es ist eine Gabe und ein Fluch... und n Haufen Übung. [/OT] |
Re: wieder konvertierungs problem
Zitat:
Alles bis auf die Menschen die ich als Collage in den Hintergrund integriert habe. Mache das mit Photoshop und diversen Plugins Genesis usw... Ein bißchen Kreativität das wars dann schon. Die aufgesetzten Motive (PinUps) sind von einen Japanischen Künstler Sorajama. Unterliegen aber keinen Copyright ;) Hab die Bilder so um die jahrtausendwende mal erstellt. @Luke Kein Album-Cover. Von wem auch ? außer aus meiner Kreativität heraus... gruss Emil |
Re: wieder konvertierungs problem
Liste der Anhänge anzeigen (Anzahl: 2)
Push :duck:
Offtopic: Denke ich kann das vertreten... Für ungläubige hier meine komplette Gallerie incl... Flash Welche ich mal für meine Hompage erstellt habe.. Bilder bis 15... sind enthalten mehr konnte ich nicht hochladen da ein Archiv nur 3MB groß sein darf. gruss Emil |
Alle Zeitangaben in WEZ +1. Es ist jetzt 13:41 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz