FastSwitch

[EWeiss]

Zitat von BUG:

Zitat von EWeiss:

Wie ein normal Mensch darauf kommen kann einfach den Button (taste) gedrückt zu halten ist mir unbegreiflich.

Das deutet darauf hin, das dass Navigieren durch die PlugIns umständlich ist. Ich würde das auch versuchen.

Um nochmal Furtbichlers ersten Vorschlag anzusprechen: Du solltest auf keinen die Benutzerschnittstelle verlangsamen; damit wirkt einfach dein Programm fehlerhaft.
Eher solltest du den Nutzer so schnell umschalten lassen, wie er möchte, und dann etwas verzögert das PlugIn nachladen (also wenn er sich "entschieden" hat).

Mittlerweile hatte er mir ja einen anderen Vorschlag unterbreitet aber da komme ich nicht mit klar bzw. müsste dann extrem viel ändern da meine Threads auf API ausgelegt sind.

So schnell wie man dann die Plugins läd können diese sich gar nicht initialisieren.
Also der User würde in dem Fall gar nicht sehen was er da laden bzw. in dem Moment für ein Plugin erwischt.

Das ist auch der grund warum man unter Winamp diese aus einer Liste unter Konfiguration wählen muss.
Ein umschalten zur Laufzeit ist gar nicht möglich.

Werde da wohl dann nichts ändern wenn die Anwendung meinen Wrapper so missbrauchen will
dann ist es letztendlich nicht mein Problem da in diesem Fall die Handhabung nicht durchdacht ist.

gruss

[Furtbichler]

Zitat von EWeiss:

Mittlerweile hatte er mir ja einen anderen Vorschlag unterbreitet aber da komme ich nicht mit klar bzw. müsste dann extrem viel ändern da meine Threads auf API ausgelegt sind.

Das geht mit reinen API-Calls genauso gut. Semaphoren bzw. Events bekommst Du mit einem API-Call, Events sind auch kein Geheimnis und wie man einen Thread mit 'BeginThread' startet, weißt Du ja auch. Die Idee dabei ist doch, das man die Arbeit von Threads untereinander synchronisieren muss und Windows alles bereit hält, um das sehr effizient umzusetzen.

[Sir Rufo]

Zitat von Furtbichler:

Zitat von EWeiss:

Mittlerweile hatte er mir ja einen anderen Vorschlag unterbreitet aber da komme ich nicht mit klar bzw. müsste dann extrem viel ändern da meine Threads auf API ausgelegt sind.

Das geht mit reinen API-Calls genauso gut. Semaphoren bzw. Events bekommst Du mit einem API-Call, Events sind auch kein Geheimnis und wie man einen Thread mit 'BeginThread' startet, weißt Du ja auch. Die Idee dabei ist doch, das man die Arbeit von Threads untereinander synchronisieren muss und Windows alles bereit hält, um das sehr effizient umzusetzen.

Trotz alledem es einfach ist - wenn man es verstanden hat - steht vor dieser Einfachheit eben genau dieses Verstehen. Und da hat der TE ja explizit hingewiesen, dass dieses Verstehen noch nicht vorhanden ist.

Also wäre eine Erklärung oder Referenz angebrachter als der Hinweis, dass das geht und eigentlich recht einfach ist.

Eine Erklärung / Referenz hätte ich auf die Schnelle aber auch adhoc nicht an der Hand

[EWeiss]

Zitat:

Also wäre eine Erklärung oder Referenz angebrachter als der Hinweis, dass das geht und eigentlich recht einfach ist.

Danke Ja!

Aber ich kann nicht von irgend jemand erwarten das er für mich code schreibt.
Daher muss ich es im Moment leider so belassen auch wenn es mich stört.
Ich muss erst mal schauen ob es ein Beispiel im Net gibt wo ich das mal schritt für schritt beim debuggen verfolgen kann.
das ist meine Lernmethode

Er hat mir ja freundlicher weise den weg gezeigt nur ich kann es nicht nachvollziehen weil es Anhaltspunkte sind.

Das ist mein Thread

Delphi-Quellcode:

function SoVisThread(glCtrl: PLongWord): DWORD;
//... nur nötiger teil
      repeat
        MsgReturn := GetMessage(Msg, 0, 0, 0);
        if ((Msg.message = WM_QUIT) or (Msg.message = WM_CLOSE)) then
          VisualizerQuitted := True
        else if Msg.message = DataReadyMsg then
        begin
          case Msg.wParam of
            DataReady:
              BassSoVis.SoRender(glCtrl^);
            RequestRestFlag:
              begin
                p1 := VisDataPointer;
                inc(p1, 70);

                p1^ := 0;
              end;
          end;
        end;

        TranslateMessage(Msg);
        DispatchMessage(Msg);
      until (integer(MsgReturn) <= 0) or VisualizerQuitted;
    end else
    PostMessage(BassSoVis.MessageHandle, DataReadyMsg, StartVisOut, 0);

  RenderThreadId := 0;

  Result := 0;
  ExitThread(0);

end;

Dieser wird beendet über

Delphi-Quellcode:

procedure TBASSSoVis.BassSonVisStop;
begin
  EndByProgram := True;

  if (RenderThreadId <> 0) then
  begin
    PostThreadMessage(RenderThreadId, WM_QUIT, 0, 0);

    repeat
      Sleep(15);
      WinProcessMessages;
    until RenderThreadId = 0;
  end else
  BassSoVisFree := True;

end;

gruss

Hier warte ich dann solange bis die RenderThreadId = 0 ist.
Also der Thread beim beenden diese auf 0 gesetzt hat.

nur beim schalten in Millisekunden Bereich funktioniert das nicht.
Auch das entfernen von Sleep(15) macht keinen unterschied.
Der Thread läuft noch während die anderen gestartet wurden.

gruss

[Furtbichler]

Zitat von Sir Rufo:

Trotz alledem es einfach ist - wenn man es verstanden hat - steht vor dieser Einfachheit eben genau dieses Verstehen. Und da hat der TE ja explizit hingewiesen, dass dieses Verstehen noch nicht vorhanden ist.

Boah. Emil meinte doch nur, das er mit meinem Pseudocode ('TXYZ.Execute...Terminate etc.') nicht viel anfangen kann, weil er nicht von TThread ableitet, sondern alles direkt mit der API macht. Wenn man nun das weiß, was ich noch dazuschrieb (eben das man alles über die API abwickeln kann), reicht das doch als Hinweis, das es diesbezüglich ('ich verwende nur reine API calls') keine Hürde gibt.

@Emil: Anstatt per sleep und in einer Repeat/Until-Schreife zu warten, bis der Thread fertig ist, kann man das auch über ein Event lösen: Du sagst dem Thread 'Hör auf' (per Message, wie gehabt) und wartest einfach ('WaitForSingleObject'), bis der Thread als letztes das Event setzt ('SetEvent').

Mein Beispielcode zeigt ja nur einen 'Workerthread', der also einfach wartet, bis es etwas zu tun gibt. Du machst etwas ähnliches, und zwar, indem Du dem Thread Messages schickst. Deine Plugin-Threads würde ich auch gar nicht mehr anfassen wollen. Es geht ja hier um eine Konfiguration, die nicht ruckeln soll, wenn ein Plugin geladen/entladen wird.

Packe also deine Lade/Beendenlogik in einen Thread, der genau diese beiden Dinge tut (Altes Plugin entladen, Neues laden).

[EWeiss]

Zitat:

@Emil: Anstatt per sleep und in einer Repeat/Until-Schreife zu warten, bis der Thread fertig ist, kann man das auch über ein Event lösen: Du sagst dem Thread 'Hör auf' (per Message, wie gehabt) und wartest einfach ('WaitForSingleObject'), bis der Thread als letztes das Event setzt ('SetEvent').

HI..
Jo genau das habe ich ja gemacht. Siehe hier

Delphi-Quellcode:

hEvent := CreateEvent(nil, True, False, nil);
PostThreadMessage(RenderThreadId, WM_QUIT, 0, hEvent);
WaitRe := WaitForSingleObject(hEvent, 1000);
CloseHandle(hEvent); 

SetEvent(Msg.LParam);

Aber es nutzt nichts.

Das nächste Plugin wird dann schon gestartet bevor der Thread überhaupt signalisieren kann.
Bei normalen starts signalisiert das Event und der Thread wird rechtzeitig beendet.
Aber nicht wenn die Plugins im MS Bereich geändert werden.

Anwendung / Mein Wrapper mit dem Thread (DLL) Plugins werden dann damit geladen wenn von der Anwendung angefordert.
Die Anwendung fordert das so schnell an das mein Thread da nicht mehr mitkommt.

Sah dann so aus

Delphi-Quellcode:

procedure TBASSSoVis.BassSonVisStop;
var
  hEvent, WaitRe: DWord;  
begin
   EndByProgram := True;

   if (RenderThreadId <> 0) then
   begin
     hEvent := CreateEvent(nil, True, False, nil);
     PostThreadMessage(RenderThreadId, WM_QUIT, 0, hEvent);
     WaitRe := WaitForSingleObject(hEvent, 1000);
     CloseHandle(hEvent); 
     
     if WaitRe = WAIT_OBJECT_0 then
        RenderThreadId := 0;

   end else
   BassSoVisFree := True;

end;

Das einzige was jetzt noch sein könnte..
BassSonVisStop kein Teil vom aktuellen Thread ist.

So wird der Thread erstellt.

Delphi-Quellcode:

SOThreadHandle := BeginThread(nil, 0, @SoVisThread,
                                      @BassSoVis.glCtrl,
                                      0, RenderThreadId);

Zitat:

Es geht ja hier um eine Konfiguration, die nicht ruckeln soll, wenn ein Plugin geladen/entladen wird

Ich weis jetzt nicht wie du ruckeln definierst..
Wenn du die AV damit meinst dann magst du recht haben.



gruss

[Furtbichler]

Zitat von EWeiss:

Delphi-Quellcode:

    hEvent := CreateEvent(nil, True, False, nil);
    PostThreadMessage(RenderThreadId, WM_QUIT, 0, hEvent);
    WaitRe := WaitForSingleObject(hEvent, 1000);
    CloseHandle(hEvent);

im Thread signalisiere ich wenn er beendet wurde
  SetEvent(Msg.LParam); Das trifft aber nicht rechtzeitig ein egal ob ich jetzt 1 oder 10 Sekunden übergebe

Verstehe ich nicht. Was 'trifft aber nicht rechtzeitig ein'. Wenn ich das teste, klappt es:

Delphi-Quellcode:

Program Project2;

{$APPTYPE CONSOLE}

Uses
  SysUtils, Windows, messages;

Var
  WaitRe, RenderThreadId, hEvent: Cardinal;

Function SoVisThread(glCtrl: PLongWord): DWORD;
Var
  MsgReturn: LongBool;
  Msg: tagMSG;
  VisualizerQuitted: Boolean;

Begin
  VisualizerQuitted := False;
  Repeat
    write('Thread loop');
    MsgReturn := GetMessage(Msg, 0, 0, 0);
    If ((Msg.message = WM_QUIT) Or (Msg.message = WM_CLOSE)) Then Begin
      Writeln('*** close received. set Event ');
      VisualizerQuitted := true;
    End;
    TranslateMessage(Msg);
    DispatchMessage(Msg);
  Until (integer(MsgReturn) <= 0) or VisualizerQuitted;

  SetEvent(hEvent);
  RenderThreadId := 0;
  Result := 0;
  Writeln('Thread finished');
  ExitThread(0);
End;

Begin
  hEvent := CreateEvent(Nil, True, False, Nil);

  BeginThread(Nil, 0, @SoVisThread, Nil, 0, RenderThreadId);
  Writeln('Thread created. Press ENTER to stop the thread');

  ReadLn;

  PostThreadMessage(RenderThreadId, WM_QUIT, 0, 0);
  Writeln('Close signalled, waiting for event');
  WaitRe := WaitForSingleObject(hEvent, INFINITE);

  CloseHandle(hEvent);
  writeln('Done (Press ENTER to terminate)');
  ReadLn;
End.

Ich habe das Event-Handle global deklariert, damit es vom Thread in jedem Fall verwendet wird und nicht nur dann, wenn es per Message übergeben wurde. Außerdem wartet 'WaitforSingleObject' jetzt solange, bis der Thread fertig ist.

[EWeiss]

Danke für deine Arbeit..
Werde das mal testen und bescheid geben.

Ja so geht es bei mir auch
Aber nicht wenn ich meinen Thread wenn er noch läuft in Millisekunden Takt erneut aufrufe.
PageUP/Down taste..


gruss

[Furtbichler]

Zitat von EWeiss:

Aber nicht wenn ich meinen Thread wenn er noch läuft in Millisekunden Takt erneut aufrufe.
PageUP/Down taste..

Was meinst du mit 'erneut aufrufe?' Du meinst, wenn Du ihm Messages schickst? Das sollte kein Problem sein. Wenn ja, dann ist in deinem Messagehandler etwas faul.

[EWeiss]

Zitat von Furtbichler:

Zitat von EWeiss:

Aber nicht wenn ich meinen Thread wenn er noch läuft in Millisekunden Takt erneut aufrufe.
PageUP/Down taste..

Was meinst du mit 'erneut aufrufe?' Du meinst, wenn Du ihm Messages schickst? Das sollte kein Problem sein. Wenn ja, dann ist in deinem Messagehandler etwas faul.

Wenn ich von der Anwendung in ms Takt ein neues Plugin zugewiesen bekomme das ich laden soll
habe ich genau das getan was du mir gezeigt hast siehe einige Post vorher.
Deshalb bin ich auch irgendwie jetzt leicht daneben warum ich immer noch im Thread herum werkle
während das nächste schon am laden ist.

Das Timing in Millisekunden funktioniert einfach nicht.
Das ist mein Problem.

Vielleicht versteht man mein Problem auch nicht richtig oder hab mich falsch ausgedrückt.
1. Start der Anwendung = 1 Plugin wird gestartet
2. PageUP wird gedrückt Plugin wird freigegeben über die API BASSVIS_IsFree
in Free wird nun mit BassSonVisStop der Thread gestoppt das Plugin entladen und die Resourcen freigegeben.
3. Während das Plugin in Free noch freigegeben wird kommt das nächste von der Anwendung über BASSVIS_ExecutePlugin
4. Ist bis dahin der Thread noch nicht beendet kommt es zu Problemen weil dann das Alte noch entladen wird.

VisInfo ist dann nicht mehr identisch mit dem das geladen/entladen wird.
Es kommt also unweigerlich zu Kuddelmuddel.
Bei normaler Verwendung geschieht das nicht nur wenn der Thread mit dem Timing nicht zurecht kommt.


gruss