Freeware Simulationssoftware erstellen

[BN]

Hallo Uwe,

Original geschrieben von UweG
Gibt es ein Programm, das zumindest die ersten 10 Punkte abdeckt? Ich kenne es dann jedenfalls nicht.

Hast Du Dir schon mal Soundeasy (http://www.interdomain.net.au/~bodzio/) angeschaut? Das ist ein Programm, das IMHO der "eierlegenden Wollmilchsau" schon nahe kommt.

Ich meine aber, daß bei der Festlegung des Funktionsumfangs für ein Programm vor allem die Zielgruppe berücksichtigt werden muß. Sind es die Boxenbau-Anfänger, die Fortgeschrittenen oder die Spezialisten? Das Ziel eines neuen Programms kann auch sein, nicht ein Programm mit besonders vielen Funktionen zu entwerfen, sondern eines, das sich besonders leicht bedienen läßt und mit dem gerade Anfänger gut zurechtkommen.

Bernhard

[not0815]

Hallo,

@UweG
das ist doch mal was konkretes.
Viele Deiner Wünsche sind in meinem WinBoxSimu bereits realisiert. Ausbau des Imports von Messdaten weiterer Formate dürfte auch kein Problem sein. Aber ingesamt sollte man sich in einem Foren-Projekt m.E. auf eine ordentliche Grundaustattung beschränken.

Jetzt mache ich erst 'mal Urlaub und werde dann mal sehen wie weit die Sache hier schon gediehen ist.

Gruß
Sven

[UweG]

Hast Du Dir schon mal Soundeasy (http://www.interdomain.net.au/~bodzio/) angeschaut? Das ist ein Programm, das IMHO der "eierlegenden Wollmilchsau" schon nahe kommt.

Dem ersten Eindruck nach ist das nicht ganz falsch. Allerdings nicht gerade Freeware (€199,-). Schick ist die Intergration eines Meßprogramms, das gefällt mir schon gut.
==> Ergänzung Lastenheft:
18. Wunsch: Integriertes Meßprogramm (da fehlt mir massiv Wissen zur Realisierung)

Ein weiterer Punkt wird auffällig, wenn man diese etwas anspruchsvollere Software ansieht: Da ist eine richtig schicke Doku! Den Gedanken daran habe ich bisher etwas vor mirt hergeschoben

[UweG]

Wenn ihr nichts ergänzt, dann mach ich eben weiter:

19. Abschätzung von Luftlastfaktoren bei Gehäuseeinbau und Einbau a la Downfire-Sub.
20. Chassis auch in Seitenwand und Rückwand ermöglichen
21. Optiional Reklexionen an Raumwand im Rücken mit berücksichtigen.

[Vince]

Plugin-Techniken statt Funktionsoverkill/unendliche Wunschliste von Anfang an ?

[jhohm]

Original geschrieben von Vince
Plugin-Techniken statt Funktionsoverkill/unendliche Wunschliste von Anfang an ?

Hi,
wenn es eine saubere Schnittstelle gibt, ist es kein Problem; Plugins zu schreiben und sich erstmal auf ein funktionierendes Grundprogramm zu konzentrieren...

Gruß Jörn

[GSD]

@Olli / Farad,

Uibel wird dabei nicht sehr behilflich sein.

1. weil es trotzdem Konkurrenz zu seinem AudioCAD ist

und

2. weil er nach Aufgabe der Weiterentwicklung von AudioCAD die Algorithmen nur verkauft (hatte selbst mal angefragt).

Meine weiteren Vorschläge:

- browserbasiert, serverseitig (ob lokal oder im Web) ANSI C/C++, dadurch nur neues Compile für anderes OS notwendig, keine Code-Änderungen, Präsentation komplett OS unabhängig und auch Web-fähig (mit dem Feature wär man allein)

- serverseitig kann ja sogar ein einfacher, kleiner Webserver implementiert werden zu Vereinfachung eines lokalen Einsatzes, damit keine Installation von Apache o.ä. notwendig ist

- Speicherung nicht in DB (oversized für ein paar hundert Treiber), sondern als XML-Doc


Java halte ich nicht für sonderlich genial, ist zwar interessant, aber performance- und resourcentechnisch eine Katastrophe !

Gruß

GSD

[UweG]

Ich nehme mal folgenden Input auf:
22. Strömungsgeschwindigkeiten in BR-Schächten und deren Auswirkungen abschätzen (einfach nur ne Zahl macht ja wenig Sinn)
23. Browserbasierte Lösung mit serverseitigem Programm in ANSI C/C++ auf einem Server und Präsentation komplett OS unabhängig und auch Web.
24. Speicherung in XML-Format

Den Punkt 23. halte ich für sehr interessant, muss aber zugeben, davon ziemlich wenig Ahnung zu haben.

Was meint ihr mit Plug-Ins? Ein zusärtzliches Feature in der Berechnung hat (i. A.) sowohl Auswirkungen auf Eingabe, auf Berechnung und auf die Ausgabe. Wie soll da eine einigermaßen handhabbare Schnittstelle aussehen?

Den Punkt "Effektivität der BR-Abstimmung in Anpassung an die Luft" habe ich nicht recht verstanden. Bitte nochmal erläutern.

Den Punkt, Speicherung im XML-Format verstehe ich ebenfalls nicht recht. Das was ich über XML finden konnte, weist eher auf eine Textbeschreibungssprache hin, aber kein Format um Daten zu speichern. Ich hätte eine ASCII-Datei mit Syntax ähnlich der .INI-Dateien in Windows vorgeschlagen.

[GSD]

@Uwe

wg. Plug-Ins:
richtig konzipiert eine interessante Sache. Das Plug-In müßte sowohl Eingabe, als auch Verarbeitung und Ausgabe definieren.

Mit einem ordentlichen Framework könntest du also einfach, sagen wir, ein Plug-In zur Simu von Hörnern hinzufügen, welches die Eingabemöglichkeiten entsprechend erweitert (TSP u.ä. bleiben ja bestehen), die Berechnung vornimmt und evtl. Erweiterungen an der Ausgabe (Daten, Charts, ...) einbaut.

Browserbasiert ist hier wieder im Vorteil, da die Präsentation durch einen Interpreter aufgebaut wird und sich mit einfachen Mitteln (HTML) anpassen, umbauen und erweitern läßt.

wg. XML:
XML ist eine Beschreibungsspache, die häufig für hierarchische Daten genutzt wird (wäre hier der Fall). Vorteil: JEDER kann mit Hilfe der DTD die Struktur verifizieren (Daten auch, aber nur in begrenztem Maße) und die Daten KORREKT lesen und schreiben. Export/Import wird vereinfacht. Das Format könnte sogar im Browser angezeigt werden.

Gruß

GSD

P.S.: webbasiert ist nicht sonderlich schwierig und kann schön in Schichten aufgebaut werden.

P.P.S.: wenn ich TMLS endlich fertig bekomme, kannst du dir ein Bild von der Speicherung der Daten in XML machen. Ist zwar schon fertig, hat aber noch einen sehr hartnäckigen Bug, für den ich noch keine Umgehung gefunden habe, da ereignis- und zudem noch vom Lebenszyklus versch. Instanzen abhängig

[UweG]

... und zudem noch vom Lebenszyklus versch. Instanzen abhängig

Da bin ich ja mal sehr gespannt. Vor allem darauf, wozu ein Simuproggi denn mehrere Instanzen braucht. Das muss doch merklich anders gestrickt sein, als ich mir so etwas derzeit vorstelle, aber umsomehr lohnt es sicherlich, das mal anzusehen.

[GSD]

Naja, nicht Instanzen der Applikation, sondern Instanzen von Klassen. Es handelt sich außerdem um eine MDI Anwendung.

Gruß

GSD

[Mad-Onion]

tot?

[UweG]

Ich bin da durchaus noch dran. Im Moment eher in Richtung Material sammeln, Algorithmen nachlesen, herleiten, überlegen .... und manchmal auch noch drei Zeilen in die Kiste häckern.

[Frankynstone]

Hi UweG und co.

Toll, dass ihr hier so mächtig am Sammeln für ein tolles Programm seid. Meine Idee für eine beliebige objektorientierte Programmiersprache wäre ja, dass beliebige Funktionen immer als neue Klassen hinzugefügt werden können. Das geht in BlueJ ganz prima, mit dem Nachteil, dass Programme, die in BlueJ geschrieben worden sind, nicht ohne weiteres Dranherumfaddeln als stand alone funktionieren.

Jede neue Funktion (plug in) bringt ihre eigenen Bedienoberfläche mit, gibt aber ein einheitliches Datenformat aus, was die anderen Klassen weiterverwenden können.

Es sollte möglich sein, ein Projekt in dem Programm anzulegen und zu entwickeln, etwa nach folgender Schrittfolge:

1. Beschreibe den Treiber (laden oder eingeben von Daten)

2. Überlagere den Gehäuseeinfluss (Innengeometrie und Dämmung)

3. Überlagere den Schallwandeinfluss (Breite, Treiberanordung, Fasen)

4. Überlagere aktive oder passive Weiche, und ermögliche händische Optimierung bei eigenem Schaltungsdesign oder opimiere automatisch die Weiche gemäß einer Zielfunktion bei einer Standardschaltung (passiver n-Pol, aktiver n-Pol).

5. Addiere die Anteile der einzelnen Chassis (mehrere Einzelprojekte), Resultat: Frequenz- und Phasengang, sowie elektrischer Phasengang und Impedanzverlauf.

6. Springe zu jedem beliebigen Zwischenschritt jedes beliebigen Einzelprojektes und berechne das Endergebnis neu.

7. Nimm den Benutzer an jeder beliebigen Position des Projektes an's Patschhändchen und führe ihn zum Ergebnis. Ein Ablaufplan (wo im Programm stecke ich jetzt, was bisher geschah, was jetzt kommt) ist sicher sinnvoll, quer ein- und aussteigen sollte das Programm erlauben (Speichern des Einzelprojektes bei beliebigem Enwicklungsstadium), um halbfertige Projekte fortsetzen zu können oder gewonnene Daten anderweitig weiterverarbeiten zu können.

8. Speichere das Ergebnis: Liste der ausgewählten Einzelprojekte (Treibername, Anzahl gleicher Treiber) mit deren tabellarischer Beschreibung (Gehäuseart und -größe, Dämmung, Schallwand) + resultierende Eigenschaftendatei (Wertetabellen der Diagramme von Phasen-, Zeit-, -Impedanz, Auslenkungs- und Frequenzgang und hastenichgesehn und kommstenichdrauf).

9. Gib die Ergebnisdatei aus Punkt 7 auf dem Bildschirm in Form der Einzelprojekttabellen und der Eigenschaften in Diagrammform auf dem Bildschirm aus (druckbare Grafik oder Pseudografik).

10. Jede Funktion sollte auch einzeln nutzbar sein, also gegebenen Frequenzgang und Impedanzverlauf mit einer Weiche verstümmeln und das Ergebnis ausgeben. Oder Daten und Frequenzgang einer Box und deren Treiber eingeben und ein Bassreflexrohr einfügen und das Ergebnis ausgeben.

Mir ist schon klar, dass das ein Monsterprojekt ist, egal welche Programmiersprache zum Einsatz kommen soll. In den Sprachen, die ich noch verstehe, also BASIC oder zur Not C ohne ++ ist es kaum mit vertretbarem Aufwand machbar. Objektorientierung ist schon beinahe Bedingung bei der Sprachwahl. Die Berechnungen an sich würde ich übrigens in eigene Klassen schmeißen. Denen könnten dann Frequenzen und so weiter übergeben werden und die Methoden (z. B. berechneVerstärkung, zeichneBildpunkt ...) werden verwendet.

Mein nächster Post zu einem anderen Teilbereich des Projektes ...

[Frankynstone]

Messgerät

Es wurde angeklungen, dass Lautsprecherparameter gemessen werden sollen.

Nun ist es kein Problem, einen Sinusgenerator, einen Verstärker, Strom- und Spannungsmesser, Mikrofonverstärker und Freqeunzmesser als Baugruppen für ein Messgerät aufzubauen. Schwieriger dürfte es werden, dieses Messgerät durch die serielle oder parallele Schnittstelle des Computers zu steuern. Eine schnöde Soundkarte, wie Soundblaster 16 Plug and Play, eignet sich nicht als Messgerät, weshalb ich die präzisen analogen Baugruppen bevorzugen würde und diese auch per Hand bedienen.

Wer die Geduld und Energie dazu hat, kann sich gerne mit mir in Verbindung setzen und wir eintwickeln ein Messgerät, was auch mit dem Computer interagiert, also meinetwegen für automatische Frequenzgangmessung und TSP-Erfassung, wobei der Computer den Sinusgenerator durchstimmt, die gemessene Frequenz und den dazugehörigen Pegel digital vom Messgerät zurück erhält. Die Soundkarte kann die Funktion des Frequenzzählers übernehmen.

Allerdings kann selbst der Frequenzmesser in das Messgerät integriert werden, womit das Messgerät beim Anschluss eines Multimeters als Ausgabegerät auch unabhängig vom Computer und für ganz andere Zwecke einsetzbar wäre. Messen von Kondensatoren und Spulen, als Eichgenerator für Drehzahlmesser oder Schalldruckmesser für Moped-Tuning zum Bleistift.

So, das war's erstmal wieder an wilden Ideen. Ich gehe jetzt an die Prüfungsvorbereitung, das ET-Studium ist nicht ohne. Insbesondere Informatik *wiesagichsbloß* hat es in sich.

mfg

FP