Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Object-Pascal / Delphi-Language (https://www.delphipraxis.net/32-object-pascal-delphi-language/)
-   -   Delphi wieder konvertierungs problem (https://www.delphipraxis.net/88826-wieder-konvertierungs-problem.html)

EWeiss 21. Mär 2007 16:55


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:
lphi+=13.5
wie müssen diese nach Delphi konvertiert werden ?
Komme da mit dem Fragezeichen nicht zurecht.

gruss Emil

Matze 21. Mär 2007 17:02

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:
lphi := lphi + 13.5;
Angaben ohne Gewähr. :stupid:

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:

RavenIV 21. Mär 2007 17:04

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.

EWeiss 21. Mär 2007 17:09

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

shmia 21. Mär 2007 17:23

Re: wieder konvertierungs problem
 
Oder ganz elegant als Einzeiler:
Delphi-Quellcode:
meterlphi := Max(Min(meterlphi, 128.0), 0.0);

EWeiss 21. Mär 2007 17:44

Re: wieder konvertierungs problem
 
Zitat:

Zitat von shmia
Oder ganz elegant als Einzeiler:
Delphi-Quellcode:
meterlphi := Max(Min(meterlphi, 128.0), 0.0);

Das kommt der IIF anweisung in VB am nächsten ;)
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:
      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;
jetzt meckert der compiler über diese zeile
Delphi-Quellcode:
for lphi := 0.0 to 189.0 do
Zitat:

[Pascal Error] VisCDRom.pas(775): E2032 For loop control variable must have ordinal type
Ich benötige aber die Variablen als GLfloat
Es muss doch möglich sein in einer schleife GLFloat zu verarbeiten.!

Hier sagt er
Delphi-Quellcode:
lphi := lphi + 13.5;
Zitat:

[Pascal Hint] VisCDRom.pas(775): H2135 FOR or WHILE loop executes zero times - deleted
Gruss Emil

marabu 21. Mär 2007 19:45

Re: wieder konvertierungs problem
 
Hallo Emil,

mein Vorschlag:

Delphi-Quellcode:
for i := 0 to 14 do
begin
  lphi := 13.5 * i;
  // ...
end;
Freundliche Grüße

EWeiss 21. Mär 2007 19:56

Re: wieder konvertierungs problem
 
Zitat:

Zitat von marabu
Hallo Emil,

mein Vorschlag:

Delphi-Quellcode:
for i := 0 to 14 do
begin
  lphi := 13.5 * i;
  // ...
end;
Freundliche Grüße

Du meinst weil 189/14 = 13.5
ja würde super passen wenn nicht wieder ne meldung mit
Zitat:

[Pascal Error] VisCDRom.pas(770): E2010 Incompatible types: 'Integer' and 'Extended'
kommen würde...

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

mkinzler 21. Mär 2007 19:59

Re: wieder konvertierungs problem
 
Deklariere lphi als Extended

EWeiss 21. Mär 2007 20:03

Re: wieder konvertierungs problem
 
Zitat:

Zitat von mkinzler
Deklariere lphi als Extended

ja sorry habe es gerade bemerkt :wall:
Hatte ich ja als Integer deklariert da es mit GLFloat nicht ging.

Danke für den Hinweis

gruss Emil

Nuclear-Ping 21. Mär 2007 20:12

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;

marabu 21. Mär 2007 20:19

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

Nuclear-Ping 21. Mär 2007 20:28

Re: wieder konvertierungs problem
 
Aha, eigentlich logisch, aber gewußt habe ich es noch nicht. Danke für den Tip. ;)

EWeiss 21. Mär 2007 20:39

Re: wieder konvertierungs problem
 
Zitat:

Zitat von Nuclear-Ping
Alternativ gänge auch eine repeat- oder while-Schleife.
Delphi-Quellcode:
lphi := 0;
while (lphi < 189.0) do
  begin
    ...
    lphi := lphi + 13.5;
  end;

wobei es hier auch wieder probleme mit der Berechnung gibt.

Delphi-Quellcode:
for lphi : = 202.5 to 229.5 do
Zitat:

229.5-202.5/13.5
Gut hier wäre der teiler 2 kann aber nicht bei null anfangen

Das würde ja dann nicht mehr funktionieren!
Delphi-Quellcode:
lphi := 13.5 * i
habe es so gelößt

Delphi-Quellcode:
      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;
gibt bestimmt eine intelligentere methode(berechnung)

gruss Emil

marabu 21. Mär 2007 20:42

Re: wieder konvertierungs problem
 
Direkt aus der Abteilung Transferwissen:

Delphi-Quellcode:
for i := 15 to 17 do
begin
  lphi := 13.5 * i;
  // ...
end;
Freundliche Grüße

EWeiss 21. Mär 2007 20:45

Re: wieder konvertierungs problem
 
Zitat:

Zitat von marabu
Direkt aus der Abteilung Transferwissen:

Delphi-Quellcode:
for i := 15 to 17 do
begin
  lphi := 13.5 * i;
  // ...
end;
Freundliche Grüße

ich bekomme die Krise .... heheheheh stimmt ;)
so einfach doch so umständlich(von mir)

gruss Emil

EWeiss 21. Mär 2007 21:54

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:
   

   lmax := 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;
Die beiden Werte
Delphi-Quellcode:
   lphi := lmax;
   rphi := rmax;
müßten wieder nach single konvertiert werden da sonst integer angenommen wird.
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

marabu 22. Mär 2007 09:35

Re: wieder konvertierungs problem
 
Hallo Emil,

wenn wavedata ein array of Integer ist, dann geht es auch so:

Delphi-Quellcode:
uses
  Math;

var
  lphi, rphi: Single;
  wavedata: array of Integer;

begin
   lphi := MaxIntValue(Copy(wavedata, 0, 576));
   rphi := MaxIntValue(Copy(wavedata, 576, 576));
end;
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.

Freundliche Grüße

EWeiss 22. Mär 2007 09:51

Re: wieder konvertierungs problem
 
Zitat:

Zitat von marabu
Hallo Emil,

wenn wavedata ein array of Integer ist, dann geht es auch so:

Delphi-Quellcode:
uses
  Math;

var
  lphi, rphi: Single;
  wavedata: array of Integer;

begin
   lphi := MaxIntValue(Copy(wavedata, 0, 576));
   rphi := MaxIntValue(Copy(wavedata, 576, 576));
end;
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.

Freundliche Grüße

Supi Danke für die Infos ...
Habe mir erlaubt dir eine PN zu schicken.

Aber hier die Deklaration von wavedata
Delphi-Quellcode:
Type
  TWaveData = Array[0..576] Of byte;
  PWaveData = ^TWaveData;
end;
Daten werden so eingelesen!
Delphi-Quellcode:
wavedata := @This_Mod^.WaveformData[0][0];
In der PN habe ich mal näher geschildert (als ich die Antwort hier noch nicht kannte)
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

EWeiss 24. Mär 2007 10:17

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

marabu 24. Mär 2007 10:20

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

EWeiss 24. Mär 2007 10:36

Re: wieder konvertierungs problem
 
Zitat:

Zitat von marabu
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

Hallo Achim

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:
  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;
Deshalb habe ich auch die beiden Datentypen >
Delphi-Quellcode:
  TSpectrumData = Array[0..575] Of byte;
  PSpectrumData = ^TSpectrumData;

  TWaveData = Array[0..575] Of byte;
  PWaveData = ^TWaveData;
als byte declariert.

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:
meterlphi := meterlphi+(lphi - meterlphi)*(dt*10.0);
emuliert werden..
wobei dt
Delphi-Quellcode:
dt := currenttime - lastcurrenttime;
eine art zeitverschiebung bewirken soll abhängig von
Delphi-Quellcode:
function GetTimes: single;

begin

   if (StartMilliseconds = 0) then
     StartMilliseconds := GetTickCount();


    CurrentMilliseconds := GetTickCount();
    Result := (CurrentMilliseconds - StartMilliseconds) / 1000.0;
end;
Delphi-Quellcode:
        specdata := @This_Mod^.spectrumData[0][0];
        wavedata := @This_Mod^.WaveformData[0][0];

          lastcurrenttime := currenttime;
         currenttime := GetTimes();
danach wird das rendern ausgeführt.

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

marabu 24. Mär 2007 20:11

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: drehpoti zeichnen

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

EWeiss 24. Mär 2007 20:37

Re: wieder konvertierungs problem
 
Zitat:

Zitat von marabu
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: drehpoti zeichnen

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

Hi Achim
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:
lphi := (lmax/270.0*128.0*13.5)/20.0;
geschieht eigentlich schon im vorfeld beim c++ source
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

xZise 24. Mär 2007 22:30

Re: wieder konvertierungs problem
 
Achtung!

Code:
for (i=0; i<576;i++) // Stelle "A"
{
  //
}
ist nicht das gleiche wie

Delphi-Quellcode:
for i := 0 to 576 do // Stelle "B"
begin
  //
end;
sondern entweder:
An Stelle A das schreiben:
Code:
for (i=0; i <= 576;i++)
Code:
for (i=0; i < 577;i++)
oder an Stelle B das schreiben:
Delphi-Quellcode:
for i := 0 to 575 do
;)

EWeiss 25. Mär 2007 08:56

Re: wieder konvertierungs problem
 
Zitat:

Zitat von xZise
Achtung!

oder an Stelle B das schreiben:
Delphi-Quellcode:
for i := 0 to 575 do
;)

Danke Fabian
Habe ich schon geändert in Delphi :)
Sind ja ansonsten 1 byte zuviel.

Gruss Emil

marabu 25. Mär 2007 10:35

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

EWeiss 25. Mär 2007 10:49

Re: wieder konvertierungs problem
 
Zitat:

Zitat von marabu
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

Moin Achim
Waldteufel ? Wer ist das kenne ich nicht.
Aber auch dahin viele grüße

Das ist interessant werde umschreiben und vom Erfolg berichten.

gruss Emil

EWeiss 25. Mär 2007 11:41

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:
   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);
Es muss nichts extra berechnet werden da nun die richtigen werte in lmax,rmax enthalten sind.
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

marabu 25. Mär 2007 11:57

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

DGL-luke 25. Mär 2007 12:05

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]

EWeiss 25. Mär 2007 12:06

Re: wieder konvertierungs problem
 
Zitat:

Zitat von marabu
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

Ja male ich selbst ;)
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

EWeiss 25. Mär 2007 12:28

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