Timing problem

[EWeiss]

Zitat:

Zitat von Luckie (Beitrag 1093807)

Zitat:

Zitat von EWeiss (Beitrag 1093805)

Wenn ich mein Window verschiebe hält der Song an.

Richtig weil dann dein Thread die Nachrichtenschleife abarbeitet und da stehe eben jede Menge Nachrichten zum Neuzeichnen an.

Ist Richtig und soll (muss) auch so sein.
Aber nicht das ich meine Anwendung aufgrund des Loops nicht mehr schließen kann.

gruss

[Trebxson]

Und was macht

Delphi-Quellcode:

  // Starte den Song
  while PlayingSong do
  begin
    //Weiterlaufen bis die 16.tel Note (Pause) abgelaufen ist
//    while GetTickCount < Tick + TempoWait do

    sleep (1000);
    Winprocessmessages;

    Tick := GetTickCount;
    PlayNotes;
    DrawGraphics(WinHandle);
    hsi.nPos := StartX + XSizeMid;
    SetScrollInfo(WinHandle, SB_HORZ, hsi, True);
  end;

?

[EWeiss]

Zitat:

Zitat von Trebxson (Beitrag 1093810)

Und was macht

Delphi-Quellcode:

  // Starte den Song
  while PlayingSong do
  begin
    //Weiterlaufen bis die 16.tel Note (Pause) abgelaufen ist
//    while GetTickCount < Tick + TempoWait do

    sleep (1000);
    Winprocessmessages;

    Tick := GetTickCount;
    PlayNotes;
    DrawGraphics(WinHandle);
    hsi.nPos := StartX + XSizeMid;
    SetScrollInfo(WinHandle, SB_HORZ, hsi, True);
  end;

?

Entschuldige bitte aber ich denke mal gar nichts.
Und das muss ich auch gar nicht erst ausprobieren ;)

Ich glaube da hilft nur noch die Knallharte Methode.. HALT;
Und das will ich eigentlich nicht.

gruss

[Trebxson]

Meinst du?

Was macht denn

Delphi-Quellcode:

while true do
 begin
 end;

> Leider muss ich feststellen das dieser sehr CPU lastig ist.
> Also 25% hab ich dann schon.

4 Kerne?

Was anderes machst du mit WinProcessMessages derzeit nicht außer Nachrichten behandeln. (Es sei denn deine Implementierung sieht inzwischen anders aus.)

[EWeiss]

Zitat:

Zitat von Trebxson (Beitrag 1093812)

Meinst du?

Was macht denn

Delphi-Quellcode:

while true do
 begin
 end;

> Leider muss ich feststellen das dieser sehr CPU lastig ist.
> Also 25% hab ich dann schon.

4 Kerne?

Was anderes machst du mit WinProcessMessages derzeit nicht außer Nachrichten behandeln. (Es sei denn deine Implementierung sieht inzwischen anders aus.)

Dein Sleep ohne es testen zu müssen sorgt dafür das die Anwendung für 1000ms schläft quasi einfriert.
das bedeutet alle 1000ms wird dann bei mir das Fenster und alles andere was damit zu tun hat weiterverarbeitet.

Was soll das werden wenn ich mir noch ne neue Bremse mit einbaue.

Zitat:

Ist das ein Baukasten oder hast du dir einen solchen selbst zurecht programmiert? Vielleicht gibt es Beispiele für deine Schleife.

Was für ein Baukasten das ist eine nonvcl Anwendung geschrieben in reinem WinAPI auf lowlevel Basis.

Bild im Anhang.

gruss

[Trebxson]

Aber ob deine Anwendung 1000 ms schläft oder 1000 ms in einer Schleife rennt, anstatt Musik zu spielen, das ist aus meiner Sicht das gleiche.

Und dass die 1000 ms nur der Platzhalter für das Tempo sind, ich dachte das wäre auch ohne Kommentar zu erkennen gewesen.

Ich weiß ja nun immer noch nicht ob PlayNotes Zeit verbrät oder gleich zurück kommt.

[Trebxson]

Verarbeitest du auch Eingabegeräte? Soweit ich gelesen habe haben die bei der Echtzeitverarbeitung von Musik die gleichen Probleme.

Meiner Meinung nach Schreit das nach einen Thread pro Aufgabe.

Ein Thread für das Formular und Nachrichtenbehandlung.
Einer für die Grafik womit das Formular gefüttert wird (auch wenn du Fenster bewegst).
Und einer für den Ton.

Sagt dir Lugert Verlag Forte etwas? Das macht genau das was du versucht umzusetzen. Nur mit einfacher Grafik.

[EWeiss]

Zitat:

Zitat von Trebxson (Beitrag 1093814)

Aber ob deine Anwendung 1000 ms schläft oder 1000 ms in einer Schleife rennt, anstatt Musik zu spielen, das ist aus meiner Sicht das gleiche.

Und das die 1000 ms nur der Platzhalter für das Tempo sind, ich dachte das wäre auch ohne Kommentar zu erkennen gewesen.

Ich weiß ja nun immer noch nicht ob PlayNotes Zeit verbrät oder gleich zurück kommt.

Playnotes prüft welcher notentyp gerade verwendet wird läd dann dementsprechend die Instrumente und starte die Note.

Delphi-Quellcode:

TNoteType   = (BlankNote, StartingNote, ContinuingNote);

Nach Playnotes geht es in DrawGraphics wo mit GDI+ die grüne Abtastleiste gezeichnet wird.
Und von da aus geht es dann in die Zeichnen routine für das Grid

Delphi-Quellcode:

DrawGrid(WinHandle);

Das ist im groben der ablauf.
Und das kann ich nicht auslagern unmöglich da alles zusammenhängt.

gruss

[EWeiss]

Zitat:

Zitat von Trebxson (Beitrag 1093815)

Verarbeitest du auch Eingabegeräte? Soweit ich gelesen habe haben die bei der Echtzeitverarbeitung von Musik die gleichen Probleme.

Meiner Meinung nach Schreit das nach einen Thread pro Aufgabe.

Ein Thread für das Formular und Nachrichtenbehandlung.
Einer für die Grafik womit das Formular gefüttert wird (auch wenn du Fenster bewegst).
Und einer für den Ton.

Sagt dir Lugert Verlag Forte etwas? Das macht genau das was du versucht umzusetzen. Nur mit einfacher Grafik.

lade dir doch einfach mal das Virtual Piano herunter (Projekte der Forummitglieder)
wenn du sehen willst was ich da mache.

Eingabegeräte verwende ich keine.

EDit:
Forte 180.00EUR Euronen .. ;)

gruss

[Trebxson]

> Eingabegeräte verwende ich keine.

Schade :)

D.h. PlayNotes startet nur, aber wartet nicht auf das Ende der Note.

Die Nachrichtenbehandlung wirst du für den Empfang von CloseQueries usw. schon brauchen. Nur solltest du das mit dem Sleep () kombinieren um deinen Wunsch nach weniger Auslastung gerecht zu werden.

Ich habe die Erfahrung gemacht, wenn im Formular z.B. ein Button gedrückt wird der in eine Schleife rennt, wird für die Dauer die zweite Schleife im selben Thread nicht weiter ausgeführt (ist auch irgendwie logisch). Daher wirst du nichts anderes erwarten können, wenn du das Fenster durch die Gegend schiebst, dass die Musik stoppt.

Mit dem Beispielcode wollte ich übrigens auch nur wissen ob die übrigen Anweisungen hängen.

Das sind so die Probleme die ich bisher erlesen konnte.