Dokumentationstool für Musikproduktionen

[sonovice]

Hallo zusammen,

für die kommenden 1, 2 Jahre habe ich vor, ein Tool zur Dokumentation von Musikproduktionen (klassisch) zu programmieren.
Bevor ich näher darauf eingehe, vielleicht ein klein bisschen was als Hintergrund: Ich bin Tonmeisterstudent in Detmold und werde demnächst regelmäßig dazu "genötigt", eine (mehr oder minder) umfassende Dokumentation meiner Aufnahmeproduktionen zu machen. Statt jedes mal eine halbgare Excel-Tabelle zu erstellen und später noch handgezeichnete Bildchen einzuscannen, würde ich diesen Prozess gerne angenehmer und zu einem gewissen Teil automatisiert gestalten.

Die Software soll vorerst folgende Grund-Features bereitstellen:

• Aufnahme der Metadaten zur Produktion (Was wird aufgenommen? Wer spielt? Wo findet das ganze statt? etc.)
• Editor zur Erstellung einer Skizze (Draufsicht) der Instrumenten- und Mikrofonverteilung im Raum
• PDF-Ausgabe der Dokumentation

Später gäbe es noch eine Vielzahl von Erweiterungsmöglichkeiten wie z.B. Mikrofonverwaltung, nützliche Abstandsberechnungen etc., aber ich würde es gerne Schritt für Schritt angehen.

Soviel zum Vorhaben. Jetzt kommt der Ego-Part:
In meinem vorherigen Studium (Elektrotechnik) bin ich des öfteren mit C (für µC) und Java in Kontakt gekommen, habe allerdings nie größere Projekte realisiert. Da das ganze allerdings neben der Funktionalität einen gleich großen Anteil an Lehrreichtum für mich selbst bieten soll, habe ich mich aus vielerlei Gründen für Python als Sprache und Qt/PySide als GUI-Toolkit entschieden - natürlich einigermaßen Neuland für mich. Eine Einarbeitung in die Grundlagen habe ich bereits hinter mir, aber es ist bei einem Projekt dieser Größe schwierig, den richtigen "Einsteig" zu finden...

Aus diesem Grund habe ich diesen Thread hier erstellt: Wo fange ich am besten an? Klassendiagramme für die Model-Daten sind in Arbeit, aber da kommt mir manchmal die Freiheit Pythons etwas in die Quere - Wenn man alles darf, stolpert man gerne mal in die falsche Richtung. Die Java-Kenntnisse machen es diesbezüglich auch nicht gerade leichter...


In der Hoffnung auf fruchtbare Kommentare.
Herzlichst, sonovice

[Leonidas]

Hallo sonovice, willkommen im Forum,

Also was die Auswahl der Tools angeht - mit Python und Qt machst du vermutlich nichts falsch und es sollte deine benoetigte Funktionalitaet gut abdecken.

Aus diesem Grund habe ich diesen Thread hier erstellt: Wo fange ich am besten an? Klassendiagramme für die Model-Daten sind in Arbeit, aber da kommt mir manchmal die Freiheit Pythons etwas in die Quere - Wenn man alles darf, stolpert man gerne mal in die falsche Richtung. Die Java-Kenntnisse machen es diesbezüglich auch nicht gerade leichter...

Ja, die Java-Kenntnisse stehen da eher im weg, denn vergiss mal die Klassendiagramme. Die fuehren meiner Erfahrung nach dazu dass man irgendwelchen Stuss zusammendesignt und dann auf Teufel-komm-raus implementiert und dann kommt etwas raus was total furchtbar zu nutzen ist, weil ueberall Code rumfliegt der nicht noetig war, weil jemand dachte dass da ne Klasse hinmuss.

Ich wuerde es eher so machen: mir ueberlegen wie ich die Daten speichern will. Datenbank? Irgendwelche Dateien? Dann wuerde ich diesen Part implementieren, also eine Art Datenabstraktionsebene. Und dann wuerde ich mir parallel dazu ein Tool basteln mit dem man diese Daten aus der Konsole heraus bearbeiten will. Dann wurde ich erst die grafischen Tools basteln, die auf diese Daten zugreifen, und zwar von unten nach oben ("bottom up").

[sonovice]

Ich wuerde es eher so machen: mir ueberlegen wie ich die Daten speichern will. Datenbank? Irgendwelche Dateien? Dann wuerde ich diesen Part implementieren, also eine Art Datenabstraktionsebene.

Genau dafür wollte ich ja die Klassen nehmen. Zum Abspeichern sollten die Instanzen der Klassen dann serialisiert und anschließend in Dateien gespeichert werden. Als weitere Optionen würden mir sonst nur eine DB (z.B. SQlite) oder XML-Dateien einfallen. Beides dürfte vermutlich etwas aufwändiger sein, oder irre ich mich da?

Mir wurde aus der Java-Welt immer wieder eingetrichtert, ich solle meine Daten in Klassen kapseln und von außen nur durch entsprechende Funktionen zugänglich machen. Ist das eher eine schlechte Idee? Wie wird soetwas für gewöhnlich in Python gehandhabt?

[Leonidas]

Genau dafür wollte ich ja die Klassen nehmen. Zum Abspeichern sollten die Instanzen der Klassen dann serialisiert und anschließend in Dateien gespeichert werden. Als weitere Optionen würden mir sonst nur eine DB (z.B. SQlite) oder XML-Dateien einfallen. Beides dürfte vermutlich etwas aufwändiger sein, oder irre ich mich da?

Bei dir klang das halt als wolltest du jetzt irgendwie die große UML-Keule rauspacken und die ganze Applikation in Klassendiagrammen designen. Aber dann hab ich dich wohl falsch verstanden. Die Klassen kannst du serialisieren, das Problem ist dann nur ggf. dass diese Daten nicht sehr portabel sind und dann das Speicherformat quasi an dein Programm gekettet ist. Wenn du keine Interoperabilität (ggf. auch mit späteren Versionen deines Programmes) benötigst, dann ist das völlig in Ordnung. Oder wenn du dich anfangs lieber mit anderer Funktionalität beschäftigen willst.

Und natürlich meinte ich nicht dass du auf die Daten direkt zugreifen sollst, dass du eine Datenabstraktion haben solltest steht ja sogar explizit in meinem Post.

Datenbank ist etwas aufwändiger, aber auch keine Raketenwissenschaft, da würde ich einfach SQLAlchemy nehmen und fertig. Von XML würde ich zum Abspeichern der Daten eher abraten, außer du willst auf diese Daten unbedingt XML-Tools ansetzen, aber ansonsten hast du damit keine Vorteile, eher im Gegenteil.

[BlackJack]

@sonovice: Falls Du da an `pickle` dachtest — damit würde ich nichts längerfristig speichern was wichtig ist und nicht nur aus den Python-Grunddatentypen besteht. Denn bei allem was Du so speicherst, darfst Du die Klassen unf ihre Aufteilung in Module und Pakete nicht mehr ändern, wenn Du das problemlos wieder laden können möchtest. `pickle` eignet sich gut für Daten die nicht so wichtig sind, und auch anderweitig wieder hergestellt werden können, für einen Objekt-Cache beispielsweise, oder eben wenn man sich auf Grunddatentypen beschränkt. Wenn man diese auch ein wenig einschränkt, dann kann man aber auch ganz einfach JSON-Dokumente speichern und laden, mit dem Vorteil, dass dieses Format nicht auf Python beschränkt ist.

XML wäre auch eine Möglichkeit. Da ist Python mit den entsprechenden Modulen (`lxml`) auch angenehmer zu benutzen als Java mit der DOM-API.

Falls SQL-DB, dann würde ich SQLAlchemy als Abstraktion empfehlen. Damit ist man weitgehend unabhängig von der konkreten Datenbank die man darunter verwendet und hat neben einer programmatischen API statt SQL-Anweisungen aus Zeichenketten zusammensetzen zu müssen, auch ein ORM, wenn man da möchte.

Daten kapseln ist an sich eine gute Idee, das bedeutet aber nicht, dass man für jedes Attribut Zugriffsschutzmechanismen und lauter Getter-/Setter-Methoden braucht. Statt dem Benutzer den Zugriff auf Interna zu verbieten wird in Python ein führender Unterstrich zur Kennzeichnung verwendet. Wer das trotzdem direkt verwendet hat entweder gute Gründe dafür, oder schiesst sich halt auf eigene Gefahr in den Fuss. Das man bei Java für *alles* einen Getter/Setter anlegt, liegt daran, dass man später an dem Zugriff vielleicht mal etwas ändern möchte. Dafür gibt es in Python `property()` um „berechnete Attribue” zu realisieren. Semantisch ist ein Attribut für das es triviale Getter/Setter gibt, letztendlich ja doch ``public``. Die kann man sich dann also auch sparen.

[sonovice]

Okay, vielen Dank für eure Antworten. Als Fazit ziehe ich mal heraus, dass ich mir demnächst auch noch die SQL-Syntax geben werde.
Daraus ergibt sich aber eine völlig neue Denkweise für die Datenspeicherung. Ist eine Kapselung in Klassen dann überhaupt noch sinnvoll oder arbeitet man bei jedem Lese-/Schreibzugriff direkt mit der DB?

Ein weiteres Problem, dass sich mir beim Gedanken machen gestellt hat (auch auf die Gefahr hin, dass diese Überlegungen dank DB hinfällig geworden sein könnten):
Ich habe eine Klasse "Ensemble", die unter anderem eine Liste von "Musikern" enthält. Parallel dazu gibt es die Klasse "Mikrofon", welche u.A. eine Zuordnung zu einem "Intrument" hält. Diese "Instrumente" wiederum sollen auch auf die entsprechenden "Musiker" verweisen. Mit Java wäre das dank Call-by-Ref. kein Thema, aber wie mache ich solche Konstrukte mit Python? Einfach IDs verteilen und darüber "adressieren"?

[Leonidas]

Okay, vielen Dank für eure Antworten. Als Fazit ziehe ich mal heraus, dass ich mir demnächst auch noch die SQL-Syntax geben werde.
Daraus ergibt sich aber eine völlig neue Denkweise für die Datenspeicherung. Ist eine Kapselung in Klassen dann überhaupt noch sinnvoll oder arbeitet man bei jedem Lese-/Schreibzugriff direkt mit der DB?

Natürlich macht so eine Kapselung Sinn, das schaut dann so aus: Datenbank <- SQLAlchemy als SQL-Abstraktion <- Datenbank-Klassen als Abstraktion deiner Daten <- Deine Applikation Und SQL brauchst du gar nicht direkt von Hand schreiben, dafür gibt es SQLAlchemy. Man sollte natürlich mit den Konzepten dahinter auch vertraut sein.

Ein weiteres Problem, dass sich mir beim Gedanken machen gestellt hat (auch auf die Gefahr hin, dass diese Überlegungen dank DB hinfällig geworden sein könnten):
Ich habe eine Klasse "Ensemble", die unter anderem eine Liste von "Musikern" enthält. Parallel dazu gibt es die Klasse "Mikrofon", welche u.A. eine Zuordnung zu einem "Intrument" hält. Diese "Instrumente" wiederum sollen auch auf die entsprechenden "Musiker" verweisen. Mit Java wäre das dank Call-by-Ref. kein Thema, aber wie mache ich solche Konstrukte mit Python? Einfach IDs verteilen und darüber "adressieren"?

Python hat genauso Referenzen und etwas was Call-by-Reference ausreichend ähnlich ist. IDs als Primary Keys kommen in der Datenbank schon vor, weil das halt das ist wie man Daten in relationalen Datenbanken referenziert, aber aus deiner Applikation solltest du keinerlei Objekt-IDs oder ähnliches benötigen.

[snafu]

Falls es bei dir wirklich vornehmlich um eine Art objektorientierte Strukturierung von Daten geht, dann willst du dir vielleicht das Gegenstück zu Javas `HashMap`s mal näher ansehen: Den Datentypen `dict`. Bedenke, dass in Python viel über Annahmen geht, ohne dass man direkt zu Interfaces zwingt. Man könnte also durchaus Wörterbücher erwarten, die als Schlüssel auf jeden Fall `x`, `y` und `z` (bitte was sinnvolles einsetzen) haben.

Falls es etwas reglementierter ablaufen soll, dann bietet sich die Erstellung diverser Container-Datentypen via namedtuple an. Das ist eine Fabrikfunktion, der dir viel trivialen Code zur Erstellung solcher Klassenarten abnimmt. In der verlinkten Doku werden sogar ein paar Beispiele zur Überführung der Ergebnisse simpler Datenbankabfragen gezeigt.

Bedenke aber, dass in `namedtuple`s keine Methoden eingebaut werden können. Man müsste sich dann also überlegen, ob man explizit zwischen Klassen zur reinen Gliederung und Klassen mit Funktionalität unterscheiden möchte. Das kann an manchen Stellen sinnvoll sein, an wiederum anderen Stellen jedoch nicht. Aber eine gemischte Lösung (also teilweise `namedtuple`s und teilweise "richtige" Klassen, die mehr können, zur Strukturierung) muss ja nicht unbedingt verkehrt sein.