OnTopic Heute mehr Fehler/Bugs?

klangsulfat
klangsulfat
format c: /y
Wie kommt es eigentlich dass man heute so viel mehr Code braucht?
Ich nehme noch mal den SY99 als Beispiel, der kann mehr als die allermeisten heutigen Synths. Warum ging das mit weniger Code?
Für die Entwickler unter uns wahrscheinlich eine sehr dumme Frage....
Das ist keine dumme Frage. Damals steckten die Algorithmen sozusagen in "hartverdrahteten", hochspezialisierten Chips. Heute ist es Code, der von einem mehr oder weniger universellen Prozessor ausgeführt wird.
 
Feel Inc.
Feel Inc.
...
Wie kommt es eigentlich dass man heute so viel mehr Code braucht?
Ich nehme noch mal den SY99 als Beispiel, der kann mehr als die allermeisten heutigen Synths. Warum ging das mit weniger Code?
Für die Entwickler unter uns wahrscheinlich eine sehr dumme Frage....
Meiner Meinung nach 2 Gründe:
1. früher hatte man eher dumme und für sehr wenige spezielle Aufgaben einsetzbare Komponenten. Diese waren recht simpel zu programmieren. Heute geht man eher auf vollwertige Prozessoren (z.B. ARM), mit denen man zwar alles machen kann, dafür aber spezielle Funktionen selber implementieren muss
2. Verwendung moderner Hochsprachen anstatt Maschinencode/Assembler/C. Die modernen Hochsprachen sind universeller einsetzbar, man findet auf dem Arbeitsmarkt deutlich mehr Leute, die das können, als Leute die spezialisiert auf eine bestimmte Plattform sind. Die Hochsprachen schleppen allerdings viel "unnötigen Ballast" mit, den man theoretisch in vielen Fällen nicht bräuchte.
 
audiot.
audiot.
|||||||
Ein Quellcode hatte damals nur wenige KiloBytes. Heute beträgt er schon mehrere MegaBytes. Da sind Fehler nicht mehr ausgeschlossen.
Jain - die Anzahl der Codezeilen ("Lines Of Code") sagt eher etwas über die Komplexität von Software aus - und je komplexer Software, desto mehr Fehler sind theoretisch möglich.
(Anm.: die Komplexität wächst übrigens eher exponentiell statt linear im Verhältnis zu den "Features" bzw. Anforderungen)

Allerdings hat sich in den letzten 20 Jahren neben der Komplexität auch die Test-Methodik weiterentwickelt (Stichwort "Test Driven Development").
"Entwickler"-/Unit-Tests sollten integraler Bestandteil der zeitgemäßen SW-Entwicklung sein - und ist es dies nicht, dann hat das Unternehmen mit ihrem Produkt ein (selbstverantwortetes) Problem - und damit letzlich der Kunde.
(Anm.: Man hat z.B. über die Testabdeckung ein objektives Kriterium für die Qualität einer Software).

In der Realität kommt es aber durchaus gar nicht so selten vor, daß Tests keine größere Bedeutung beigemessen wird - Klassiker: Controller (rechte Hand vom "Chef") mit BWLer-Hintergrund hat entschieden, Tests seien zu teuer.

Wie kommt es eigentlich dass man heute so viel mehr Code braucht?
Z.B. weil heutige Software komplexere Probleme lösen muß als früher (wenn man nicht gerade einen Fahrstuhl-Controller programmiert).

Cool in diesem Zusammenhang find ich übrigens Akai (mit den modernen MPCs) - die zwar sicherlich nicht immer fehlerfreie Software geliefert haben, aber kontinuierlich Fehler beheben und das Produkt immer weiterentwickeln.
So etwas nennt man "iteratives Vorgehen" in der SW-Entwicklung.
 
betadecay
betadecay
Dronemaster Flash
Es sind aber nicht nur Synths, sondern alle Dinge die mit Software zu tun haben.
Ganz krass finde ich es im Bereich von Spielen, Anwendersoftware, Betriebssystemen usw.
Kommt ganz darauf an...

Wir hatten in der Firma eine Software, die ständig angepasst werden musste - die Nutzer gieren nach neuen Funktionen und es es müssen neue regulatorische Vorgaben eingearbeitet werden. Einmal im Jahr musste man updaten, das war Zwang vom Hersteller (sonst kein Support) und eben auch vom Gesetzgeber. Früher war das so, dass die User zwar das neue Release getestet haben, dabei wurden auch Fehler gefunden, die auch sofort behoben wurden, aber oft musste man schon am WE nach dem Update die ersten Patches installieren, weil erst im Tagesbetrieb die richtig üblen Hämmer auffielen. Man kann natürlich fragen, ob die User dann richtig getestet haben, richtig Zeit und Lust hatten die dazu ja nie, aber theoretisch hätten diese Fehler eigentlich gar nicht bei uns auffallen dürfen, sondern schon vorher beim Entwickler. Der Hersteller hat dann viel Geld für QM in die Hand genommen. Erfolg: nach dem Update haben wir oft 2, 3 Monate bis zum ersten Patch warten können. Und der wurde manchmal sogar nicht wegen Programmfehlern installiert, sondern weil es eine neue wichtige Funktion gab.
 
Jeltz
Jeltz
zerfrettelter Grunzwanzling
Verwendung moderner Hochsprachen anstatt Maschinencode/Assembler/C.
In Assembler programmieren ist zu Zeiten von 8 Bit Prozessoren ja noch "übersichtlich" gewesen. Auf einem 32 Bit µProzessor nicht mehr sinnvoll - das würde zu lange dauern. Das macht man bestenfalls nur noch für extrem Zeitkritische Stellen.
Damals steckten die Algorithmen sozusagen in "hartverdrahteten", hochspezialisierten Chips. Heute ist es Code, der von einem mehr oder weniger universellen Prozessor ausgeführt wird.
Interessanterweise sieht man sowas heutzutage wieder öfters, allerdings in Form von FPGAs (z.B. bei Elektron, Intellijel).
 
fanwander
fanwander
*****
Früher hat man die Fülle der "Bugs" möglicherweise gar nicht so mitbekommen, weil es noch wenig Netz und keine Foren gab.
Das glaub ich auch. Jedes Instrument, das ich aus den 80ern/90ern habe hat eigentlich Bugs, aber das wurde damals einfach nicht als behebbarer Fehler gesehen, sondern als Schwäche, die das Instrument halt hat, und mit der man aber leben muss. Die Bugfixes kamen dann oft in der Firmware des Nachfolgegerätes.
Nur so ein paar Beispiele:
TR-808 -> keine Umschalten von Play in Write im laufenden Betrieb (der Bugfix kam dann halt in der Firmware der 606)
JX-3P -> Start des Sequencer bei eingestecktem Trigger-Signalkabel aber ohne laufenden Trigger, löst die erste Note aus, obgleich noch gar kein Trigger ankam.
DX-7 -> MIDI-Send-Kanal nicht wählbar (Bugfix kam dann mit dem DX7II)
SDD-3000 -> Fast increment und gleichzeitig Write (oder wars eine andere Taste?) drücken hängt das Gerät komplett auf.
Ensoniq ESQ-1 -> diverse Absturz- und Freeze-/Noten-Hänger Situationen.
dito Alesis MMT-8 ...
MPC -> Das JJOS ist eigentlich als private Bugfix-Release für das grottige Akai OS begonnen worden, und hat sich dann zu einem selbständigen OS entwickelt
 
Zuletzt bearbeitet:
Feel Inc.
Feel Inc.
...
In Assembler programmieren ist zu Zeiten von 8 Bit Prozessoren ja noch "übersichtlich" gewesen. Auf einem 32 Bit µProzessor nicht mehr sinnvoll - das würde zu lange dauern. Das macht man bestenfalls nur noch für extrem Zeitkritische Stellen.
Absolut richtig und ich würde vor jedem, der heute ernsthafte Anwendungen in Assembler auf modernen Prozessoren programmiert, auf die Knie gehen (OK, ich würde vermutlich dabei überlegen, ob ich ihn nicht lieber einweisen lassen sollte ;-) )
 
Horn
Horn
||||||||||||
Sind heutige Instrumente noch viel komplexer?
Einige ja.

Ist das eine Verklärung der Vergangenheit, weil ich den Zeitpunkt der Markteinführung der alten Kisten nicht mitbekommen habe und die auch schon mit Fehlern gestartet sind?
Teilweise auch das.

Hatten Entwickler damals mehr Zeit?
Hatten die Firmen mehr Geld? (Testen kostet ja auch Geld.)
Große Firmen wie Roland oder Yamaha mit Sicherheit. (Aber eigentlich auch immer noch - deren Instrumente haben ja auch heute noch nicht so viele Bugs wie die der kleineren Hersteller.)

Ist man heute generell eher bereit mit Fehlern zu leben?
Nein, eher im Gegenteil. Heute werden durch das Internet Dinge breitgetreten, die in den 90er-Jahren 90% der Anwender nie bemerkt hätten.

Ist die Diskussion eigentlich überflüssig, weil die vermeintliche Häufung von Bugs eine Fehlwahrnehmung in der Forumsblase ist?
In gewisser Weise ja, siehe oben.

Ich finde die häufigen Bug Reports total abschreckend. Aber vielleicht ist das auch übertrieben?
Ich meine schon. Denn genau genommen kann man fast immer mit den Instrumenten ganz ohne Probleme Musik machen. Die wenigsten sind so verbuggt, dass das mit ernsthaften Einschränkungen verbunden wäre, wenn man ganz einfach nur Musik machen will. Man nimmt dann halt einfach die Einstellungen, die funktionieren.
 
betadecay
betadecay
Dronemaster Flash
Klassiker: Controller (rechte Hand vom "Chef") mit BWLer-Hintergrund hat entschieden, Tests seien zu teuer.
Unser Klassiker: der Fachbereich hat so schon genug zu tun, also bekommt der neue Mitarbeiter, der noch gar nicht richtig eingearbeitet ist, die Aufgabe, mal eben die Tests zu machen. Das kann nicht gut gehen. Und tat es oft auch nicht.

Oder: Fachbereich will nicht testen, weil "wir benutzen das Programm ja nicht selber". Ja, aber Ihr gebt die Daten, die anderer Abteilungen rechnen, an die Kunden raus und nur Ihr könnt deren Richtigkeit validieren. Es ist eure Aufgabe, das zu prüfen. Ach soo, na gut, wenn Sie meinen, na dann...
 
Martin Kraken
Martin Kraken
|||||||
Sicherlich.
Aber es kann doch nicht sein, dass man sich z.B. ein teures Spiel kauft, dieses dann installiert und dann geht erst mal richtig die Post ab.
50GB Update plus Installation, ein paar Stunden vergehen, während der Puls auf 200 steigt.

Der Unterschied ist, dass früher an so einem NES-Spiel vielleicht 3-4 Leute beteiligt waren, ein Spiel wie z.B. Cyberpunk hat einen Abspann mit Beteiligten der etwa 10 Minuten dauert. 130 Millionen Euro an Entwicklungskosten, die teilweise auf Pump sind und Zinsen kosten. Die Produktion der DVDs kostet Zeit, bis zu 2 Monaten. Also produziert man die vor. Außerdem ist der User auch anspruchsvoller geworden. Gab es früher ein paar kleine Fehler, war das relativ egal, Hauptsache man konnte das Spiel zu Ende spielen. Jetzt ist jede Textur die nicht rechtzeitig lädt ein Bug. Bei Synthesizern ist es sicherlich so, dass die Leute die diese produzieren auch alt geworden sind. Es gibt also einen riesigen Wasserkopf der auch ernährt werden will. Also muss alles schnell und billig produziert werden, zumal auch noch die Preise im Keller sind.
 
Feel Inc.
Feel Inc.
...
Der Unterschied ist, dass früher an so einem NES-Spiel vielleicht 3-4 Leute beteiligt waren, ein Spiel wie z.B. Cyberpunk hat einen Abspann mit Beteiligten der etwa 10 Minuten dauert. 130 Millionen Euro an Entwicklungskosten, die teilweise auf Pump sind und Zinsen kosten. Die Produktion der DVDs kostet Zeit, bis zu 2 Monaten. Also produziert man die vor. Außerdem ist der User auch anspruchsvoller geworden. Gab es früher ein paar kleine Fehler, war das relativ egal, Hauptsache man konnte das Spiel zu Ende spielen. Jetzt ist jede Textur die nicht rechtzeitig lädt ein Bug. Bei Synthesizern ist es sicherlich so, dass die Leute die diese produzieren auch alt geworden sind. Es gibt also einen riesigen Wasserkopf der auch ernährt werden will. Also muss alles schnell und billig produziert werden, zumal auch noch die Preise im Keller sind.
Hammer -> Nagel -> Kopf!
Die Programmierteams sind deutlich größer geworden, die Programme/Spiele deutlich komplexer. Ich erinnere mich auch noch an viele Spiele aus den 80er/90er Jahren, die von 2-4 Leuten KOMPLETT fertig gemacht wurden... inkl. Grafik und Musik. Und die Sachen passten auf eine Diskette (1.44MB). Dieses Phänomen mit großen Teams kann man ja selbst bei sowas wie Hausbau beobachten: Was meint ihr, wie viel da schief geht, wenn viele Gewerke an Board sind?
 
Olutian
Olutian
Arschimov
finde den golem artikel nicht mehr, aber da gabs einen bericht von rockstar / take two, dass aaa-titel nicht mehr unter 200 millionen dollar machbar sind.

wie viele läute es dafür braucht könnt ihr euch ja ausmalen. und deswegen kommen auch so viele re-makes...

je komplexer eine technik wird, desto mehr fehler können auftreten.

die zeiten von super nintendo sind längst vorbei.
 
Zuletzt bearbeitet:
MoogelPackung
MoogelPackung
||||
Die Zeiten bis zur Marktreife sind oft sehr kurz.

Genau das ist der springende Punkt.
Kürzere Produkt-Zyklen, Wettbewerbsdruck, Marketing ist oft wichtiger als eine vernünftige Entwicklung, das Controlling sitzt den Entwicklern auch noch im Nacken.

Was ich allerdings viel schlimmer finde ist, wenn Firmen ihre immer noch halbfertigen Produkte nicht einmal mehr wirklich fertig stellen, sondern die Entwickler stattdessen schon den nächsten Prototypen auf den Markt hauen.
... oder wenn (wie z.B. beim Korg Electribe) Bugs nicht gefixt werden, aber Entwickler-Ressourcen darauf verschwendet werden, die Geräte gegen Cross-Update zwischen verschiedenen Versionen zu verrammeln (die sich eigentlich nur durch Gehäusefarbe und Firmware unterscheiden).
 
rolfdegen
rolfdegen
|||||
Heutzutage sind Hardware-Fehler im Bereich der Musikelektronik nicht mehr vorhanden. Die Software-Fehler lassen sich in der Regel durch ein Firmware Update leicht beheben.
 
VEB Synthesewerk
VEB Synthesewerk
Thomas B. aus SAW
Der Unterschied ist, dass früher an so einem NES-Spiel vielleicht 3-4 Leute beteiligt waren,

Das glaube ich jetzt nicht so richtig.
Um mal beim Beispiel von Final Fantasy 8 für die PS1 zu bleiben.
Ich weiß natürlich nicht, wieviele Angestellte SQUARE zu der Zeit hatte...
Momentan sind es ca. 5000.
Vielleicht damals 1000?

Und auch so manches NES Spiel, wie ZELDA, kann man nicht mit 3-4 Leuten entwickeln.
Und Spiele, wie Super Mario World für das SNES sind bestimmt extremst aufwändig in der Entwicklung.

Fakt ist, der Kram funktionierte völlig fehlerfrei.
 
Summa
Summa
hate is always foolish…and love, is always wise...
finde den golem artikel nicht mehr, aber da gabs einen bericht von rockstar / take two, dass aaa-titel nicht mehr unter 200 millionen dollar machbar sind.

wie viele läute es dafür braucht könnt ihr euch ja ausmalen. und deswegen kommen auch so viele re-makes...

je komplexer eine technik wird, desto mehr fehler können auftreten.

die zeiten von super nintendo sind längst vorbei.
Ist ähnlich wie bei Hollywood Blockbustern, die Spiele werden durch das Budget nicht interessanter, man spielt auf Sicherheit und versucht ein möglichst großes Publikum zu erreichen mit Spielmechaniken (Stichwort: Rogue-Like) die aktuell im Trend liegen und Stories die den aktuellen Geschmack abdecken, z.B. die verf*ckten Dystopien. Viele Spiele sind eher sowas wie ein Filme den man durchspielt. Bei Synths ist das mit den Remakes ja auch sowas wie 'ne Seuche.
 
Martin Kraken
Martin Kraken
|||||||
Das glaube ich jetzt nicht so richtig.
Um mal beim Beispiel von Final Fantasy 8 für die PS1 zu bleiben.
Ich weiß natürlich nicht, wieviele Angestellte SQUARE zu der Zeit hatte...
Momentan sind es ca. 5000.
Vielleicht damals 1000?

Und auch so manches NES Spiel, wie ZELDA, kann man nicht mit 3-4 Leuten entwickeln.
Und Spiele, wie Super Mario World für das SNES sind bestimmt extremst aufwändig in der Entwicklung.

Fakt ist, der Kram funktionierte völlig fehlerfrei.

Also im Abspann von Zelda auf dem NES sind es genau 7 Leute. 2 Producer, 3 Programmierer, 1 Designer und einer hat den Sound gemacht. Das war sicherlich für damalige Zeiten schon eine riesen Produktion.
 
MoogelPackung
MoogelPackung
||||
Heutzutage sind Hardware-Fehler im Bereich der Musikelektronik nicht mehr vorhanden.
Kommt ganz darauf an, was man als Fehler einstuft. Ich könnte spontan mehrere Probleme bei aktuelle Geräten benennen, die ich für Hardware-Fehler halte.
Fängt an bei USB-MIDI ohne Potentialtrennung.
Geht weiter mit schlampiger Signal- und Masseführung, die zu unnötig schlechtem SNR führen.
 
BTH 3000
BTH 3000
|||||
Heutzutage kann man eben auch fast jedes Gerät schnell und einfach (sehr oft über USB) updaten. Das verleitet natürlich dazu Produkte beim Kunden "reifen" zu lassen...

Ich kaufe jedenfalls nie direkt etwas, warte normalerweise mindestens 1 Jahr bzw. lese dann noch mal nach wie der aktuelle Stand ist.
Das ist ein sehr gewichtiges Argument!
 
einseinsnull
einseinsnull
[nur noch musik]
von der allgemeinen entwicklung mal abgesehen- thema kurzlebigkeit und qualität - ist es vermutlich in der tat so, dass es heute mehr verschiedene prozessoren gibt, und dass es vor allem mehr layer sind mit denen man es da zu tun hat, bis hin zum FPGA, so dass es vermutlich dadruch irgendwie auch mehr fehlerquellen gibt.

gar nicht mehr beurteilen könnte ich dann die frage, ob es auch etwas mit der produktphilosophie zu tun hat, ob es nicht eifnach 1990 so war, dass man als hersteller etwas so eingerichtet hat, dass es auf ewig hin läuft, während man heute relativ bewusst halbfertige sachen ausliefert, so frei nach dem motto "wir können es ja updaten".

will sagen, früher hat man das gesamtprodukt als harwdare mit firmware betrachtet, heute betrachtet man es eher als programm mit kiste drumherum.

und wer hat schon etwas dagegen, wenn er sich einen virus B kauft und nach den nächsten update hat der plötzlich 2 stimmen mehr - oder der remote controller kann jetzt plötzlich auch zaquencer. es hat ja auch vorteile.

offenkundige fehler oder instabilitäten in geräten von 1990 sind mir auch unbekannt, das kann ich sofort bestätigen.
 
micromoog
micromoog
Rhabarber Barbara
Das glaub ich auch. Jedes Instrument, das ich aus den 80ern/90ern habe hat eigentlich Bugs, aber das wurde damals einfach nicht als behebbarer Fehler gesehen, sondern als Schwäche, die das Instrument halt hat, und mit der man aber leben muss. Die Bugfixes kamen dann oft in der Firmware des Nachfolgegerätes.
Nur so ein paar Beispiele:
TR-808 -> keine Umschalten von Play in Write im laufenden Betrieb (der Bugfix kam dann halt in der Firmware der 606)
JX-3P -> Start des Sequencer bei eingestecktem Trigger-Signalkabel aber ohne laufenden Trigger, löst die erste Note aus, obgleich noch gar kein Trigger ankam.
DX-7 -> MIDI-Send-Kanal nicht wählbar (Bugfix kam dann mit dem DX7II)
SDD-3000 -> Fast increment und gleichzeitig Write (oder wars eine andere Taste?) drücken hängt das Gerät komplett auf.
Ensoniq ESQ-1 -> diverse Absturz- und Freeze-/Noten-Hänger Situationen.
dito Alesis MMT-8 ...
MPC -> Das JJOS ist eigentlich als private Bugfix-Release für das grottige Akai OS begonnen worden, und hat sich dann zu einem selbständigen OS entwickelt
Die Frage ist, war alles wirklich Bug oder „nur nicht soweit gedacht“.

DX7 Send Kanal 1 war ab und zu nervig, aber war es ein Bug?
1983 wusste mit rund 4-5 Midi Synthesizern am Markt doch noch keiner wo die Reise hingeht.
Siehe die Handvoll „nur Omni Mode“ Synths der ersten Generation.
 
Neusiker
Neusiker
Paramusiker
(warum jedes mal "Rad" neu erfinden, wenn ich "Rad" günstig einkaufen und nutzen kann?
In der digitalen Welt ist das Rad eigentlich ein Polygon mit n Kanten. Wenn n von Komponente1 ungleich n von Komponente 2, passt es halt nicht mehr ganz und du brauchst eine Abstraktionsschicht, eine Vermittlungskomponente.

Die Wiederverwendung von Fremdcode ist Fluch und Segen zugleich in der IT. Ich bin über jede Zeile Code froh, die keine Abhängigkeiten nutzt. Und ich bin froh, dass bis heute kein IoT bei mir eingezogen ist. Ich betätige gern meine Lichtschalter direkt. Und ich bin froh, dass ich zum Musikmachen nur ein 08/15-Digi habe, sowie eine selbstprogrammierte Software zum Machen eigener Fehler auf synthetischem Gebiet, wiewohl sich manch Fehler schon als Erfolg entpuppt hat. Ich lerne viel lieber, wie was wirklich funktioniert. Lieber als wie eine API irgendeiner eierlegenden Wollmichsau angewendet wird. Noch naiver gehen die heutigen IT-Jüngelchen an die Sache heran: "Das geht doch irgendwie mit KI" - schon, aber änder mal irgend ein Detail an der Eingabe und es kann sein, dass aus einem 50-km/h-Schild ein Teelöffel wird, und die KI sagt dir nur schuld sind die Trainingsdaten, aber natürlich nicht, wo sie nicht die Realität wiederspiegeln. Realität, was ist das schon.

Am Ende könnte man die Diskussion zusammendampfen auf: You get what you pay for. If you don't get it (or you get more), your descendents will (get less). Die Kolonialzeit wird sich noch bitter rächen. Verbuggtes Spielzeug ist des Schicksals Kindergarten.
 
BTH 3000
BTH 3000
|||||
finde den golem artikel nicht mehr, aber da gabs einen bericht von rockstar / take two, dass aaa-titel nicht mehr unter 200 millionen dollar machbar sind.

wie viele läute es dafür braucht könnt ihr euch ja ausmalen. und deswegen kommen auch so viele re-makes...

je komplexer eine technik wird, desto mehr fehler können auftreten.

die zeiten von super nintendo sind längst vorbei.
Aber wieso schafft das die Autoindustrie mit globaler Arbeitsteilung, Dutzenden Zulieferern und dann noch als kundenindividualisiertes Massenprodukt?
 
MoogelPackung
MoogelPackung
||||
Kannst du mind. ein Gerät mit Potential-getrennter USB-Schnittstelle nennen?
Abgesehen davon dass es mehrere davon gibt...
...ist es wohl das Mindeste was man erwarten kann, dass beim Tunneln von MIDI-Daten über USB auch an die bei MIDI via Standard vorgesehene Potentialtrennung denkt und es nicht dem Anwender überlässt, da nochmal eine zusätzliche externe Schaltung nachzukaufen.
 
T
tulle
||
...ist es wohl das Mindeste was man erwarten kann, dass beim Tunneln von MIDI-Daten über USB auch an die bei MIDI via Standard vorgesehene Potentialtrennung denkt und es nicht dem Anwender überlässt, da nochmal eine zusätzliche externe Schaltung nachzukaufen.
Dafür hätten sich welche zusammensetzen müssen und eine verbindliche Spezifikation schreiben müssen. USB ist von Hause aus nicht potenzialgetrennt.
Audio ist bei Instrumenten meistens auch nicht mit Trafos getrennt. Wäre eigentlich auch sinnvoll.
 
MoogelPackung
MoogelPackung
||||
Dafür hätten sich welche zusammensetzen müssen und eine verbindliche Spezifikation schreiben müssen.
Ganz einfach mal das eigene Gehirn benutzen (wie damals die Erfinder von MIDI) hätte völlig gereicht.


Audio ist bei Instrumenten meistens auch nicht mit Trafos getrennt.

Und genau aus diesem Grunde muss jede andere Verbindung potentialgetrennt sein. Das ist ingenieurtechnisches Grundwissen.
 
 


Neueste Beiträge

News

Oben