30.12.2016, 14:21
Hallo Kai,
das ist ein Artefakt dessen, dass ich noch nicht viel Zeit in Benutzerfreundlichkeit gesteckt habe: Die Sampling-Rate wird am Anfang des Testton-Erzeugung auf 96 kHz festgelegt - und ist ohne viel Aufhebens in einer Zeile zu ändern. Weil ich sowieso die ganze Zeit am Code herumbastele, war es so für mich nicht störend. Für einen Nutzer ist es aber befremdlich, wenn ich sagen muss "oh, und zum Ändern von diesem Parameter, ändere mal schnell in dieser Datei diesen Wert". Abhilfe ist nicht schwierig, mach ich als nächstes.
Bei der Analyse wird die Rate verwendet, die das gelesene File eben hat. Prinzipiell funktioniert das ganze mit 44.1 kHz genauso wie mit 192 kHz.
Nein, im Allgemeinen nicht. Hier aber vorerst schon, denn ich habe es noch nicht auf Python 3 ausprobiert. Die nötigen Änderungen wären wahrscheinlich nicht groß. Aus Trägheit habe ich mich noch nicht umgestellt... Mit nur geringfügigen Änderungen ist der Code jetzt auch auf Python 3 lauffähig - eben getestet und committed.
Auch dieser Punkt ist sehr richtig. Kurzfassung: Der magnetische Bezugspegel sollte dem -10dB-Pegelton zu Beginn entsprechen, dann ist 10 dB nach oben Luft. Ausprobieren, ob die Verstärker das alle mitmachen.
Jein. Ipython benutze ich selbst gerne als interaktive Python-Shell. Es hat eine schöne Verlaufshistorie, Tab-Completion und diverse Helferlein (z.B. zum Messen der Laufzeit oder Speichern der Historie). Eignet sich auch ausgezeichnet als Taschenrechner-Ersatz, wenn man es auf einen Tastatur-Shortcut legt
Ursprünglich habe ich die Analyseschritte einfach in einer langen, interaktiven IPython-Session ausprobiert, diese danach abgespeichert, bereinigt und in Bausteine zerlegt. Die Entstehungsgeschichte kannst Du in Git noch nachvollziehen. Leider ist dies das Gegenteil von testgetriebener Entwicklung, und deswegen ist die automatische Testabdeckung zur Zeit noch gleich Null. Nicht vorbildlich
Sehr beliebt ist auch das vormalige Ipython Notebook, jetzt als Jupyter bekannt, bei dem man in einem Browser Befehle, deren Ausgabe incl. Plots, und Kommentare zusammenführen kann. Im Hintergrund steuert es einen Ipython-Kernel an. Schwer zu erklären, wenn man es noch nicht gesehen hat, quasi ein interaktives Laborbuch, was auch ausführbar ist. Für diesen Zweck hier hilft es mir aber wenig. Wenn Du eine Analyse mit Zwischenschritten und Codebeispielen den Kollegen erklären willst, ist es aber ausgezeichnet.
Die Matplotlib ist eigentlich der Standard, wenn es um Plots in Python geht. Auch hier Bequemlichkeit und Gewohnheit: Seit ich laufen kann (naja), benutze ich Gnuplot, und habe mich noch nicht umgewöhnt. Es gibt zwar vieles, was mich stört, aber keine der Alternativen war bisher überzeugend genug. Leider auch die Matplotlib: Ihre API fand ich nicht sehr eingängig, wenig "Pythonic", mit seltsamen Nebenwirkungen und impliziten Kontexten und so weiter. Manche sagen, sie wäre Matlab nachempfunden - das kann ich nicht beurteilen. Ich muss mich früher oder später nochmal mit ihr auseinandersetzen, aber bisher habe ich das nicht getan.
Von daher - eigentlich wäre es nur logisch, wenn die Plots in einem Projekt mit NumPy und SciPy dann auch mit Matplotlib gemacht würden. Wäre ja mal ein Anlass...
Viele Grüße
Andreas
kaimex,'index.php?page=Thread&postID=197878#post197878 schrieb:Hast du mal dran gedacht, daß nicht jeder Interessent eine 96ksample/s fähige Soundkarte hat ?
Inwieweit ist das notwendige oder hinreichende Bedingung zur Anwendung deiner Software ?
Wäre auch eine Anpassung auf 48ksample/s möglich ?
das ist ein Artefakt dessen, dass ich noch nicht viel Zeit in Benutzerfreundlichkeit gesteckt habe: Die Sampling-Rate wird am Anfang des Testton-Erzeugung auf 96 kHz festgelegt - und ist ohne viel Aufhebens in einer Zeile zu ändern. Weil ich sowieso die ganze Zeit am Code herumbastele, war es so für mich nicht störend. Für einen Nutzer ist es aber befremdlich, wenn ich sagen muss "oh, und zum Ändern von diesem Parameter, ändere mal schnell in dieser Datei diesen Wert". Abhilfe ist nicht schwierig, mach ich als nächstes.
Bei der Analyse wird die Rate verwendet, die das gelesene File eben hat. Prinzipiell funktioniert das ganze mit 44.1 kHz genauso wie mit 192 kHz.
kaimex,'index.php?page=Thread&postID=197878#post197878 schrieb:2. Soll man die Finger von python 3.x lassen ?
Nein, im Allgemeinen nicht. Hier aber vorerst schon, denn ich habe es noch nicht auf Python 3 ausprobiert. Die nötigen Änderungen wären wahrscheinlich nicht groß. Aus Trägheit habe ich mich noch nicht umgestellt... Mit nur geringfügigen Änderungen ist der Code jetzt auch auf Python 3 lauffähig - eben getestet und committed.
kaimex,'index.php?page=Thread&postID=197878#post197878 schrieb:Nach Durchlesen deiner Erläuterung bei github habe ich den Eindruck, daß da noch eine Anweisung fehlt, mit welchem Pegel dein Testsignal aufzunehmen ist, bzw. bei welchem Teil-Testton "Vollaussteuerung" einzustellen ist, denn es muß doch sicher zur Bestimmung des MOL auch übersteuert werden, Gell ?
Auch dieser Punkt ist sehr richtig. Kurzfassung: Der magnetische Bezugspegel sollte dem -10dB-Pegelton zu Beginn entsprechen, dann ist 10 dB nach oben Luft. Ausprobieren, ob die Verstärker das alle mitmachen.
kaimex,'index.php?page=Thread&postID=197878#post197878 schrieb:Bei SciPy.org sehe ich auch noch IPython und Matplotlib. Sind die in diesem Zusammenhang nützlich ?
Jein. Ipython benutze ich selbst gerne als interaktive Python-Shell. Es hat eine schöne Verlaufshistorie, Tab-Completion und diverse Helferlein (z.B. zum Messen der Laufzeit oder Speichern der Historie). Eignet sich auch ausgezeichnet als Taschenrechner-Ersatz, wenn man es auf einen Tastatur-Shortcut legt
Ursprünglich habe ich die Analyseschritte einfach in einer langen, interaktiven IPython-Session ausprobiert, diese danach abgespeichert, bereinigt und in Bausteine zerlegt. Die Entstehungsgeschichte kannst Du in Git noch nachvollziehen. Leider ist dies das Gegenteil von testgetriebener Entwicklung, und deswegen ist die automatische Testabdeckung zur Zeit noch gleich Null. Nicht vorbildlich
Sehr beliebt ist auch das vormalige Ipython Notebook, jetzt als Jupyter bekannt, bei dem man in einem Browser Befehle, deren Ausgabe incl. Plots, und Kommentare zusammenführen kann. Im Hintergrund steuert es einen Ipython-Kernel an. Schwer zu erklären, wenn man es noch nicht gesehen hat, quasi ein interaktives Laborbuch, was auch ausführbar ist. Für diesen Zweck hier hilft es mir aber wenig. Wenn Du eine Analyse mit Zwischenschritten und Codebeispielen den Kollegen erklären willst, ist es aber ausgezeichnet.
Die Matplotlib ist eigentlich der Standard, wenn es um Plots in Python geht. Auch hier Bequemlichkeit und Gewohnheit: Seit ich laufen kann (naja), benutze ich Gnuplot, und habe mich noch nicht umgewöhnt. Es gibt zwar vieles, was mich stört, aber keine der Alternativen war bisher überzeugend genug. Leider auch die Matplotlib: Ihre API fand ich nicht sehr eingängig, wenig "Pythonic", mit seltsamen Nebenwirkungen und impliziten Kontexten und so weiter. Manche sagen, sie wäre Matlab nachempfunden - das kann ich nicht beurteilen. Ich muss mich früher oder später nochmal mit ihr auseinandersetzen, aber bisher habe ich das nicht getan.
Von daher - eigentlich wäre es nur logisch, wenn die Plots in einem Projekt mit NumPy und SciPy dann auch mit Matplotlib gemacht würden. Wäre ja mal ein Anlass...
Viele Grüße
Andreas