klangsulfat
SYS 64738
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.
||
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.
electric guillaume
keine Information
Früher hat man die Fülle der "Bugs" möglicherweise gar nicht so mitbekommen, weil es noch wenig Netz und keine Foren gab.
audiot.
Hitglied
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.
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
Dronemaster Flash
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
zerfrettelter Grunzwanzling
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.
Interessanterweise sieht man sowas heutzutage wieder öfters, allerdings in Form von FPGAs (z.B. bei Elektron, Intellijel).
fanwander
************************
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.
||
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
*****
Einige ja.
Teilweise auch das.
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.)
Nein, eher im Gegenteil. Heute werden durch das Internet Dinge breitgetreten, die in den 90er-Jahren 90% der Anwender nie bemerkt hätten.
In gewisser Weise ja, siehe oben.
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
Dronemaster Flash
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
Anfänger
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.
||
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
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.
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:
M
M15064
Guest
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).
VEB Synthesewerk
Thomas B. aus SAW
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
hate is always foolish…and love, is always wise...
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
Anfänger
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.
M
M15064
Guest
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.
![j[b++]](/synthesizer/data/avatars/m/5/5663.jpg?1501482891){kind=avatar}
j[b++]
Blub
Kannst du mind. ein Gerät mit Potential-getrennter USB-Schnittstelle nennen?
H
Hammerbrooklyn
Guest
Das ist ein sehr gewichtiges Argument!
Summa
hate is always foolish…and love, is always wise...
Yamaha Reface DX, Montage
einseinsnull
[nur noch PN]
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.
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.
Jörg
|||||||||||||
Das ist kein Bug.
Wenn Yamaha versprochen hätte man könne den Kanal wählen, und es würde nicht funktionieren: Das wäre ein Bug.
micromoog
Rhabarber Barbara
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.
D
D1g1t4l D3t0x3r
Offline bis Juli '24. Erreichbar via PN.
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.
H
Hammerbrooklyn
Guest
Aber wieso schafft das die Autoindustrie mit globaler Arbeitsteilung, Dutzenden Zulieferern und dann noch als kundenindividualisiertes Massenprodukt?
M
M15064
Guest
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.
tulle
Dilletant
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.
M
M15064
Guest
Ganz einfach mal das eigene Gehirn benutzen (wie damals die Erfinder von MIDI) hätte völlig gereicht.
Und genau aus diesem Grunde muss jede andere Verbindung potentialgetrennt sein. Das ist ingenieurtechnisches Grundwissen.
News
-
Rainy Day (bisher Otem Rellik) Hailström - Sampler & Drummachine- Gestartet von Moogulator
- Antworten: 1
-
-
SequencerTalk #206 Synthesizer Entwicklung über die Zeit, Rückschritte und Fortschritte und Neues
- Gestartet von Moogulator
- Antworten: 1
-
Knobula Pianophonic - Ein Piano für Leute die keine Pianos brauchen - Eurorack + MIDI!
- Gestartet von Moogulator
- Antworten: 1
-
9-11.5.2024, Fischbach bei Idar Oberstein, Modular Meeting Happy Knobbing 2024
- Gestartet von Moogulator
- Antworten: 0
-
-