Zitat von trashkid2000: |
Ich sehe da eindeutig zu viele
C#-Code: |
KillTasks();
|
|
tja .. leider ist die einzige Alternative die kontrolle über das DOS Tool zu nehmen und über windows an das Fenster den Druck der Space Taste zu simulieren - was am Ende übrigens nix anderes macht als das Programm zu beenden..
Vom Ablauf her sieht das so aus :
Programm mit Parametern starten .. dieses läuft dann im Shell Fenster und wartet auf "Space"-Druck in dieser Zeit zählt einfach nur ein Zähler die bereits abgespielten Samples.
Über 'Kill Prozess' stelle ich nur sicher das definitiv immer nur eine Instanz des Programms läuft da 2 Instanzen nicht gleichzeitig auf die ASIO Schnittstelle zugreifen können.
Was das Anpassen der KomboBox betrifft, hier wird diese Schleife vor der Freigabe der Box für den Benutzer modifiziert. Im Idealfall würde die Prüfung und Anpassung innerhalb weniger Millisekunden abgeschlossen sein. Der Grund für dieses unschöne Vorgehen ist, das ich über das externe Tool die "angeblich möglichen Samplefrequenzen" abfragen kann aber es mir leider immer alle von sich selbst unterstützten, jedoch nicht nur die von der Hardware unterstützen Frequenzen angibt. Daher muß ich, um es für den Benutzer möglichst ohne Fehlermeldungen laufen zu lassen, die Combobox immer beim Wechsel des ASIO Devices neu befüllen und dabei die nicht unterstützten entfernen.
Was ich mir jedoch als alternative Lösung vorstellen könnte, wäre:
Ich prüfe nur die kritischen Frequenzen und befülle dann die ComboBox mit den übrigen Frequenzen. Das wäre sicherlich auch vom Code her deutlich schöner und käme auch mit weniger Kills aus.
Abschließend nur ein Hinweis auf die Sleeps. Diese habe ich hinzugefügt weil es ohne Wartezeit z.T. Probleme beim Start des Shell Programms gab. Hier könnte ich sicherlich auch die Wartezeit noch etwas reduzieren.
Am Ende habe ich jetzt aber irgendwie den Eindruck das keiner von Euch mir sagen kann warum mein Programm hängt sobald das externe Tool gestartet wurde (und ohne Fehler läuft).