Boxsim Weiterentwicklung..

[AlphaRay]

Schön zu sehen, dass es hier voran geht...!
Lustigerweise kam ich eben mal drauf den Status vom neuen BoxSim zu checken, da ich die Tage mal wieder dran dachte BoxSimToolbox weiter zu entwickeln... Bei mir hat sich die letzten paar Monate viel getan. Neben Jobwechsel (nicht mehr Selbständig) und Wohnungswechsel + doppelter Arbeit in den letzten vier Monaten (50-70 h die Woche) kam ich zu nichts. Die drei freien WEs die ich dieses Jahr nicht gearbietet hatte konnte ich zum entspannen nutzen.

Da sich die parallelen Projekte der alten Firma sich dem Ende nähern (gestern Mitternacht das letzte abgeschlossen nach einem 14h Arbeitstag vor'm Rechner ), wollte ich mich zumindest in den Pausen auf der Arbeit wieder an BST machen, wie also hauptsächlich bisher gelaufen ist
Der letzte Stand war, dass ich Uwe's Testversion von BoxSim mit Exportfunktion am testen war. Hierfür war ich BST komplett am überarbeiten, da die bisherigen Werte alle fest eingetragen waren und nicht auf Dateien basierten.

Falls jemand nicht weiß worüber ich rede:
http://visaton.de/vb/showthread.php?...=boxsimtoolbox

Letzter Stand + Download zum ausprobieren beim Post #46:
http://visaton.de/vb/showpost.php?p=402955&postcount=46

Wenn ich soweit bin, dass ich eine Projektdatei erfolgreich einlesen kann (aus: http://visaton.de/vb/showpost.php?p=409625&postcount=68 ), werde ich wieder eine neue Version online stellen

Programmiersprache C# wird bleiben - vorerst auch mit .NET 4.0 / WPF, wodurch die App momentan nur unter Windows lauffähig bleibt. Angedacht ist .NET Core, wodurch die Software zu Linux und MacOS kompatibel wird
https://www.microsoft.com/net/download/core#/runtime

Gruß
Paul

[ubix]

Hallo, ich habe gestern beim Simulieren ein kleinen Bug beim jetzigem Boxsim gefunden. Aber eher einen lustigen Bug.
Der automatische Weichenoptimierer optimiert wohl auch, wenn ein Lautsprecher gar nicht simulationsmäßig angeschlossen ist, wobei ganz nette Werte zustande kommen. Den BG 20 hat er aber recht gut linearisiert.

Dabei ist mir so nebenbei in den Kopf gekommen, das es gut wäre, wenn man dem automatischem Simulator Trennfrequenzen vorgeben könnte. Ev. für den neuen Simulator eine Möglichkeit, wie immer die man auch umsetzen könnte.

[UweG]

Hat mal jemand eine saubere Definition einer Trennfrequenz versucht.
Verwendet werden darf alles was in Boxsim eingegeben oder ausgerechnet wird. Also nicht: "Tieftöner", "Mitteltöner", ... So etwas gibt es in Boxsim nicht.

Wenn die Definition beide Trennfrequenzen einer VOX zutreffend beschreibt, bin ich (erstmal) zufrieden.

Beispiele die nicht funktionieren:
- Eine Trennfrequenz ist diejenige Frequenz bei der zwei Chassis auf Achse gleich laut sind.
- Bei der Trennfrequenz liefert ein Chassis die Hälfte des Gesamtpegels auf Achse.
- Bei der Trennfrequenz liefert ein Chassis den selben Pegel wie alle anderen Chassis zusammen.

Wie viele Trennfrequenzen hat eigentlich ein Chassis? 1, 2, Anzahl Chassis - 1, beliebig viele ?

[Burns]

Ist mir auch schon aufgefallen, das der Optimierer die Trennfrequenz des HT zu tief ansetzt. Ein Limit wäre da schon nicht schlecht.

Das Problem bei der Programmierung ist glaub ich, das wenn der errechnete Wert in den kritrischen Bereich kommt, wie das Programm reagieren soll? (kurve steiler setzen oder generell ändern)

Sonst: Weitere Ideen:

max. untere Trennfq=Resonanzfq(chassie1,2,3) x 1,4 (davon gelten die 2 höheren Werte

Direkteingabe

lg

[ubix]

Eigentlich ist es indirekt doch möglich, eine bestimmte Trennfrequenz vorzugeben. Als Beispiel BG20 und HTH 8.7. Ich kann für den BG 20 von Hand zum beispiel bei 5000Hz trennen, danach die Werte für Automatische Bauteileberechnung im Tieftonzweig deaktivieren, und Boxsim nur die Werte für den HTH 8.7 berechnen lassen.
Ansonsten kann es passieren, das Boxsim im Extremfall für den HTH 8.7 Werte berechnet, die der nicht verträgt.

Bzw, jetzt habe ich mal was versucht, was nicht ganz will.

[ubix]

Noch ein versuch?

Ich glaube, der HTH 8.7 ist nicht einfach zu berechnen.

Ich denke aber, das dies programmtechnisch extrem aufwendig wäre, die Berechnungen von unsinnigen Werten zu unterdrücken, bzw. dem Programm beizubringen, was es darf, und was nicht. Dazu müsste es von jedem Hochtöner z.b. noch die max. untere Grenzfrequenz wissen, usw.
Das soll die Leistung von Boxsim und gerade von UweG nicht schmälern, sondern es zeigt nur die "Logik" von Programmen auf. Wer ein Schachprogramm hat, weiß, das es da auch manchmal abenteuerliche berechnungen, oder versteckte Bugs gibt.

Aber vielleicht habe ich ja gerade auch mit meinen Überlegungen einen Bug

[ubix]

So, Hochtöner andersherum gepolt, und da werden die Werte wieder realistischer, wenn auch etwas ungewohnte Widerstandswerte.

Dabei belass ich es dann auch mal.

[jhohm]

Moin Ubix,

ich habe mal etwas gespielt; jetzt passt es mit der Phase etwas besser.
Ausserdem habe ich Normwerte eingegeben...

Gruß Jörn

[mechanic]

Der Martin hat bei der Entwicklung der CR Semilight mal schön dokumentiert, dass der BG20 sich nicht wirlich brauchbar simulieren lässt; es gibt da eine Messung mit der "BoxSim-Weiche" (total krumm) und die massiv abgeänderte Weiche für einen recht linearen Frequenzgang. Nur mal so am Rande ...

[ubix]

Der Martin hat bei der Entwicklung der CR Semilight mal schön dokumentiert, dass der BG20 sich nicht wirlich brauchbar simulieren lässt; es gibt da eine Messung mit der "BoxSim-Weiche" (total krumm) und die massiv abgeänderte Weiche für einen recht linearen Frequenzgang. Nur mal so am Rande ...

Da scheint leider was dran zu sein, wie ich nach einer Klickorgie feststellen muss.

[UweG]

Mal zurück zu Boxsim. Hat jemand zufällig irgendwo eine pir-Datei aus einer 2-Kanal-Messung mit "richtig" eingestelltem Arta herumliegen. Ich würde gerne mal ein neue Importroutine testen. Bitte ggf. mailen an die dort stehende Adresse Kontakt auf boxsim.de

[donhighend]

Hallo Uwe,

muss ich das verstehen? Du magst doch das.bch Format ohnehin nicht freigeben...

[UweG]

Wieso bch? pir-Dateien!

Die Idee ist, dass Boxsim nicht nur ASCII-Dateien mit Frequenzgang und Phase importieren kann, sondern die pir-Dateien des genialsten aller Lautsprecher-Messprogramme direkt verarbeiten können soll.
Ich finde, Arta und Boxsim sind ein gutes Paar und das soll noch besser werden.

[Peter K]

Hallo Uwe,

Die Idee ist, dass Boxsim nicht nur ASCII-Dateien mit Frequenzgang und Phase importieren kann, sondern die pir-Dateien des genialsten aller Lautsprecher-Messprogramme direkt verarbeiten können soll.

Ich befürchte, das macht keinen Sinn, denn die PIRs speichern, so weit ich weiss, nur das Zeitsignal und die Fensterungseinstellungen bei der Speicherung.
Da ARTA aber auch aus den PIRs auch .FRD und .ZMA Dateien exportieren kann (die man sich für den Import in Boxsim dann passend gefenstert hat), macht das mehr Sinn, und die Dateien kann man dann ja leicht in Boxsim importieren....

Ich finde, Arta und Boxsim sind ein gutes Paar und das soll noch besser werden.

Schon, mit dem gemessenen Frequenzgängen funktioniert das auch prima...
Allerdings haben die von Boxsim berechneten Winkelfrequenzgänge dann nur bedingt mit der Wahrheit zu tun, wenn man die mal mit echten Winkelmessungen vergleicht.

Gruß
Peter Krips

[UweG]

So richtig hilfreich ist die Diskussion hier irgendwie nicht.

1. Ich weiß grundsätzlich was in pir-Dateien stehen soll. Das steht auf Seite 69/70 im Arta-Handbuch (V1.90)

2. Dass Boxsim 1.20 mit der Richtcharakteristik von Chassis, die nicht mehr näherungsweise als Kolbenstrahler angesehen werden können, so seine Probleme hat, ist mir auch bekannt.

Was die "Wahrheit" ist, darüber können wir mutmaßen. Das Ergebnis von Messungen ist erstmal nur eine andere Abschätzung mit anderen Fehlern. Bei guten Messaufbauten kann das Messergebnis näher an der Wahrheit liegen als selbst bei einer guten Simulation, aber immer ist das definitiv nicht so.