Anmelden
Der Board-Partner EVGA trennt sich von Nvidia und will auch keine Grafikkarten für Intel und AMD herstellen.
© evga.com
In den vergangenen Jahren hat sich EVGA als Hersteller und Verkäufer von Grafikkarten einen Namen gemacht. Wer einen neuen Gaming-Rechner anschaffen wollte, hatte auch immer die GPUs von EVGA auf dem Schirm. EVGA beschränkte sich dabei auf Grafikkarten mit Chips von Nvidia, diese Zusammenarbeit wird nun beendet. Auf einer Pressekonferenz gab der Hersteller bekannt, dass man künftig keine Grafikkarten mehr entwickeln und produzieren werde. Von der kommenden Geforce-RTX-40-Serie wird es demnach keine EVGA-Modelle geben.
Auch Grafikkarten der Mitbewerber AMD und Intel will EVGA nicht fertigen. Die Produktion von Grafikkarten wurde komplett eingestellt. Hauptgrund für die Aufgabe des Herstellers sei eine langsam schlechter werdende Beziehung zu Nvidia. Dabei ginge es um Respekt. Aus finanzieller Sicht spreche wenig für eine Beendigung der Zusammenarbeit, man wolle aber aus Prinzip getrennte Wege gehen.
Zwar gebe es bereits erste Testmuster der RTX 4090 von EVGA, diese sollen allerdings nie in die Produktion gehen. An einer neuen Zusammenarbeit mit Intel oder AMD sei man ebenfalls nicht interessiert. Die damit verbundene Verkleinerung des Unternehmens nehme man dafür in Kauf. Käufer einer Grafikkarte von EVGA sollen auch weiterhin von einer Gewährleistung ihrer Karten profitieren können.
Bislang seien 75 Prozent der Umsätze von EVGA durch den Verkauf von Nvidia-Grafikkarten erwirtschaftet worden. Der Ausstieg dürfte entsprechend große Folgen für die Größe des Unternehmens haben. Die noch auf Lager liegenden RTX-30-Grafikkarten wolle man noch abverkaufen. Nvidia äußerte, dass man eine großartige Partnerschaft aufgebaut hätte. Man wünsche dem Unternehmen
alles Gute für die Zukunft
.
Hersteller Intel lässt sich in die Karten schauen: Mit Teardown und Übertaktungs-Tipps sollen Käufer angelockt werden.
Intel bringt mit den Intel Arc-Grafikkarten in diesem Jahr eigene GPUs auf den Markt, die sich gegen die etablierten sowie neuen Modelle von AMD und Nvidia behaupten müssen. Um Spieler weltweit für die neuen GPUs zu begeistern, hat Intel nun umfangreiche Informationen zur Übertaktung und zum Aufbau seiner Grafikkarten veröffentlicht.
Man habe sich bei der Entwicklung der Karten auf relativ konservative Taktraten beschränkt. Entsprechend könne durch eine Übertaktung der GPUs noch mehr Performance gehoben werden. Die entsprechenden Tools wie Intel Arc Control Performance Tuning stellt Intel selbst bereit, auch um die Garantie der Karten müssten sich Käufer keine Sorgen machen.
Als Beispiel für eine Übertaktung nennt Intel die Limited Edition der Arc A750 im Zusammenspiel mit “Hitman 3“. Über das Tastenkürzel “Alt“ und “i“ könne eine Steuerungskonsole angezeigt werden, die Daten zur Leistung in Echtzeit ausgibt. Nutzer können Werte für das Power Limit, die maximalen Temperaturen oder Spannung selbst ändern. Im gezeigten Beispiel konnte die Bildrate so von 90 auf 96 Bilder pro Sekunde gesteigert werden.
Außerdem hat Intel im Rahmen eines Teardowns gezeigt, aus welchen Komponenten die Arc A770 Limited Edition besteht: Unter dem matten Gehäuse findet sich eine von Intel entwickelte Kühllösung mit zwei Axial-Lüftern und Heatsink. Beide sollen die GPU-Chips unter 90 Grad Celsius halten und die Leistung von bis zu 225 verlässlich ableiten und dennoch leise arbeiten. Eingerahmt sind die Kühler von LEDs, die sich über die Software steuern lassen. Sogar auf der Rückseite hat Intel LEDs untergebracht.
Asus kündigt seine beiden neuen Gaming-Smartphones ROG Phone 6D und 6D Ultimate mit Mediateks Dimensity 9000 Plus an.
© Asus
Asus hat in dieser Woche seine neuen Gaming-Smartphones ROG Phone 6D und ROG Phone 6D Ultimate vorgestellt . Der einzige Unterschied zwischen den beiden Modellen liegt in der Speicher-Ausstattung und dem Kühlsystem. Während das ROG Phone 6D mit bis zu 16 Gigabyte RAM und 256 Gigabyte internem Speicher ausgeliefert wird, können Käufer des Ultimate auch eine Version mit 512 Gigabyte internem Speicher wählen. Für eine gute Kühl-Leistung beim Gaming soll das AeroActive-Portal an der Rückseite des Ultimate sorgen. Es kann über ein Scharnier angehoben werden und öffnet so einen Luftweg ins Gehäuse, der Wärme schnell abtransportieren soll.
Die übrigen Spezifikationen der Smartphones sind identisch. Sowohl das ROG Phone 6D als auch das 6D Ultra bieten einen AMOLED-Bildschirm mit 6,78-Zoll-Diagonale, einer Auflösung 2.448 x 1.080 Pixeln, HDR10+ und einer Bildwiederholfrequenz von bis zu 165 Hz. Im Gehäuse werkelt Mediateks Dimensity 900 Plus. Der Akku ist mit 6.000 mAh großzügig bemessen und kann mit 65 Watt schnell geladen werden.
An der Rückseite der beiden Smartphones verbaut Asus jeweils eine Dreifach-Kamera. Diese besteht aus einem Hauptsensor mit 50 Megapixeln, einer Ultraweitwinkel-Linse mit 13 Megapixeln und einer Makro-Kamera mit 5 Megapixeln. Die Front-Kamera löst mit 12 Megapixeln auf. Zur weiteren Ausstattung gehören ein klassischer Kopfhörer-Anschluss, Stereo-Lautsprecher, 5G, Bluetooth 5.3, NFC und ein im Display verbauter Fingerabdruck-Sensor.
Als mobiles Betriebssystem kommt Android 12 mit ROG UI und Zen UI zum Einsatz. Beide Smartphones wurden bislang nur für Großbritannien angekündigt. Dort kostet das ROG Phone 6D umgerechnet 910 Euro und die Ultra-Variante 1.366 Euro. Wann die Geräte in Deutschland erhältlich sein werden, ist noch unklar.
A few highlights ✨:
Detailed tracked changes.
Full changelog:
FreshRSS 
(author:Alice OR intitle:hello) (author:Bob OR intitle:world)!((author:Alice intitle:hello) OR (author:Bob intitle:world))search:"My query" or search:QueryA, or by ID: S:3pg_trgmdata/config-user.custom.php #4360archive.today #4530rename_attribute() instead of removing attributes to better be able to style/hide content of articles #4175,status_code type for PHP 8.1+ simplepie#728"ab cd" and ab-cd #4277& #4287' in the address #4330htmlspecialchars() warnings with PHP 8.1+ #4411freshrss_user_maintenance in CLI #4495errorMessage() which exists on some platforms #4289entry_before_insert to change entry->isRead() #4331php-openssl (used by PHPMailer) and php-xml (used by SimplePie) #4420freshrss/freshrss:newest to PHP 8.2 #4420base_url to avoid some common configuration bugs, especially via Docker / CLI #4423lib_phpQuery by PhpGt/CssXPath library for full content retrieval #4261
a[href*="example"] CssXPath#181.gitattributes export-ignore #4415attributes (JSON) for entries #4444Moog Mavis (c) Moog
Das Moog Mavis Selbstbaukit eignet sich gut als Einstieg in Synthesizer, nicht nur weil es East-Coast-Synthese mit West-Coast-Synthese verknüpft.
Jüngster Spross in der Produktpalette des traditionsreichen Synthesizer-Spezialisten Moog ist der analoge, monophone Synthesizer Mavis. Er basiert auf den klassischen analogen Moog-Schaltungen (sogenannte East-Coast-Synthese) und unterstützt zusätzlich Wavefolding aus der West-Coast-Synthese. (Wer sich für nähere Details interessiert, findet im Artikel über das ZeKit [1] eine Textbox, die wichtige Eigenschaften der verbreitesten Synthese-Stile beschreibt).
Das Schöne am Mavis ist dabei die Möglichkeit, eigene Signalwege zu kreieren. Dazu gibt es ein Patch-Bay, das erlaubt, viele Konfigurationen mit Hilfe von Patchkabeln zu definieren, womit Mavis einen semimodularen Ansatz bietet. Zudem dienen einige der Patchpunkte zum Anschluss externer Geräte wie einem Midi-Keyboard. oder anderen Synthesizern. Das geschieht allerdings über CV/GATE-Anschlüsse statt über Midi-Ports. Wer Mavis über ein reines MIDI-Gerät steuern will, benötigt demzufolge ein MIDI-to-CV-Interface. Siehe dazu den den Artikel auf bonedo.de [2]. Zum Glück verfügen selbst einige preisgünstige MIDI-Keyboards wie Arturia KeyStep sowohl über MIDI als auch über CV/GATE.
Im Prinzip stellt Mavis den würdigen und leistungsfähigeren Nachfolger von Moogs Werkstatt-01 dar (zum Artikel über Moog Werkstatt-01 [3]). Der Synthesizer lässt sich als alleinstehende Komponente nutzen, sieht aber auch den Einbau in ein Eurorack vor.
Das Produkt ist mit einem Preis von 399 Euro allerdings das Gegenteil von einem Schnäppchen, zumal in dieser Preiskategorie auch Synthesizer wie der Arturia Microfreak oder die Volca-Produktfamilie von Korg fallen, die teilweise mehr Funktionen zu einem günstigeren Preis offerieren. Auch ist für mein Gefühl der Preisunterschied zu anderen Moog-Produkten wie Mother-32, DFAM oder Subharmonicon zu gering.
Aber für Moog-Synthesizer sind nun mal auch Moog-Preise fällig. Abgesehen davon bietet Mavis viele Features fürs Experimentieren und Lernen. Die große Moog-Community ist ebenfalls von Vorteil, da sie zahlreiche Tipps und Informationen bereitstellt. Nicht zu vergessen der unverwechselbare Klang eines Moog-Synthesizers.
Mit einem Selbstbausynthesizer verbinden Benutzer komplizierte Lötarbeiten an der Hauptplatine, was aber in diesem Fall nicht zutrifft. Beim Zusammenbau ist lediglich das Montieren von 9 Schrauben und 24 Muttern notwendig, um nach geschätzt 15 Minuten den fertigen Synthesizer in Betrieb nehmen zu können. Das zugehörige 12V-Netzteil ist übrigens im Lieferumfang vorhanden. Ein Batteriebetrieb ist nicht vorgesehen.
Eine große Herausforderung ist die Montage also nicht und stellt selbst ungeschickte Zeitgenossen nicht auf die Probe.
Die Bedienelemente des Mavis sind in verschiedene Bereiche unterteilt:
VCO (Voltage-Controlled Oscillator) ist die Komponente, die das Ausgangssignal beziehungsweise die gewünschte Wellenform erzeugt. Dabei ist die Auswahl von Sägezahn- und Rechteckswellen vorgesehen. Beide Wellenformen lassen sich durch den Drehknopf VCO WAVE fließend ineinander verschmelzen. Für Rechteckswellen können Musiker mittels PULSE WIDTH einstellen, wie lange sich das Signal auf Level HIGH oder Level LOW befinden soll. Zwei Modulationsquellen, entweder der Hüllkurvengenerator (EG = Envelope Generator) oder der LFO (Low Frequency Oscillator), erlauben Tonhöhe und Pulsweite dynamisch zu verändern. Dazu später mehr. Das funktioniert in etwa so, als würde man die entsprechenden Drehpotis periodisch hin- und herdrehen. Wir haben es also mit einer Form von Automatisierung zu tun. Die Knöpfe PITCH MOD AMT und PWT AMT steuern dabei wie stark die entsprechende Modulation von Tonhöhe oder Pulsweite sein soll.
VCF (Voltage-Controlled Filter) dient zum subtraktiven Formen des VCO-Signals. So ist die Frequenz einstellbar, ab der das Audiosignal gekappt werden soll (CUTOFF). RESONANCE nimmt einen Teil des so erzeugten Audiosignals und dirigiert diesen Teil erneut zum Filter um. Dadurch kann es sogar zur Oszillation des Filters kommen. Wie der VCO enthält auch der VCF den Hüllkurvengenerator (EG) und den LFO als zwei potenzielle Modulationsquellen, um die CUTOFF-Frequenz dynamisch zu variieren. Mittels des Drehknopfes VCO MOD MIX ist eine Kombination aus beiden Modulationsquellen einstellbar, während VCF MOD MIX bestimmt, wie stark die Modulation des Cutoff-Parameters sein soll.
Der VCA (Voltage-Controlled-Amplifier) ist der dritte im Bunde, was den grundsätzlichen Signalpfad betrifft. Wie nicht anders zu erwarten, kontrolliert diese Komponente über VOLUME die Lautstärke, die entweder konstant bleibt oder sich über den Hüllkurvengenerator dynamisch verändern kann. Das resultierende Ausgangssignal liegt dann am Kopfhörerausgang an. Der Schalter VCA MODE definiert, ob ein konstantes Ausgangssignal anliegen soll (Position: ON) oder der Hüllkurvengenerator die Ausgangslautstärke beeinflusst (Position: EG).
Der LFO (Low-Frequency Modulator) ist, wie bereits erwähnt, eine der beiden möglichen Modulationsquellen. Einstellbar sind die Frequenz des LFO über LFO RATE und die dafür verwendete Wellenform über LFO WAVE. Möglich sind hier Dreieckswellen oder Rechteckswellen.
Ein Hüllkurvengenerator EG bestimmt, was hinsichtlich des Signalverlaufs im Detail passieren soll, sobald der Anwender eine Taste des Keyboards drückt.
Es handelt sich entsprechend um eine ADSR-Hüllkurve.
Im Bereich KEYBOARD des Mavis befinden sich 13 Tasten von Note C bis Note C1. Beim gleichzeitigen Drücken zweier Tasten gibt Mavis der niedrigeren Note Vorrang, da es sich um einen monophonen Synthesizer handelt. Mehr als ein erzeugter Ton gleichzeitig ist nicht.
UTL (Utilities) erlaubt die Parametrisierung bestimmter Funktionen, die nur im Patch-Bay verfügbar sind. Das geschieht durch Anschluss von Kabeln. Der Drehknopf FOLD steuert das Wavefolding und ermöglicht dem Musiker, der vom Oszillator erzeugten Wellenform weitere Obertöne hinzuzufügen. Das funktioniert freilich nur, wenn der Musiker ein entsprechendes Signal an FOLD IN anschließt. Mittels ONE LVL lassen sich Eigenschaften wie etwa die Signalstärke des am Eingangsanschluss ONE(-5) anliegenden Audiosignals reduzieren beziehungsweise variieren. ATTENUATOR leistet dasselbe für Audiosignale, die am ATTN(+5) Eingangsport eingespeist werden.
In der Lieferung von Mavis befinden sich 5 Patchkabel (3,5mm-Miniklinkenstecker) und 5 beispielhafte Patchschablonen zum Auflegen auf das Bedienfeld. Die Schablonen zeigen an, welche Schalterstellungen der Benutzer für den jeweiligen Patch wie stellen soll, und welche Patchverbindungen notwendig sind. Auf diese Weise erhält der Musiker schon mal eine Grundlage für eigene Experimente.
Insgesamt befinden sich 24 Buchsen auf dem Patch-Bay, wovon 13 als Inputs und 11 als Outputs dienen. Die Inputs sind jeweils mit Standardtext betitelt (weißer Text auf schwarzem Hintergrund), während die Outputs in umgekehrter Darstellung (schwarzer Text auf weissem Hintergrund) notiert sind. Ohne veränderte Signalwege durch einen Patch lösen die Tasten des Keyboards sowohl den VCO als auch den EG aus, von wo die erzeugte Wellenform zum nachfolgenden VCF gelangt. Das Ausgangssignal des VCO leitet der Synthesizer wiederum zum VCA weiter. Dessen Signal gelangt zur Kopfhörerbuchse.
Es ist natürlich müßig, etliche Ein- und Ausgänge des Patch-Bay im Detail zu beschreiben. Daher sollen hier nur ein paar Beispiele adressiert werden:
Auf der Mavis-Webseite [4] findet sich ein Mavis-Handbuch, ein Manual über Patches und weitere exemplarische Patchschablonen sowie ein leeres Patchsheet zum Ausdrucken. Darüber hinaus haben Anwender auf dem Internet eigene Patches hochgeladen, ebenso wie es dort YouTube-Videos über Patches, diverse Meinungen zu Mavis, sowie empfohlene Workflows gibt. Besonders interessant ist übrigens die Webseite patchstorage [5], weil sie zahlreiche Patches für Mavis zum Herunterladen anbietet.
Moogs neuester Synthesizer Mavis kann mit seinem semimodularen Ansatz überzeugen, da er viele Möglichkeiten eröffnet. Er eignet sich sowohl für Anfänger, die das Synthesizer-Feeling erleben wollen, ohne von Dutzenden Funktionen erschlagen zu werden, als auch für Profis, die Mavis als zusätzliche Komponente in ihrer Studiokonfiguration vorsehen. Für alle, die schon einen Moog-Synthesizer des Typs Mother-32, DFAM oder Subharmonicon ihr eigen nennen, dürfte Mavis jedenfalls eine gute Ergänzung darstellen.
Mit seinem minimalistischen Ansatz erleichtert Mavis den Einstieg in die Welt der Synthesizer, bietet aber immer noch ein schier unendliches Spektrum an Patchmöglichkeiten. Der Preis ist zwar aus Moog-Sicht nachvollziehbar, aber aus meiner Sicht hätte ein Verkaufspreis von unter 300 Euro mehr Sinn gemacht. Viele potenzielle Käufer dürften nicht so tief in die Tasche greifen wollen. Trotzdem ist Mavis aus meiner subjektiven Sicht ein guter Kauf, da der Synthesizer volle Moog-Funktionalität besitzt, schon jetzt eine hilfreiche Community bietet, und East-Coast-Synthese mit West-Coast-Synthese verbindet. Wenn ich zwei Wünsche frei hätte, würde ich mich über einen integrierten Sequencer und auch über die Unterstützung von MIDI freuen.
Wer sich noch nicht sicher ist und trotzdem preisgünstig mit (semi-)modularen Synthesizern von Moog experimentieren möchte, sei auf die diversen Apps und Plugins verwiesen, die virtuelle Moog-Synthesizer wie das Moog Modell 15 virtualisieren. Zusätzlich bietet Behringer Hardware-Synthesizer zu günstigen Preisen an, die ihren Moog-Pendants klanglich und funktional sehr nahe kommen. Ein Beispiel ist das Behringer Model D zu einem Straßenpreis von 298 Euro. Diese Lösungen bieten aber kein Wavefolding.
Es gibt also immer verschiedene Wege nach Moog.
URL dieses Artikels:https://www.heise.de/-7160932
Links in diesem Artikel:[1] https://www.heise.de/blog/Fred-s-Lab-ZeKit-Synthesizer-mit-DiY-Feeling-7154810.html[2] https://www.bonedo.de/artikel/die-besten-midi-to-cv-interfaces/[3] https://www.heise.de/blog/Frisch-aus-der-Werkstatt-Ein-Selbstbau-Synthesizer-von-Moog-6664968.html[4] https://www.moogmusic.com/exploremavis[5] https://patchstorage.com/moog-mavis/[6] https://www.moogmusic.com/exploremavis[7] https://back.moogmusic.com/sites/default/files/2022-06/MAVIS_MANUAL_V2_06.27.2022.pdf[8] https://back.moogmusic.com/sites/default/files/2022-06/Mavis-Patching-With-Intention_Web.pdf[9] https://back.moogmusic.com/sites/default/files/2022-06/Mavis_Exploration_Patchbook_Web.pdf[10] https://back.moogmusic.com/sites/default/files/2022-06/Mavis_Patchbook_Lisa_Bella_Donna.pdf[11] https://back.moogmusic.com/sites/default/files/2022-06/Mavis_Blank_Template.pdf[12] mailto:rme@ix.de
Copyright © 2022 Heise Medien
(c) Fred’s Lab, ZeKit
Dieser Beitrag über Synthesizer behandelt das Selbstbaukit ZeKit. Zur Sprache kommen Montage und Nutzung des vierstimmigen paraphonischen Hybrid-Synthesizers.
Die Kreationen von Fred’s Lab zeichnen sich durch kreative Namen aus, etwa Töörö, Buzzy! oder eben ZeKit. Die Hardware kommt nicht im sonst typischen Schwarz- oder Weiss-Gewand zu den Nutzern, sondern im erfrischenden Bunt. Dadurch hebt sich Fred’s Lab angenehm hervor, ohne dass die Produkte verspielt wirken. Hinter dem ungewöhnlichen Firmennamen verbirgt sich übrigens Frédéric Meslin, ein Zeitgenosse aus französischer Produktion, der in Deutschland lebt und seit 2016 kleine innovative Synthesizer erfindet und vertreibt. Fred war bis Firmengründung bei bekannten Unternehmen wie Arturia (MiniBrute-Synthesizer) und Waldorf (NW1-Synthesizer) in der Hardware-/ Softwarentwicklung beschäftigt. Diese Erfahrung macht sich bei seinen Geräten bezahlt.
Philosophie von Freds Unternehmens ist die Bereitstellung portabler Synthesizer, die ihre Besitzer beispielsweise über eine DAW (Digital Audio Workstation) á la Logix Pro X , Cubase, Ableton Live und Bitwig ansteuern. Alternativ können Musiker dafür auch jedes Midi-Gerät, egal ob Hardwaresequenzer, Midi-Keyboard oder Hardware-DAW nutzen.
Interessant ist für den vorliegenden Blog insbesondere der Bausatz ZeKit, da Fred sowohl dessen Software als auch dessen Hardware über eine Open-Source-Lizenz zur Verfügung stellt. Maker können dementsprechend die Firmware anpassen beziehungsweise erweitern, und natürlich ebenso die Hardware nach ihren Vorstellungen modifizieren. Grund genug also, das ZeKit hier zu adressieren.
Auch wenn das ZeKit bei einigen Musikshops wegen der verwendeten digitalen Wellenerzeugung als digitaler Synthesizer firmiert, ist es genau genommen ein Hybrid, da andere Teile wie die Envelop-Generatoren, der Verstärker VCA (Voltage-Controlled Amplifier), oder der Filter VCF (= Voltage-Controlled Filter) analog vorliegen.
Der Synthesizer ist im Prinzip polyphon, das heißt bis zu vier Stimmen können gleichzeitig erklingen. Da sich aber alle Stimmen Komponenten wie den VCF und die Hüllkurvengenerator teilen, gilt ZeKit als paraphoner Synthesizer. Die Synthese der digital erzeugten Wellenformen erfolgt als Kombination von Sägezahnkurven. Generieren lassen sich in diesem Zusammenhang je 8 einstellbare monophone & paraphone Wellenformen. ZeKit integriert einen Sequenzer mit 96 Steps und 4 Noten per Step. Benutzer können zudem bis zu 16 Patterns definieren.
Wer einen Vorgeschmack auf die Möglichkeiten des ZeKit bekommen will, besucht am besten die Produktseite [5], auf der sich einige Klangbeispiele finden.
Als Schnittstellen offeriert ZeKit einen Midi-Eingang, der beispielsweise den Anschluss eines Midi-Keyboards oder eines Sequenzers erlaubt. Andere Tonquellen sind über einen Audioeingang anschließbar. An einen Audioausgang können Anwender Kopfhörer, Lautsprecher oder weiteres Equipment verbinden, um das vom ZeKit generierte Audiosignal zu verarbeiten. Ein Clock-Eingang erlaubt die Synchronisation des ZeKit mit anderen Geräten.
Herz des ZeKit ist ein 16-bit-Prozessor der Microchip-Produktfamilie PIC24F. Der Mikrocontroller läuft mit 16 MHz. Die PIC24F-Produktfamilie implementiert diverse Anschlussmöglichkeiten wie USB, SPI, UART, I2C, PWMs (Pulse-Width Modulators) und Timer, zudem ADCs (Analog-Digital Converter) und DACs (Digital-Analog Converter). Über I2S lassen sich zwischen dem Mikrocontroller und anderen Komponenten Audiodaten übertragen. Das F in PIC24F steht dafür, dass die Mikrocontroller dieser Familie Flashspeicher integrieren. Programmierbar sind die PIC-Mikrocontroller entweder mit C oder Basic. Microchip stellt für die Programmierung eine integrierte Umgebung namens MPLAB X [6] für Windows, macOS und Linux bereit, die auf einer Java-Runtime beruht.
Interessierte können den ZeKit-Synthesizer zwar auch fertig montiert für 189 Euro erwerben, aber mehr Spaß und Einblicke in das Innenleben eines Synthesizers bietet das Selbstbaukit für preisgünstige 139 Euro. Letzteres lag mir – Fred sei dank – zum Test vor. Zur Stromversorgung benötigt der ZeKit-Anwender noch ein Netzteil, das 5 bis 9 Volt Versorgungsspannung liefert.
Zwar ist die Montage des ZeKit mit moderater Lötarbeit verbunden, aber das ist selbst für Maker machbar, die keine Lötvirtuosen sind, da sich alle SMD-Komponenten bereits vormontiert auf der Platine des Synthesizers befinden. Zu verlöten sind lediglich passive Teile mit Through-Hole-Bauform wie Kondensatoren, Potentiometer, IC-Sockel, oder LEDs, was aber in dem beiliegenden Handbuch gut beschrieben ist. Insbesondere bei den wenigen Bauteilen, bei denen es auf die richtige Polarität ankommt – beim ZeKit sind das LEDs und Schalter mit LEDs – sollten Maker etwas mehr Sorgfalt walten lassen. Der Rest ist fast ein Kinderspiel. Im Handbuch gibt es sogar Passagen für weniger elektronikaffine Zeitgenossen, um das richtige Löten zu illustrieren. Unerfahrene sollten rund 1,5 bis 2,5 Stunden Zeitaufwand einkalkulieren, Erfahrene etwa eine Stunde.
Nun ist es an der Zeit, die Lötstation anzufeuern.
Gehen wir die einzelnen Schritte des Zusammenbaus durch, um aus den Bauteilen einen betriebsbereiten Synthesizer zu schaffen.
Zuvor aber ein paar Hinweise:
Hinweis 1: Klebeband ist hilfreich, um Teile auf dem Board in Position zu halten, während wir deren Beinchen auf die Platine löten.
Hinweis 2: Nach dem Löten sollten Maker die überstehenden Beinchen der Komponenten mit einem kleinen Seiten- oder besser mit einem Mittenschneider entfernen.
Hinweis 3: Wie immer empfiehlt sich das Anbringen eines antielektrostatischen Bandes ans Handgelenk. Sicher ist sicher.
Im ersten Schritt bringen wir die Sockel für die ICs auf die Hauptplatine. Das Board symbolisiert den Platz für IC-Sockel mit einer an der Spitze halbkreisförmigen Aussparung. Da die IC-Sockel und die ICs ebenfalls eine solche Aussparung besitzen, kann es nur bei grober Unachtsamkeit zu Fehlern kommen.
Schritt 2 besteht darin, die blauen Filmkondensatoren (C15, C19, C21) auf das Board zu löten. Dieser Typ von Kondensator ist nicht polarisiert und kann daher in jeder Orientierung eingebaut werden. Allerdings sind die Bauelemente hitzeempfindlich. Wir sollten die Bausteine deshalb nicht länger als 5 Sekunden der Hitze des Lötkolbens aussetzen.
Schritt 3 beinhaltet das Löten der Schalter mit roter LED (SW5, SW6, SW7, SW8, SW2, SW3, SW4). Diese Schalter arbeiten in ihrer Funktion als Schalter natürlich in jeder Orientierung. Allerdings gilt das nicht für die eingebaute rote LED. Zum Glück ist auf dem Board ein Loch mit der Markierung “R” angebracht, ebenso wie eines der sechs Schalterbeinchen eine rote Markierung besitzt. Aus diesen Markierungen geht die Positionierung der Schalter eindeutig hervor.
Schritt 4: Die Kippschalter, die zwei stabile Einrastpositionen besitzen, lassen sich nun in beliebiger Orientierung einbauen.
Im Schritt 5 erfolgt das Löten der beiden Arten bereitgestellter Potentiometer. Die einen besitzen auf der Unterseite die Kennung “b103”, die anderen “b104”. Diese Zahlen definieren den Widerstandswert. Zum Beispiel bedeutet die Zahl 104 einen Widerstand von 10 * 10^4 KOhm = 100 KOhm, während 103 für 10 * 10^3 KOhm = 10 KOhm steht. Die Positionen dieser Widerstände sind eindeutig auf dem Board markiert.
Schlussendlich löten wir im Schritt 6 die rote LED (fungiert als Power-Anzeige) ein. Das längere Beinchen ist der Pluspol, das kürzere der Erdungspol. Das längere Beinchen muss näher am Berührungsschalter SW2 positioniert sein als das kürzere.
Im achten Schritt löten wir alle verbleibenden Bauteile auf der Boardrückseite ein, also den blauen Trimmer, die Verbindungsstecker für Audio-In, Audio-Out, Netzteil, fünfpoligen Midi-Eingang sowie die schwarze Ein-/Austaste.
Im neunten Schritt stecken wir die ICs vorsichtig in die vorgesehenen Sockel. Auch hier gilt: Zur richtigen IC-Orientierung halbkreisförmige Aussparung am IC und Sockel beachten.
Im zehnten Schritt falten wir die beiliegenden Gehäuseteile zu einem Quader und montieren das Board mit vier Abstandhaltern ins Gehäuse, was nach kurzer Zeit erledigt ist. Das gilt auch für das Aufsetzen der Drehknöpfe auf die Potentiometer. Das Alublech lässt sich mit den Händen falten oder mit einer Zange und einem kleinen Schutztuch, um Kratzer zu vermeiden.
Schritt 11 inkludiert jetzt nur noch das Anbringen der klebbaren Kunststofffüßchen auf der Geräteunterseite. Damit ist der Zusammenbau beendet.
Die Inbetriebnahme des fertiggestellten Synthesizers erfolgt am besten über ein Gleichspannungsnetzteil mit 5V bis 9V Versorgungsspannung und einer Stromstärke von 60 bis 500 mA, zum Beispiel 100 mA. Die Steckergröße des Netzadapters beträgt 2,1 mm. Eine Eingangsspannung von mindestens 5V bis maximal 9V wandelt das Board in intern benötigte Spannungen von +3,3V und -2V um. Wer auf Nummer sicher gehen will, nutzt zum ersten Test ein Labornetzgerät, um genaue Versorgungswerte einzustellen. Alternativ wäre eine weitere Option, ein geregeltes Netzteil mit Stromstärken-Limitierung zu nutzen. Ein funktionstüchtiges ZeKit ist daran zu erkennen, dass beim Einschalten die Power-LED leuchtet, die Knöpfe mit roter LED beim Drücken blinken, der Regulatorchip U2 auf der linken oberen Vorderseite des Boards kühl bleibt, sich beim Drücken des Play-Knopfes SW8 dessen Funktion aktiviert, worauf die LED des Schalters SW6 im Gleichtakt blinken sollte. Funktioniert das ZeKit wie vorgesehen, kann der eigentliche musikalische Spaß beginnen.
Nur ein Hindernis steht noch im Weg: Analoge Elektronikkomponenten besitzen Fertigungstoleranzen. So misst beispielsweise ein 10 kOhm Widerstand in der Regel nicht 10 kOhm sondern hat einen um wenige Prozent abweichenden Wert. Das mag für eine einzelne Komponente noch unkritisch erscheinen, kann sich aber bei mehreren Komponenten zu größeren Differenzen aufschaukeln, was sich speziell beim VCF (Voltage-Controlled Filter) auswirkt. Genau dafür gibt es den blauen Trimmer-Poti, der sich über einen passenden Schraubenzieher justieren lässt. Die Details der VCF-Kalibrierung würden diesen Beitrag sprengen. Deshalb sei an dieser Stelle auf die Anleitung hingewiesen.
Die Firmware des ZeKit liegt auf einem Git-Repository [7] als Open Source bereit, lässt sich also nach eigenem Gusto erweitern oder ändern. Weitere Resourcen, Informationen und Sounddemos finden sich auf der ZeKit-Webseite [8].
Musik kreieren auf dem ZeKit können Nutzer zum Beispiel über den Anschluss an eine DAW wie Ableton Live. Zum Experimentieren empfiehlt sich aber auch ein externes Midi-Keyboard (zum Beispiel Arturia KeyStep).
Das Sounddesign mit dem ZeKit beginnt mit der Auswahl der gewünschten Wellenformen. Insgesamt stehen je acht monophone und paraphone Wellenformen zur Verfügung.
Dem schließt sich ein analoger Filter an, der die Wahl zwischen einem Lowpass-Filter und einem Bandpass-Filter lässt und eine Flankensteilheit von 12db besitzt. Die Frequenz, ab der ein Abschneiden des Signals erfolgen soll, ist mit dem CUTOFF-Regler einstellbar.
Mittels eines Kippschalters kann der Sounddesigner bezüglich der Resonanz zwischen Chill und Acid wählen. Während Chill eher für sanfte Gemüter gedacht ist, wirkt Acid etwas harscher.
Danach folgt im Signalpfad ein spannungsgesteuerter analoger Verstärker (VCA).
Um den Filter zu modulieren, existiert eine einstellbare Attack-Delay-Hüllkurve. Zur Regelung des Verstärkers dient eine Release-Hüllkurve. Der Hüllkurvengenerator ist loopfähig (siehe Alternativfunktion der REC-Taste), wodurch sich eine weitere niederfrequente Modulationsquelle ergibt, wenn der Musiker ATTACK, RELEASE, ACCENT auf kleine Werte setzt.
Ein spezieller Kippschalter bietet eine Umschaltmöglichkeit zwischen VCF und Mix, dessen Einstellung bestimmt, ob das ZeKit ein extern anliegendes Audiosignal zum Mixer oder zum Filter des ZeKit umleiten soll.
Zum Aufmotzen des Sounds eines ZeKits kann das erzeugte Audiosignal zum Beispiel zu einem Effektmodul geleitet werden, das den Klang um Effekte wie Reverb ergänzt, zumal ZeKit stubenrein ist und keine eigenen Effekte anbietet.
Insofern schreit das ZeKit geradezu danach, eine Liaison mit anderen Geräten einzugehen.
Wer übrigens nach dem Lautstärkeregler sucht: Mittels des LEVEL-Potis ist die Masterlautstärke des ZeKit regulierbar.
Es gibt noch viele weitere wichtige Funktionen. Hier ein Ausschnitt.
ZeKit ist in gewisser Weise ein Überraschungsei für Maker und Musiker mit Elektronikaffinität. Sowohl der Zusammenbau als auch das Spielen des Synthesizers machen Spaß. Zusätzlich erhalten Maker einen Einblick in die Funktionsweise von Synthesizern. Das gilt umso mehr für diejenigen, die einen genaueren Blick auf Firmware und Hardware wagen. Im Anhang des Montagemanuals hat Fred die genauen Schaltpläne des ZeKit mit Erläuterungen dokumentiert. Ebenso befindet sich dort eine detaillierte Stückliste. Gerade Maker, die schon immer einen Synthesizer kreieren wollten, erhalten beim ZeKit wichtige Anregungen für ihre eigenen Projekte.
Nach dem Zusammenbau kann man das ZeKit so nutzen, wie es ist, oder eigene Mods vornehmen, etwa einen einfacheren Hardware-Mod für zusätzlichen Batteriebetrieb oder einen aufwendigen Hardware+Software-Mod, um ein kleines Display für die Visualisierung hinzuzufügen. Es gibt folglich viele Möglichkeiten, dem ZeKit eine persönliche Note zu verleihen. Der zu anderen Selbstbaukits relativ günstige Preis verursacht kein tiefes Loch im Geldbeutel und offeriert ein exzellentes Preis-Leistungs-Verhältnis.
Noch ist die Miniserie über Selbstbausynthesizer nicht abgeschlossen. In der nächsten Folge soll es um Moog’s jüngsten semimodularen Synthesizer Mavis gehen.
URL dieses Artikels:https://www.heise.de/-7154810
Links in diesem Artikel:[1] https://www.heise.de/blog/Frisch-aus-der-Werkstatt-Ein-Selbstbau-Synthesizer-von-Moog-6664968.html[2] https://www.heise.de/blog/Frisch-aus-der-Werkstatt-Ein-Selbstbau-Synthesizer-von-Moog-6664968.html[3] https://youtu.be/9wJXOWLeEqM[4] https://reverb.com/news/the-basics-of-east-coast-and-west-coast-synthesis[5] https://fredslab.net/en/zekit-module.php[6] https://www.microchip.com/en-us/tools-resources/develop/mplab-x-ide[7] https://github.com/Marzac/zekit[8] https://fredslab.net/en/zekit-module.php[9] mailto:michael.stal@gmail.com
Copyright © 2022 Heise Medien
(Bild: Andrey Suslov/Shutterstock.com)
Über die Direct Sockets API könnten Web-Apps in Zukunft UDP- und TCP-Ports öffnen und sich direkt mit Geräten oder Diensten verbinden, die kein HTTP sprechen.
Project Fugu, eine Initiative mehrerer Browserhersteller innerhalb des Chromium-Projekts, hat über die vergangenen Jahre viele Schnittstellen ins Web gebracht, die Webanwendungen Zugriff auf plattformspezifische Fähigkeiten gegeben haben und im Web ursprünglich nicht vorhanden waren. Der Fokus des Projektes, das auf diesem Blog schon mehrfach diskutiert wurde [1], lag zuletzt auf Produktivitätsanwendungen wie Bildbearbeitungsprogrammen oder Office-Apps.
Dank der Fugu-Schnittstellen konnten Ende 2021 etwa gleich zwei hochkarätige Anwendungen in einer Webfassung herausgegeben werden: Adobe stellte eine webbasierte Variante von Photoshop [2] zur Bearbeitung von Clouddokumenten bereit (Creative-Cloud-Abonnement erforderlich) und Microsoft packte seinen Codeeditor Visual Studio Code direkt ins Web [3].
Doch dabei soll es nicht bleiben. Im Rahmen der Isolated Web Apps [4], das sind Apps, die exklusiv über den Play Store oder per Enterprise Configuration im Unternehmenskontext zur Verfügung gestellt werden und mit Web-Technologien gebaut werden, kommt nun die nächste Kategorie von Anwendungen ins Visier: Apps, die über HTTP, WebSockets und WebRTC hinaus mit Netzwerkdiensten kommunizieren wollen, also etwa FTP-, SSH-, Remote-Desktop- oder E-Mail-Clients, die direkt via POP3 oder SMTP mit dem Server sprechen möchten. Ebenso denkbar sind Netzwerkspiele oder Steuersoftware für (Intranet-)Geräte, die über andere als die üblichen Ports und Protokolle kommunizieren.
Hierzu befindet sich gerade die Direct Sockets API in der frühen Phase der Spezifikation. Das ganze geschieht entsprechend der üblichen Prozesse innerhalb der Web Incubator Community Group [5] (WICG) des W3C. Dort können neue Schnittstellen erprobt und mit Entwicklern und anderen Browser-Herstellern diskutiert werden.
Die von dieser Gruppe herausgegebenen Dokumente sind keine offiziellen Webstandards, können aber später zur passenden Arbeitsgruppe übertragen und dort dann zur W3C-Recommendation werden – Voraussetzung dafür ist die Unterstützung der Schnittstelle durch eine zweite, unabhängige Browser-Engine. Es handelt sich dabei um den zweiten Anlauf zur Implementierung einer solchen Schnittstelle, nachdem die TCP and UDP Socket API [6] im Jahr 2015 nicht zu Ende geführt wurde.
Die Direct Sockets API wird im Explainer-Dokument bei der WICG [7] grob vorgestellt, ein inoffizieller Spezifikationsentwurf [8] wird aktuell erarbeitet. Die Schnittstelle soll es ermöglichen, Client-Ports zu anderen Servern zu öffnen; Server-Ports sind dabei aktuell kein Teil der Spezifikation, der Browser wird also (noch) nicht selbst zum Server. Die Direct Sockets API würde dem globalen Navigator-Objekt zwei Methoden hinzufügen: openTCPSocket(), um ein neues TCP-Clientsocket zu öffnen, und openUDPSocket() zum Öffnen eines UDP-Clientsockets. Zum Aufbau einer SMTP-Verbindung mit einem Mailserver könnte eine Webanwendung etwa folgenden Code nutzen:
if ('openTCPSocket' in navigator) {
const tcpSocket = await navigator.openTCPSocket({
remoteAddress: 'mail.gmx.net',
remotePort: 587,
});
// read/write on socket
}Die jeweiligen Methoden geben dann ein Promise zurück, das mit einem TCP- oder UDP-Socket-Objekt resolved. Kann das Socket nicht geöffnet werden, wird das Promise rejected. Auf dem Socket-Objekt befinden sich die Eigenschaften readable und writable, zwei Streams zum Lesen bzw. Schreiben von Daten. Die Methode close() auf dem Socketobjekt schließt das geöffnete Socket wieder.
Die Schnittstelle befindet sich aktuell in einer frühen Phase der Entwicklung. In Chromium-basierten Browsern muss unter about://flags die Origin der Web-App eingetragen werden, um die Direct Sockets API für diese zu aktivieren. Das funktioniert schon jetzt mindestens unter Linux. Aktuell wird in diesem Fall ein dauerhafter Warnhinweis angezeigt.
Mozilla lehnt die Implementierung der Schnittstelle ab [9], von Apple gibt es kein offizielles Statement. Die Direct Sockets API würde einer weiteren Klasse von Anwendungen den Weg ins Web ebnen und wäre für alle interessant, die eine plattformübergreifende, direkt im Browser lauffähige Software schreiben wollen, um mit Diensten oder Geräten zu sprechen, die kein HTTP, WebSockets oder WebRTC implementieren. Der weitere Verlauf der Entwicklung bleibt also spannend, bei neuen Ereignissen informieren wir wieder hier auf dem ÜberKreuz-Blog.
[Update 7.7. 14:00]: Die Direct Sockets API wird nicht, wie zuvor berichtet, generell verfügbar gemacht, sondern nur für Isolated Web Apps. Die Schnittstelle lässt sich mindestens unter Linux schon ausprobieren
URL dieses Artikels:https://www.heise.de/-7156224
Links in diesem Artikel:[1] https://www.heise.de/blog/Fugu-Die-Macht-des-Kugelfisches-4255636.html[2] https://www.heise.de/blog/Analyse-Photoshop-jetzt-als-Webanwendung-verfuegbar-6229321.html[3] https://www.vscode.dev[4] https://github.com/reillyeon/isolated-web-apps/blob/main/README.md[5] https://wicg.io/[6] https://www.w3.org/TR/tcp-udp-sockets/[7] https://github.com/WICG/direct-sockets/blob/main/docs/explainer.md[8] https://wicg.github.io/direct-sockets/[9] https://github.com/mozilla/standards-positions/issues/431[10] mailto:rme@ix.de
Copyright © 2022 Heise Medien
(Bild: akedesign/Shutterstock.com)
Das W3C, bislang von mehreren Universitäten betrieben, wird eine eigenständige Organisation. W3C-CEO Dr. Jeff Jaffe spricht über Gründe und Auswirkungen.
Das World Wide Web Consortium [1] (W3C) wird zum 1. Januar 2023 eine eigenständige, gemeinnützige Non-Profit-Organisation [2]. Zuvor wurde das Konsortium, dem sich derzeit 463 Mitgliedsorganisationen aus aller Welt angeschlossen haben, von unterschiedlichen Universitäten und Forschungseinrichtungen als Gastgeber getragen ("Hosted Model"). Christian Liebel sprach mit Dr. Jeff Jaffe, CEO des W3C, über Gründe und Auswirkungen dieses Umbaus.
Christian Liebel: Das W3C setzte traditionell auf das Hosted Model, die Organisation wurde von mehreren Universitäten und Forschungseinrichtungen gemeinsam betrieben. Wie kam es dazu?
Dr. Jeff Jaffe: Nachdem das Web 1991 für die Öffentlichkeit freigegeben wurde, verbreitete sich die Webtechnologie sehr schnell. 1994 traten Vertreter des Massachusetts Institute of Technology (MIT) an Tim Berners-Lee heran, um das World Wide Web Consortium zu gründen, da sie Erfahrung mit Technologiekonsortien hatten (siehe die Pressemitteilung des MIT vom Oktober 1994 [3]). Tim erkannte jedoch von Anfang an, dass das W3C global aufgestellt sein müsse.
Innerhalb weniger Jahre schlossen das MIT, Keio in Japan und Inria (später übertragen auf das ERCIM, ein europäisches Technologiekonsortium) Vereinbarungen, um das W3C gemeinsam und auf Augenhöhe zu betreiben. Diese Hosting-Vereinbarungen bilden das Fundament, auf dem das W3C heute aufsetzt. Im Jahr 2013 kam die Beihang-Universität in China als weiterer Host hinzu. Diese Verwaltungspartnerschaft, das sogenannte Hosted Model, ermöglicht die Verwaltung der W3C-Mitglieder und die Beschäftigung von W3C-Mitarbeitern weltweit, die unter der Leitung der W3C-Geschäftsführung arbeiten.
Nach 28 Jahren soll das W3C nun zum 1. Januar 2023 eine eigenständige Legal Entity, also eine unabhängige juristische Person werden. Warum ist dieser Schritt notwendig?
Jaffe: Neben verschiedenen weiteren Gesichtspunkten gibt es zwei Hauptgründe, die die Einführung einer unabhängigen Legal Entity erforderlich machen:
Zum einen die Notwendigkeit, unsere Mitglieder in die formale Leitung einzubinden. Das soll über ein Board of Directors geschehen, um eine klarere Berichterstattung, Verantwortlichkeit, größere Diversität, bessere strategische Ausrichtung und globale Koordination zu erreichen. Von Beginn an war das W3C eine mitgliedergetriebene Organisation, bei der die teilnehmenden Mitglieder ihre Patente gebührenfrei zur Verfügung stellen und sich gemeinsam um den Erhalt und die Weiterentwicklung des Web kümmern. Mit den Vertretern unserer Hosts und unseren internen Führungsgruppen, von denen einige von W3C-Mitgliedern in beratender Funktion gewählt wurden, verfügen wir über erstaunliche Talente in der Leitung von technischen und Standardisierungsprozessen. Wir wollen und müssen noch weiter gehen, mit einem Gremium, das aus CEOs und CTOs von Unternehmen besteht – und aus Führern der Zivilgesellschaft.
Weiterhin ist der Bedarf nach neuen Webfunktionen über die Jahre gestiegen und die drängenden Probleme des Web sind stärker hervorgetreten. Dies hat sich in den letzten Jahren unter dem Druck, der von der Corona-Pandemie ausgeht, noch verschärft. Um diese Herausforderungen zu bewältigen und den Anforderungen im richtigen Tempo gerecht zu werden, muss das Web-Konsortium auf eine rasche Entwicklung und Kompetenzerwerb in neuen Bereichen setzen, seien es Medien, Web-Barrierefreiheit, Datenschutz, Sicherheit, Nachhaltigkeit, Fehlinformationen und so weiter. Die Fachkenntnisse, die wir von unseren Mitarbeitern benötigen, ändern sich ständig, und die Einstellungsprozesse in den akademischen Host-Einrichtungen bieten hierfür zu wenig Flexibilität.
Welche Auswirkungen wird die Umstrukturierung auf das Konsortium, die Entwickler und das World Wide Web haben?
Jaffe: Wir erwarten keine Veränderungen hinsichtlich unserer Vorgehensweisen im Umgang mit Entwicklern und der breiteren Web-Community. In der üblichen Interaktion wird es keine unmittelbaren Änderungen geben. Wie eben schon gesagt, gehen wir davon aus, dass uns die Umstrukturierung ermöglicht, das Tempo zur Bewältigung der wachsenden Anforderungen im Web zu erhöhen – sowohl für funktionale Verbesserungen, aber auch um gesellschaftliche Anliegen zu adressieren.
Innerhalb des W3C wird schon seit einiger Zeit über eine Zukunft des W3C ohne Direktor ("Director-Free") diskutiert, wenn der derzeitige Direktor Tim Berners-Lee zurücktritt. Adressiert die Umwandlung in eine Legal Entity diese Thematik?
Jaffe: Die Umwandlung in eine Legal Entity geht Hand in Hand mit den Director-Free-Diskussionen. Ein großer Teil des Erfolgs des W3C und des Web ist der Verdienst von Tim Berners-Lee. Das geht so weit, dass wir nie einen Aufsichtsrat hatten, sondern Tim es war, seine Vision und seine Kontakte, die uns mit den richtigen Stellen in Verbindung gebracht haben. Im Zuge der Director-Free-Diskussionen sollen die vielen Rollen des W3C-Direktors aufgeteilt werden, und manche dieser Rollen werden durch das Board of Directors unterstützt.
Zu guter Letzt: Welche Entwicklungen im World Wide Web finden Sie derzeit spannend?
Jaffe: Es freut mich, dass Sie das fragen, da es viele Möglichkeiten gibt, die Herausforderungen des bestehenden Web zu bewältigen und eine bessere Zukunft dafür zu schaffen. Wir nehmen das Web nicht als gegeben hin. Es kann mehr leisten. Es kann noch mehr sein. Wir haben das während der Pandemie gesehen, als die Welt plötzlich "virtuell" wurde und es die Webtechnologien waren, die die Durchführung vieler Aktivitäten weltweit ermöglichten.
Um den gesellschaftlichen Ansprüchen gerecht zu werden, wird es eine gemeinsame Anstrengung brauchen, um sicherzustellen, dass das Internet für Menschen auf der ganzen Welt zugänglicher und sicherer wird und als Motor für das Wachstum in wichtigen Bereichen von Wirtschaft und Gesellschaft dienen kann.
Wir müssen nicht nur die unzähligen Kerntechnologien des Web auf dem aktuellsten Stand halten, sondern auch unsere Bemühungen um die Technologien verstärken, die den Übergang zu mehr Virtualität ermöglichen, zum Beispiel Web Real Time Communications (WebRTC). Unsere 350 Community-Gruppen entwickeln unentwegt neue Technologien in verschienenen Bereichen wie Virtual Reality, dem Metaverse, der Interoperabilität von hybriden (nativen/webbasierten) Anwendungen sowie für ein dezentraleres Web. Wir arbeiten an Technologien, die auf die Bedürfnisse einer sich wandelnden Gesellschaft eingehen, einschließlich Fragen des Datenschutzes, der Werbung im Web, Smart Cities, sicherer Zahlungen und der Automatisierung.
In einer immer stärker global vernetzten Welt sorgen wir dafür, dass das Web für Zeichensätze und Verleger in der ganzen Welt funktioniert. Wir erwägen, am Thema "finanzielle Inklusion" zu arbeiten, um das Web für Menschen ohne Bankkonto besser nutzbar zu machen. Wir gehen auf branchenspezifische Bedürfnisse ein – wie die Tatsache zeigt, dass wir in diesem Jahr unseren dritten Emmy-Award in sieben Jahren gewonnen haben.
Schließlich unterstreichen die kulturellen, wirtschaftlichen und gesellschaftlichen Verschiebungen der letzten zwei Jahre die Wichtigkeit webbasierter Technologie und Dienste. Sie haben die Notwendigkeit allgemein akzeptierter technischer Spezifikationen, Leitlinien und Webstandards deutlich gemacht. Wir müssen anerkennen, dass das Web sowohl die schnelle Verbreitung wichtiger Informationen ermöglicht, aber leider zugleich auch Kanäle zur Verbreitung von Fehlinformationen schafft. Wir müssen verstehen, dass das Web einerseits der ultimative Beschleuniger von Wirtschaft und Handel ist, durch seine Allgegenwart aber zugleich auch missbräuchlich verwendet werden kann. All das zwingt uns zu anhaltender und erhöhter Wachsamkeit, um sicherzustellen, dass eine der größten Errungenschaften der Menschheit nicht denjenigen zum Opfer fällt, die seine enorme Macht für falsche Zwecke missbrauchen wollen.
Das Interview wurde schriftlich geführt und aus dem Englischen übersetzt.
URL dieses Artikels:https://www.heise.de/-7157916
Links in diesem Artikel:[1] https://www.w3.org/[2] https://www.heise.de/news/Webstandards-Das-W3C-baut-sich-um-7156498.html[3] https://news.mit.edu/1994/lcs-1019[4] mailto:rme@ix.de
Copyright © 2022 Heise Medien
(Bild: MichaelJayBerlin/Shutterstock.com)
Apple bringt Web Push auf Safari für macOS, iPadOS und iOS. Damit können Websites und PWAs jetzt auf allen relevanten Plattformen Pushnachrichten empfangen.
Progressive Web Apps [1] sind Anwendungen, die plattformübergreifend ausgeführt werden können: Einmal geschrieben laufen PWAs überall dort, wo ein halbwegs moderner Webbrowser zur Verfügung steht – unter anderem auf Android, iOS, Linux, macOS und Windows. Schon seit vielen Jahren können Webanwendungen auf dem Gerät des Anwenders installiert und offline ausgeführt werden. Mit den Apple-Mobilplattformen iOS und iPadOS können Websites und PWAs nun auf sämtlichen relevanten Mobil- und Desktoplattformen Pushnachrichten empfangen und anzeigen. Diese Funktion brauchen unter anderem Messenger, Nachrichten- oder Banking-Apps sowie soziale Netze.
Apple implementiert Web Push für Safari 16 auf macOS Ventura, das im Herbst 2022 erscheinen soll. Auf iOS und iPadOS folgt die Implementierung im Jahr 2023 [2]. Unter macOS können Anwender bereits seit langer Zeit mit Firefox, Edge oder Chrome Pushbenachrichtigungen erhalten. Aufgrund der fehlenden Browserenginewahl unter iOS und iPadOS war dies dort aber bislang nicht möglich. Apple wird in Safari dieselben Spezifikationen implementieren, die alle übrigen relevanten Browserhersteller schon seit einigen Jahren unterstützen:
Aufseiten des Frontends bedeutet dies, dass Websites und Webanwendungen einen Service Worker [9] implementieren müssen, um Pushbenachrichtigungen empfangen zu können. Für den Empfang von Pushnachrichten muss der Anwender erst einwilligen. Dazu wird eine Berechtigungsabfrage angezeigt, die nur im Rahmen einer Benutzerinteraktion wie einem Klick oder Tastendruck geöffnet werden darf. Wie bei allen anderen Apps auch können Anwender die Berechtigung in den Systemeinstellungen auch wieder zurückziehen. Das genaue Vorgehen ist im Video Meet Web Push for Safari [10] von der Entwicklerkonferenz WWDC 2022 zu sehen.
Der Apple Push Notification Service (APNs) wird wie die anderen Pushdienste Windows Push Notification Service, Firebase Cloud Messaging und Mozilla Push Service die Voluntary Application Server Identification [11] (VAPID, RFC 8292) unterstützen, mit der sich das Backend beim Pushdienst ausweisen kann. Auch das Backend muss lediglich ein Protokoll sprechen, um mit den verschiedenen Pushdiensten zu kommunizieren. Eine Registrierung beim Apple Developer Program ist nicht erforderlich. Wer Web Push bereits implementiert und sich an die Standards gehalten hat, muss vermutlich gar nichts ändern: Sobald Safari die Schnittstellen generell verfügbar macht, sollte es auch dort einfach funktionieren.
Weitere Details sind in der Apple Developer Documentation [12] nachzulesen. Mit der Verfügbarkeit von Pushbenachrichtigungen schließt sich für PWAs unter iOS und iPadOS nun endlich der Kreis: Schon 2018 [13] implementierte Apple den Service Worker sowie das Web Application Manifest in WebKit. Diese Spezifikationen bilden die Grundlage für Offlinefähigkeit und Installierbarkeit von Webanwendungen. Die Push API wird seit Chrome 42 (2015), Firefox 44 (2016) und Edge 17 (2018) unterstützt. Safari unterstützt unter macOS seit Version 7 ein proprietäres Pushprotokoll (Safari Push Notifications), das auch weiterhin funktionieren wird, aber eine Registrierung beim Apple Developer Program voraussetzt, sowie die Notifications API seit Version 6.
Mit Web Push und weiteren WebKit-Ankündigungen von der WWDC 2022 holt Apple im Web-Bereich zunehmend auf. Das PWA-Anwendungsmodell ist nun auch auf iOS und iPadOS abgerundet. Die Herausgeber Chromium-basierter Browser, die seit vielen Jahren Web Push unterstützen, sind jedoch längst in neue Gefilde aufgebrochen: Die im Rahmen von Project Fugu [14] entstandenen Webschnittstellen haben es etwa Adobe erlaubt, Photoshop in einer Webfassung herauszugeben [15]. Für Webentwickler bleibt zu hoffen, dass Apple auch hier nachlegen wird, um Webanwendungen auf dem Desktop mit weiteren spannenden Fähigkeiten auszustatten.
URL dieses Artikels:https://www.heise.de/-7134230
Links in diesem Artikel:[1] https://www.heise.de/blog/Progressive-Web-Apps-Teil-1-Das-Web-wird-nativ-er-3733624.html[2] https://webkit.org/blog/12945/meet-web-push/[3] https://www.thinktecture.com/pwa/push-api/[4] https://www.w3.org/TR/push-api/[5] https://www.thinktecture.com/pwa/push-notifications-api/[6] https://notifications.spec.whatwg.org/[7] https://www.thinktecture.com/pwa/push-api/[8] https://datatracker.ietf.org/doc/html/rfc8030[9] https://www.heise.de/blog/Progressive-Web-Apps-Teil-2-Die-Macht-des-Service-Workers-3740464.html[10] https://developer.apple.com/videos/play/wwdc2022/10098/[11] https://datatracker.ietf.org/doc/html/rfc8292[12] https://developer.apple.com/documentation/usernotifications/sending_web_push_notifications_in_safari_and_other_browsers[13] https://www.heise.de/blog/iOS-11-3-Willkommen-Progressive-Web-Apps-3960706.html[14] https://www.heise.de/blog/Fugu-Die-Macht-des-Kugelfisches-4255636.html[15] https://www.heise.de/blog/Analyse-Photoshop-jetzt-als-Webanwendung-verfuegbar-6229321.html[16] mailto:map@ix.de
Copyright © 2022 Heise Medien
(Bild: Rowan Morgan/Shutterstock.com)
Eigentlich sollte auf diesem Blog schon längst eine Serie zum Raspberry Pi Zero 2 W beginnen. Doch die Chip-Krise hat dies verhindert.
Eigentlich sollte auf diesem Blog schon längst eine Serie zum Raspberry Pi Zero 2 W beginnen. Doch die Chip-Krise hat dies verhindert, weil sich momentan kein Raspberry-Pi-Board erwerben lässt; zumindest nicht zu vernünftigen Preisen, also für 15 Euro statt für Wucherpreise um die 50 bis 100 Euro. Woran das liegt, möchte der vorliegende Artikel beleuchten.
Als wegen des Coronavirus Sars-CoV-2 die jetzige Wirtschaftskrise im Frühjahr 2020 begann, hoffte die Halbleiterindustrie gerade, sich von ihrer eigenen Wirtschaftsflaute zu erholen. Doch das Virus bereitete dieser Hoffnung schon bald ein jähes Ende. Kunden der Chipproduzenten stornierten übereifrig viele Aufträge, etwa die Automobilindustrie. Kurz darauf erholte sich die Nachfrage zwar wieder so stark, dass die Produktionskapazitäten nicht mithalten konnten, aber bis heute leiden viele Branchen und auch die Maker-Szene unter diesem Problem.
Der ein oder andere mag sich noch daran erinnern, dass durch das Corona-indizierte Homeoffice der Bedarf nach Consumer-Electronics (beispielsweise Webcams, Spielekonsolen, Streaming-Hardware) stark anstieg, was das Problem weiter verschärfte.
Es gab allerdings parallel zur Pandemie auch noch andere Ursachen.
Pleiten, Pech und Pannen: Im Winter 2021 fielen wegen eines dramatischen Kälteeinbruchs im texanischen Austin mehrere Fabs aus. Zusätzlich gab es in Japan einen Großbrand in einer für die Automobilindustrie wichtigen Halbleiterfabrik. Das alles in einer Zeit, in der wegen Corona ohnehin weniger Arbeitskräfte verfügbar waren. Zu schlechter-letzt kam Ende des Jahres 2021 wegen Komplett-Lockdowns die Halbleiterproduktion im chinesischen Xian zum Stopp.
Donald Trump: Aufgrund der US-Sanktionen und Handelsbeschränkungen gegenüber China durch Präsident Trump sollten chinesische Elektronikhersteller weniger Halbleiterprodukte aus den USA beziehen können. Das brachte die Firmen dazu, zum einen große Hamsterkäufe benötigter Komponenten zu tätigen und zum anderen, sich stärker auf eigene Füße zu stellen.
Bitcoin & Co: Da wäre auch noch der Run auf Kryptowährungen. Dieser Trend hat zu riesigen Serverfarmen geführt, die mit großem Aufwand Mining betreiben, also das energieintensive Erschaffen neuer Bitcoins. Durch den Anstieg der Energiepreise war das Mining schon bald nicht mehr rentabel, weshalb die professionellen Miner ihre Zelte in China aufschlugen, was der chinesische Staat aber sinnvollerweise schon bald unterbunden hat. Um Mining weiterhin rentabel zu gestalten, bedarf es vieler Rechenressourcen in Gestalt von Hochleistungsgrafikkarten. Das führte schon vor der Pandemie zu Engpässen und letztendlich dazu, dass die Preise für Grafikkarten alle Preisindizes nach oben durchbrachen.
Rohstoffe: Eine wichtige Ingredienz zur Fertigung von Halbleiterprodukten sind die dafür benötigten Ressourcen. Damit ist nicht etwa nur Silizium gemeint, das es sprichwörtlich wie Sand am Meer gibt. Für die Veredelung zu Reinstsilizium sind entsprechende Produktionskapazitäten notwendig, und für Elektronik sind seltene Erden und Metalle unabdingbar. Diese sind aber sehr beschränkt auf unserem Planeten verfügbar. Viele Länder und Firmen konkurrieren um sie. Bis zur Entwicklung geeigneter Ersatzstoffe kann es noch eine Weile dauern.
Erst für Ende 2022 haben einige Marktanalysten das Ende dieser Knappheit prognostiziert. Es würden demnach noch einige Monate vergehen, bis sich die Situation wieder einigermaßen beruhigen könnte. Der CEO von Intel, Pat Gelsinger, prophezeit sogar, dass das limitierte Angebot für Chips sich noch bis ins Jahr 2024 erstrecken dürfte. Keine guten Nachrichten also sowohl für die Industrie als auch für Konsumenten.
Was Maker jetzt tun können:
Die Chip-Krise dürfte uns noch einige Zeit begleiten. Speziell bei der Herstellung leistungsfähigerer und damit komplexerer Chips kommt die momentane Knappheit zum Tragen. Das führt beispielsweise bei Automotive-Anwendungen zu Problemen, aber auch bei Consumer-Produkten.
Zum Glück sind nicht alle Produktkategorien gleichermaßen davon betroffen. Im Microcontroller-Bereich schaut es noch besser aus. Trotzdem erscheint es ratsam, eigene Maker-Projekte bezüglich der Bill of Material rechtzeitig vorab zu planen und die eigene Logistik entsprechend anzupassen. Dieser Blog wird jedenfalls darauf Rücksicht nehmen, zumal es keinen Sinn ergibt, Projekte oder Boards vorzustellen, die der interessierte Maker nicht oder nur zu Wucherpreisen anschaffen kann.
URL dieses Artikels:https://www.heise.de/-7090001
Links in diesem Artikel:[1] https://youtube.com/playlist?list=PLjF7R1fz_OOX6EyjN3BYud1VHIqnDyvm_[2] https://blog.adafruit.com/category/the-great-search/[3] mailto:michael.stal@gmail.com
Copyright © 2022 Heise Medien
(Bild: Moog Music)
In der letzten Episode stand der Korg NTS-1 im Fokus. Das ist aber nicht der einzige verfügbare Synthesizer zum Zusammenbauen.
Vom Urvater aller Synthesizer Robert Moog gibt es einen relativ preisgünstigen Bausatz namens Werkstatt-01. Um diesen "Mini-Moog" soll es im vorliegenden Beitrag gehen.
Der analoge, einstimmige Moog-Synthesizer Werkstatt-01 kam zum ersten Mal im Jahre 2015 als DiY-Baukasten auf den Markt. Das Produkt umfasst einen kleinen Analogsynthesizer, der Technik von größeren Moog-Synthesizern wie Little Phatty, Sub 37 oder Mini Voyager enthält.
Das Kit ist das Ergebnis des jährlich stattfindenden Moogfests, bei dem Kunden, Künstler und Mitarbeiter die Moog-Produktfamilie zelebrieren. Dazu gehören unter anderem Vorträge und musikalische Sessions. Im Jahr 2014 konnten Interessenten unter Hilfestellung von Moog-Mitarbeitern den kleinen Synthesizer Werkstatt-01 zusammenbauen, sich daran auch nach der Konferenz erfreuen, und außerdem überall und jedermann von diesem Miniatursynthesizer erzählen, was schließlich in der Moog-Community zu einer Euphorie für den Werkstatt-01 führte. Überrascht von dieser positiven Resonanz, beschloss Moog, den DiY-Synthesizer 2015 als Baukasten für alle Interessierten herauszubringen.
Zu Beginn mussten Synthesizer- oder Elektronikfreaks noch über 300 Euro für das Kit hinblättern plus weitere 49 Euro für den optionalen CV-Expander.
2020 hat Moog den Synthesizer neu aufgelegt. Seitdem ist der Bausatz inklusive CV-Expander bereits für rund 215 Euro im Fachhandel erhältlich.
Das Zusammenschrauben beziehungsweise Stecken der Komponenten dauert nicht mehr als zehn Minuten. Alles, was Maker dafür benötigen, ist ein handelsüblicher Philips-Schraubenzieher. Die folgende Bilderstrecke illustriert, welche Schritte dabei nötig sind.
Vor dem Aufstecken des Frontpanels sollten angehende Moog-Anwender den Werkstatt-01 über das mitgelieferte Netzteil an den Strom anschließen. Leuchtet die rote LED bei LFO kontinuierlich oder blinkt sie je nach Einstellung des RATE-Drehknopfes, dann funktioniert das Gerät einwandfrei.
Wer auch den CV-Expander am Gerät befestigen möchte, verwendet auf der rechten Gehäuseseite die zwei beigelegten spitzen Schrauben statt der zwei schwarzen Gehäuseschrauben.
Im letzten Beitrag [1] kamen bereits die grundsätzlichen Elemente eines (analogen) Synthesizers zur Sprache. Trotzdem erfolgt an dieser Stelle nochmals ein Überblick, um auch die Terminologie von Moog kennenzulernen.
(Bild: (c) Moog Music)
Die erste und zentrale Komponente jedes Synthesizers ist ein Oszillator, der Wellen mit bis zu 16 kHz erzeugt. Dieser firmiert unter dem Begriff VCO (Voltage-Controlled Oscillator) und erlaubt beim Werkstatt-01 (Bedienbereich WAVE) entweder Sägezahnwellen (SAW) oder Rechteckswellen (PULSE). Deren Frequenz lässt sich mit dem FREQ-Poti und deren Intensität mit dem PWM-Poti vom Anwender beeinflussen. PWM steht dabei für Pulse-Width-Modulation und bestimmt, wie lange das Signal anliegen (Busy-Phase) und wie lange es nicht anliegen soll (Idle-Phase). Dadurch lässt sich die Intensität des Signals variieren.
Ein Envelope Generator (ENVELOPE beziehungsweise EG) bietet Einstellmöglichkeiten für jeden erzeugten Ton: A = Attack beschreibt die Zeit, bis zu der ein Ton seine maximale Amplitude (Lautstärke) erreicht, S = SUSTAIN regelt die Höhe des Tons (SUSTAIN = ON), und D = DECAY ist dafür verantwortlich, wie lange es am Schluss dauert, bis der Ton wieder die 0 erreicht.
Links unten auf dem Bedienpanel gibt es als weiteren Oszillator den LFO (Low-Frequency Generator), der im Gegensatz zum VCO einen niedrigfrequenten Oszillator darstellt. Als Wellenformen sind Rechteckswellen und Dreieckswellen möglich. Der Schaltpoti RATE stellt die Frequenz des LFO ein. Dessen Wellen sind für das menschliche Ohr nicht hörbar. Aber wozu braucht es dann überhaupt einen LFO?
Dazu betrachten wir zwischen VCO und LFO den VCO MOD, einen Modulator, der vorgegebene Wellen moduliert. Dessen Quelle (SOURCE) kann dabei entweder der LFO oder der Hüllkurvengenerator (EG) sein. Die Modulation arbeitet dabei als Ziel (DEST) entweder auf der Pulsweitenmodulation (PWM) oder der Frequenz (FREQ) des VCO. Die Intensität beziehungsweise Stärke der Modulation hängt von der Einstellung von AMOUNT ab. Obwohl also die vom LFO erzeugten Wellen für uns nicht hörbar sind, verändern sie angewandt auf den VCO den Sound hörbar. Der LFO spielt also eine wichtige Rolle bei dem Anpassen der Wellenform.
Im Abschnitt rechts neben dem VCO residiert der VCF (Voltage-Controlled Filter), eine Komponente, die aus der im VCO erzeugten Welle Frequenzen herausschneidet oder Resonanz hinzufügt. Mit dem Poti CUTOFF legt der Musiker fest, welche Frequenzen der Synthesizer herausfiltern soll. Damit wird auch der Moog-typische Ladder-Filter mit 24db Flankenanstieg realisiert, der Moog-Synthesizern ihren charakteristischen, "fetten" Ton verschafft. Bei der Resonanz füttert der Synthesizer die Ausgabe des Filters nochmals an den Eingang zurück, was zu einer harmonischen Verstärkung des Tons führt.
Rechts daneben befindet sich der VCA (Voltage-Controlled Amplifier), der entweder auf Basis der Hüllkurve dynamisch arbeitet (EG) oder statisch einen andauernden Ton erzeugt (ON).
Der Modulator namens VCF MOD nutzt als Quelle (SOURCE) entweder den Hüllkurvengenerator (EG) oder den LFO, moduliert dabei mit einer einstellbaren Stärke (AMOUNT) den Filter VCF und kann dabei auch die Polarität umkehren (POLARITY), was erlaubt, die CUTOFF-Frequenz weiter zu senken und damit einen "dunkleren" Sound zu erzeugen. Wenn etwa der VCF MOD den LFO als Quelle nutzt, verschiebt sich dynamisch und regelmäßig die CUTOFF-Frequenz des Filters VCF gemäß dem dazumodulierten LFOs, sodass als Ergebnis ein alarmartiger Klang entsteht.
Der Drehknopf GLIDE dient dazu, den Übergang zwischen zwei aufeinanderfolgenden Tastenanschlägen festzulegen, beantwortet also die Frage, ob sich Töne stakkatoartig, also abrupt abwechseln, oder stattdessen legatoartig sanft ineinander gleiten.
Rechts neben dem GLIDE-Knopf befinden sich übrigens die Tasten, um einzelne Noten einer Oktave zu spielen. Dieser Kompromiss ist der Größe des Synthesizers geschuldet, weil der kleine Synthesizer natürlich keinen Platz für eine echte Klaviatur besitzt. Die unteren acht Eingabeknöpfe entsprechen den weißen Tasten eines Klaviers im Umfang einer Oktave, die fünf oberen Knöpfe den schwarzen Klaviertasten.
In der Spielpraxis empfiehlt sich deshalb eine andere, bequemere Eingabemöglichkeit etwa ein Midi-Keyboard.
Wer sich noch weiter in die Materie Synthesizer einarbeiten möchte, findet grundlegende Infos über Synthesizer auch auf der Webseite von How-Stuff-Works [2].
Wie man mit einem Synthesizer Sounds erstellt, findet sich auf der Webseite bonedo.de [3].
Als Buch empfiehlt sich "Synthesizer. So funktioniert elektronische Klangerzeugung" von Florian Anwander [4].
Im Großen und Ganzen legt das Gerät also fest, wie seine verschiedenen Sektionen verschaltet sind. Hier ist oft vom Signalpfad die Rede. Durch Wechselschalter lassen sich zumindest alternative Signalpfade definieren, etwa bei der schalterbasierten Wahl zwischen unterschiedlichen Quellen und Zielen beim VCO MOD.
Der am Werkstatt-01 anmontierte CV-Expander – CV steht für Control Voltage – verändert diese Situation, in dem er mittels Patchkabel erlaubt, eigene Signalpfade zu definieren. Dadurch lässt sich der Werkstatt-01 vereinfacht als semimodularer Synthesizer betrachten. Nebenbei bemerkt: Ohne Integration des CV-Expanders lassen sich diese Verbindungen mittels eingesteckter Dupontkabel vorgeben.
Grundsätzlich gibt es folgende Ausgänge: VCO OUT, VCF OUT, LFO OUT, EG OUT, TRIG OUT, GATE OUT, KB CV OUT, CV OUT.
Und als Eingänge: VCF OUT IN, GATE IN, LFO IN, VCO EXP IN, VCO LIN IN, VCA IN, CV IN.
Wer also einen Eingang mit einem Ausgang verbindet, kann völlig neue Konfigurationen definieren. Der Synthesizer bietet für jeden Ausgang zwei Ports, für jeden Eingang einen Port. Damit lassen sich von jedem Ausgang per Kabel bis zu zwei Eingänge ansteuern.
Mögliche Beispielskonfiguration: Musiker verbinden per Dupontkabel oder Patchkabel den Ausgang des Envelope Generators mit dem Eingang des LFO. Dadurch beeinflusst das vom Envelope Generator ausgehende Spannungssignal die Frequenz des LFOs, was zu einem speziellen oszillierenden Ton mit sich vergrößernden Dämpfung führt.
Zunächst lohnt es sich, mit dem Synthesizer zu experimentieren. Einfach einen Kopfhörer in die 6,3 mm-Buchse anschließen und schon kann es losgehen.
Das Werkstatt-01 Exploration Patchbook [5] ist ein guter Ausgangspunkt, um zu lernen, wie sich verschiedene Soundeffekte mittels Patchkabel am CV-Expander erzielen lassen.
Auf der SoundCloud [6] finden sich unter der Suchzeichenkette “moog werkstatt” allerlei Beispiele für im Werkstatt-01 produzierte Sounds.
Den Anschluss externer Hardware, zum Beispiel des Midi-Keyboards Arturia KeyStep Pro an den Werkstatt-01 über den CV-Expander, zeigt exemplarisch ein Video des amerikanischen Händlers Sweetwater [7] ().
Beim Anschließen externer Hardware kann es freilich passieren, dass die Oktave auf dem Moog nicht mehr richtig kalibriert ist, was zum Beispiel zu einer Abweichung von einem Halbton führen kann, weil etwa aus dem oberen C ein C# wird. In diesem Fall muss der Anwender den Synthesizer kalibrieren. Dazu gibt es sowohl Anleitungen auf YouTube [8] als auch ein Manual [9]. Normalerweise deckt 1 V auf dem Synthesizer eine Oktave ab, aber durch Anschluss eines externen Geräts ist es möglich, dass sich hier etwas verschiebt, was sich durch den Trimpoti VCO EXP TRIM kalibrieren lässt. Der sitzt direkt auf dem eingebauten PCB-Board. Zum Kalbrieren reicht also das VCO-EXP-TRIM-Poti plus ein Instrumententuner, den es als Hardware oder als Smartphone-App gibt.
Den Synthesizer von Moog betrachtet der Artikel vor allem wegen seiner Ausbaufähigkeiten. So können Anwender unter anderem den LFO zu einem zweiten VCO umbauen, per Arduino oder einem anderen Microcontroller einen Arpeggiator konstruieren oder einen wabbelnden Klang erzeugen, eine Pitchbend-Möglichkeit oder einen Noise-Generator hinzufügen, und vieles mehr.
Dazu gibt es von Moog und anderen wertvolle Anregungen [10]. Ein ganzes Tutorial für Synthesizer Mods [11] findet sich zum Beispiel hier.
Für die Mods sind im wesentlichen einfache Bausteine wie Breadboards, Dupontkabel, Widerstände, Potis und Kondensatoren notwendig. Bei ausgefeilteren Mods kommen auch schon einmal Arduino Boards oder 555-ICs zum Einsatz. Jeder Mod benötigt den GND des Werkstatt-01. Dazu öffnet der Maker das Gehäuse, und verbindet das abisolierte Ende eines schwarzen Dupontkabels mit einer der inneren Schrauben, die das Synthesizerboard am metallenen Gehäuserahmen befestigen. Führt man das andere Ende dieses Kabels nach außen, lässt es sich mit der Schaltung des Mods als Common Ground verbinden.
Auf Sparkfun gibt es weitere Anregungen [12].
Die Schaltpläne des Werkstatt-01 hat Moog ebenfalls bereitgestellt -> Schematics [13].
Eine etwas komplexere Modifikation betrifft die Nutzung des VCO-Signals als Oszillator eines weiteren Synthesizers [14].
Der Besitzer des Werkstatt-01 offeriert also eine ganze Palette an Möglichkeiten zum Erweitern.
Sowohl der Moog Werkstatt-01 als auch der Korg NTS-1 kamen in diesem Blog zur Sprache, weil sie ermöglichen, Themen wie Elektronik und Musik, Mikrocontroller, Embedded Software zu adressieren. Die beiden vorgestellten Kits sind nicht mehr die jüngsten, stammen dafür von bekannten, innovativen Unternehmen, haben eine große Community, und lassen sich modifizieren beziehungsweise erweitern.
Wer einen ausgefeilten DiY-Synthesizer zu einem günstigen Preis sucht, sollte die Webseite von Zynthian besuchen. Bei Zynthian handelt es sich um eine Open Synth Software und gleichzeitig um eine Linux-Distribution für den Raspberry Pi (3 oder 4). Wer die Community unterstützen möchte, ordert das zugehörige Kit (aktuelle Version [15]). Ein Zynthian-Gerät lässt sich aber auch mit einfachen Mitteln selbst entwerfen und zusammenbauen. Von Floyd Steinberg gibt es dazu ein passendes YouTube-Video [16], in dem aus einem Raspberry Pi Board, einem kleinen Touch-Display und einem Midi-USB-Kabel ein Zynthian-Synthesizer entsteht.
Die Axoloi Community [17] hat ein Board erstellt (Axoloti Core), mit dem sich unter Zuhilfenahme einer außergewöhnlichen Software, dem Axoloti Patcher, coole Sachen machen lassen. Es könnte aber unter Umständen schwierig sein, ein solches Board zu erwerben. Zumindest hatte der Autor damit Probleme.
Weitere Kits stellt die britische Webseite TheVinylFactory [18] in einem Artikel vor.
Für Synthesizer-Interessierte mit mehr Bezug zum Musikmachen als zu Elektronik und Embedded Systemen, gibt es schon für wenige Hundert Euro sehr leistungsfähige Geräte. So eignen sich für den Einstieg zum Beispiel der Korg Minilogue XD oder der Wave-basierte ASM HydraSynth-Explorer, der Roland JD-Xi, der Arturia MicroFreak, der Behringer DeepMind 6, oder der Yamaha MX49 V2.
In dieser und der vorherigen Folge kamen die Synthesizer Korg NTS-1 und Moog Werkstatt-01 zur Sprache. Beide Kits stammen von renommierten Unternehmen, verfügen wegen ihres Alters über große Communitys, und erweisen sich als gut erweiterbar mittels eigener Software und Elektronik. Sie vermitteln Grundkenntnisse in puncto Synthesizer, und lassen sich durch die große Zahl von Informationsquellen leicht durchdringen. Während der Werkstatt-01 das Patchen über Kabel erlaubt, trumpft der NTS-1 mit mehr Schnittstellen auf. Das Experimentieren mit ihnen macht Spaß, weil man sie gut in die eigene Sound-Konfiguration integrieren kann. Beim ein oder anderen wird dadurch vielleicht der Funken entzündet, es auch mal mit ausgewachsenen Geräten zu versuchen.
URL dieses Artikels:https://www.heise.de/-6664968
Links in diesem Artikel:[1] https://www.heise.de/blog/Korg-NTS-1-Elektronik-trifft-auf-Musik-6658911.html[2] https://electronics.howstuffworks.com/gadgets/audio-music/synthesizer.htm[3] https://www.bonedo.de/artikel/crashkurs-synthesizer-und-sounddesign/[4] https://www.amazon.de/Synthesizer-So-funktioniert-elektronische-Klangerzeugung/dp/3941531700/ref=sr_1_1?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=MZ22TAN7M8MP&keywords=synthesizer&qid=1648769229&rnid=1703609031&s=books&sprefix=synthesizer%2Caps%2C98&sr=1-1[5] https://api.moogmusic.com/sites/default/files/2020-10/Werkstatt-01_Patchbook_2020.pdf[6] https://soundcloud.com[7] https://m.youtube.com/watch?v=xfWauY8H8J0[8] https://m.youtube.com/watch?v=vVNI3jibZ4U[9] https://api.moogmusic.com/sites/default/files/2018-04/Werkstatt_Expansion_Board_Final.pdf[10] https://www.moogmusic.com/media/werkstatt-01-projects-mods[11] https://back.moogmusic.com/sites/default/files/2020-10/Werkstatt_Modification_Handbook.pdf[12] https://www.sparkfun.com/news/1617[13] https://api.moogmusic.com/sites/default/files/2018-04/Werkstatt_01_Schematics.pdf[14] https://synthnerd.wordpress.com/category/moog-werkstatt/[15] https://shop.zynthian.org/shop/product/zynthian-kit-v4-6-448?category=13[16] https://youtu.be/Aq9Bavd7OqY[17] http://www.axoloti.com/[18] https://thevinylfactory.com/features/8-diy-analogue-synthesizers-you-can-build-at-home/[19] mailto:rme@ix.de
Copyright © 2022 Heise Medien
Der Synthesizer ist ein Paradebeispiel für die Symbiose aus Musikinstrumentenbau und Elektronik. Ein kleiner Bausatz macht Appetit darauf.
Egal ob Tonabnehmer, Instrumententuner oder Effektgeräte für Gitarristen - schon vor langer Zeit sind Musikinstrumentenbau und Elektronik eine erfolgreiche Symbiose eingegangen, anfangs bei Gitarren und Keyboards. Als Paradebeispiel für die vollständige Verschmelzung beider Disziplinen fungieren Synthesizer, weshalb in diesem Beitrag ein kleiner Bausatz im Vordergrund stehen soll.
1964 erschuf der legendäre Robert Moog den weltweit ersten analogen Synthesizer. Er hat anfangs die Geräte dieser Gattung als raumfüllende Spezialanfertigungen für Musikstudios konzipiert.
Erst ab 1970 wurden Synthesizer wie der kompakte Minimoog einem breiteren Publikum zugänglich und inspirierten andere Unternehmen dazu, auf Moogs Spuren zu wandeln. Firmennamen wie Korg, Roland, Akai oder Oberheim dürften für die meisten Musikgenießer bekannt klingen.
Heutzutage existieren Synthesizer in allen Leistungs- und Preisklassen. Korg, AKAI, Roland und selbst Moog bieten entsprechende Produkte für wenig Geld an.
Für noch weniger Geld lassen sich freilich im Apple App Store oder Google Play Store Apps erwerben, die ganze Synthesizer simulieren, darunter auch legendäre Geräte wie den Minimoog. Aber seien wir ehrlich: An die akkustischen und haptischen Momente mit echter Hardware kommen virtuelle Synthesizer nicht ran.
Wer aus Elektroniksicht tiefer in die Materie eintauchen und die innere Arbeitsweise von Synthesizern kennenlernen möchte, geht ins Museum oder legt selbst Hand an. Und dafür eignet sich insbesondere der Korg NTS-1, ein als Baukasten ausgelieferter minimalistischer Synthesizer. Es ist beileibe nicht der einzige Synthesizer-Bausatz, aber eindeutig einer der interessantesten.
Übrigens werde ich in einem Folgeartikel auch noch auf den Moog Werkstatt-01 eingehen, den Interessierte ebenfalls als Bausatz erwerben können, um sich als Besitzer eines Moog betrachten zu können.
Ein Synthesizer setzt per Klangsynthese in Echtzeit auf elektronischem Weg Klänge zusammen. Die Ansteuerung der synthetisierten Klänge kann durch einen Sequenzer (spielt gespeicherte Klangfolgen), einen Arpeggiator (spielt Akkorde) oder durch eine Klaviatur (spielt alle gedrückten Tasten) erfolgen.
Dabei synthetisiert ein monophoner Synthesizer nur einen Ton gleichzeitig, ein polyphoner Synthesizer hingegen mehrere. Die Elektronik eines Synthesizers, egal ob mono- oder polyphon, kann dabei analog, digital oder hybrid arbeiten.
Der erste Baustein, den Musiker auf einem Synthesizer vorfinden, ist ein sogenannter VCO (Voltage-Control-Oscillator), der eine Welle als Fundament erzeugt. Ein VCO erlaubt das Generieren von Wellen in verschiedenen Formen, Frequenzen und Amplituden. Als Wellenform treten häufig Sinuskurven, Sägezahn-, Dreieck- und Rechteckformen (Pulse) auf. Synthesizer wie der Korg-NTS1 erlauben zusätzlich benutzerdefinierte Wellenformen. Während eine Sinuswelle einen “sauberen” Ton erzeugt, weisen andere Wellenformen unterschiedliche charakteristische Obertöne (sogenannte Harmonics) auf. Das gilt auch für Musikinstrumente, weshalb mancher Synthesizer bei Wahl der richtigen Modellierungsparameter „echte“ Musikinstrumente sehr realitätsnah nachahmen kann.
Im Bereich Filter legen Anwender – nomen est omen – diverse Filter für den erzeugten Ton fest, zum Beispiel Low-Pass-, High-Pass- und Band-Pass-Filter. Das geschieht mittels einer Cut-Off-Frequenz, die die Grenze für das Abschneiden der Frequenz festlegt. Ein Low-Pass-Filter definiert beispielsweise eine Cut-Off-Frequenz, ab der ein Synthesizer die höherfrequenten Klanganteile herausfiltert, sodass nur noch die niedrigeren Frequenzen den Filter passieren können.
Synthesizer stellen in der Regel einen LFO (Low Frequence Oscillator) zur Verfügung, mit dessen Hilfe sich die erzeugte Wellenfunktion modulieren lässt. Normalerweise sind niederfrequente Wellen für den Menschen nicht wahrnehmbar. Sobald Nutzer den LFO allerdings dafür einsetzen, um eine andere (hörbare) Welle zu modulieren, verleiht er dem erzeugten Ton eine auch im menschlichen Ohr wahrnehmbare, spezielle Charakteristik. Mittels der Frequenz des LFO lässt sich so die Intensität der modulierten Welle festlegen, mit dessen Amplitude die Stärke des wahrnehmbaren Modulationseffekts. Mit einem LFO ist es beispielsweise möglich, Tremoloeffekte zu erzeugen.
Danach kommt der EG (Envelope Generator) zum Einsatz, der eine ADSR-Amplitudenhüllkurve definiert. Die einzelnen Buchstaben stehen für die Parameter Attack (Zeit bis der Ton sein Maximum erreicht), Decay (Zeit bis der Ton auf ein geringeres Plateau fällt), Sustain (Tonhöhe nach dem Decay) und Release (Zeit bis der Ton zu guter letzt wieder auf die Amplitude 0 fällt).
Zusätzlich ermöglichen Synthesizer das Anwenden diverser Effekte auf den Klang, etwa Reverb und Delay.
Ein Arpeggiator sorgt bei einem anhaltenden Tastendruck dafür, dass nicht nur ein einziger Ton sondern sequenziell die Töne eines Akkords abgespielt werden. Dabei lässt sich zum Beispiel festlegen, welche Oktave der Synthesizer abspielt, welchen Akkordtyp er dafür nutzt, wie lange jeder Ton anhält, wie lange die Pause zwischen Tönen dauern soll, und vieles mehr.
Wer glaubt, ein monophoner Synthesizer könne automatisch nur einen VCO besitzen, der liegt falsch. In einem monophonen Synthesizer können mehrere VCOs für schwebende Klänge sorgen. Polyphone Synthesizer besitzen hingegen immer mehrere VCOs, mit denen sich verschiedene Tonhöhen und deshalb auch Akkorde spielen lassen. Sie integrieren einen Mixer, mit dessen Hilfe der Musiker bestimmt, aus welchen Anteilen der diversen VCOs der resultierende Klang sich zusammensetzt. Das ist notwendig, weil etwa eine Sägezahnwelle durchsetzungsfähiger ist als eine Sinuswelle. In diesem Fall reicht von ersterem Signal oft ein kleinerer Anteil als vom zweiten Signal.
Das Schaltbild des weiter unten besprochenen monophonen Korg NTS-1 enthält alle genannten Komponenten: Oscillator (VCO), Filter, Envelope Generator, Modulator (LFO) sowie die Effekte Delay und Reverb. Durch Schalter (->Route) lassen sich auf Wunsch ein, zwei oder drei der letztgenannten Bausteine umgehen. Zusätzlich gibt es einen Eingang, um den Synthesizer von außen anzusteuern (etwa über ein Midi-Keyboard, Effektgeräte, oder andere Synthesizer) sowie Ausgänge für Kopfhörer beziehungsweise Lautsprecher oder andere nachgeschaltete Geräte (zum Beispiel Recorder, Sampler, Mixer). Mittels eines Arpeggiators lassen sich gemäß eingestellten Akkorden Sequenzen von so erzeugten Klängen abspielen.
In den meisten Synthesizern ist die dargestellte Signalkette mehr oder weniger fest integriert. Speziell modulare Synthesizer bieten dagegen die Möglichkeit, einzelne Komponenten beispielsweise über Patchkabel miteinander zu verbinden, um auf diese Weise beliebige Signalketten zu konfigurieren. Besonders die früheren Synthesizer waren an der verwirrenden Vielzahl ihrer Patchkabel zu erkennen. In einem YouTube Video [1] aus dem Jahr 1970 demonstriert Wendy Carlos dieses Vorgehen. Sie war Mitarbeiterin des Synthesizer-Pioniers Robert Moog und erlangte 1968 als Künstlerin mit dem Album “Switched-on Bach” Berühmtheit, auf dem – wie sollte es anders sein – ein Moog-Synthesizer zum Einsatz kam.
Insgesamt stellt ein Synthesizer also sehr viele Stellschrauben zur Verfügung, mit denen sich gefühlt unendlich viele Sound-Landschaften gestalten lassen. Jeder Synthesizer verfügt über spezielle Hardwareeigenschaften, die das Klangbild mitbestimmen. So besitzen Synthesizer von Moog einen sehr charakteristischen “fetten” Klang.
Es gibt auch Synthesizer, die andere Verfahren nutzen, etwas Wavelists und Waveforms wie der ASM HydraSynth. Deren Potenzial ist wesentlich größer, dafür die Umsetzung von Klangideen meistens aufwendiger. Auf diese alternativen Konzepte geht der vorliegende Artikel aus Platzgründen nicht ein.
Für den Preis und die Mächtigkeit eines Synthesizers gibt es scheinbar keine Grenze nach oben. Das gilt aber nicht für den Geldbeutel und die Wünsche von uns Normalsterblichen. Zum Glück geht es auch sehr günstig und minimalistisch. Der hybride monophone Korg NTS-1 richtet sich zum einen an diejenigen, die Erfahrung mit einem Synthesizer erwerben wollen, und zum anderen an erfahrene Zeitgenossen, die das Gerät als zusätzliche Möglichkeit betrachten, eigene Soundquellen aufzupeppen. Für einen Straßenpreis von 99 Euro können Interessenten den Bausatz erwerben, der neben dem Kurzmanual auch einen QR Code enthält. Letzterer verweist auf eine Korg-Webseite mit der visuellen Bauanleitung für den NTS-1 [2], wobei der Begriff “Bausatz” auf einige abschreckend wirken könnte. Genau genommen, besteht das Zusammenbauen in diesem Fall nicht aus Löten, sondern im wesentlichen aus dem Zusammenstecken zweier Platinen und dem Zusammenschrauben des Gehäuses.
Das “Zerbrechen” der großen Platte in ihre Einzelteile (Platinen) anhand der perforierten Schnittstellen, ist dabei noch das kritischste Manöver. Genau genommen, ist das Zusammenbauen selbst für Zeitgenossen mit zwei linken Händen keine echte Herausforderung. Die ganze Montage ist deshalb in gut einer halben Stunde erledigt.
Sobald der NTS-1 über ein Micro-USB-Kabel zum ersten Mal Strom erhält, fährt das Gerät hoch, und gibt durch das Aufflackern diverser LEDs und Texten in der Anzeige ein erstes Lebenszeichen von sich. Wer über die 3,5mm-Klinkenbuchse an der Gehäusefront einen Kopfhörer anschließt, kann sofort mit dem Experimentieren anfangen. Das Gerät integriert aber auch einen eingebauten Lautsprecher mit geringer Leistung als Nice-to-have-Feature. Die aufgeklebte Miniklaviatur dient der Bedienung. Das ist zwar pragmatisch, aber nicht besonders bequem. Besitzer eines Midi-Keyboards können dieses per Midi-Kabel mit dem Midi-in-Eingang des NTS-1 verbinden (Typ: TRS-A 3,5mm-Klinkenbuchse), was die Bedienung spürbar erleichtert. Über den Audio-in-Eingang lassen sich eigene Tonquellen anschließen. Zwei weitere Buchsen Sync-In/-Out helfen bei der Synchronisation mit und über andere Geräte.
Ein paar Proben gefällig? Als Appetithäppchen hat Korg ein paar Soundbeispiele auf der Soundcloud [3] veröffentlicht (Suchstring: “Korg NTS-1”). Dort lässt sich ein erster Eindruck von den vielfältigen musikalischen Möglichkeiten des Miniatur-Synthesizers gewinnen.
Dass der Synthesizer nicht als Spielzeug konzipiert ist, liegt auf der Hand, zumal er dieselben Komponenten verwendet, die auch bei seinen “ausgewachsenen” Brüdern Korg Minilogue XD und Korg Prologue zum Einsatz kommen. Der Autor als Besitzer eines Korg Minilogue und eines Minilogue XD kann das aus eigener Erfahrung bestätigen.
Der NTS-1 ist deshalb auch kompatibel mit dem logue-SDK der Synthesizerproduktfamilie bestehend aus Korg Minilogue, Korg Monologue und eben auch Korg NTS-1. Die zugehörigen Dateien befinden sich auf einem Github-Repository [4]. Als Programmiersprache liegt C++ zugrunde. Diverse Hobbyisten und Profis haben damit bereits zum Teil sehr ausgefeilte eigene Effekte und Oszillatoren entwickelt. Eine Sammlung von freien Oszillatoren ist beispielsweise über die Webseite [5] verfügbar. Bei einer Websuche finden sich aber noch wesentlich mehr Effekte und Oszillatoren sowie YouTube-Videos zu dem Thema.
Wer keine Lust hat, das SDK programmatisch zu nutzen, kann stattdessen auf Windows oder macOS die Software NTS-1 digital Librarian [6]installieren, die das bequeme Laden und Verwalten von vorgefertigten Oszillatoren und Effekten über eine grafische Oberfläche unterstützt ). Damit lassen sich allerlei mächtige Funktionalitäten auf das Gerät laden.
Wer noch mehr Futter für den NTS-1 braucht, findet bei Hammond Eggs Music [7] passende logue-Plug-ins für alle Korg-Produkte aus der logue-Familie (NTS-1, Prologue und Minilogue XD).
Übrigens: Momo Müller bietet für 6,90€ einen interaktiven Editor [8] für den NTS-1 sowohl als Standalone-Programm als auch als VST-Plug-in an. Damit lässt sich der Synthesizer problemlos in eine DAW (Digital Audio Workstation) der Wahl integrieren.
Der spanischen Entwickler Oscar RC stellt einen kostenlosen Webeditor für den NTS-1 zur Verfügung, der als PWA (Progressive Web Application) sogar offline funktioniert. Die Quellen dazu gibt es auf GitHub [9].
Sogar das Erstellen einer eigenen Frontplatte für den NTS-1 ist denkbar. So findet sich auf der Webseite [10] eine alternative Frontplatte für den NTS-1, die sich über Arduino-Shields erweitern lässt. Auf der genannten Webseite gibt es noch weitere Custom Front Panels und den Verweis auf einen ausführlichen Arduino-Sketch mit einem Sequencer-Template. Ein zusätzliches YouTube-Video [11] erläutert den Austausch der normalen Frontplatte mit der gerade beschriebenen alternativen Frontplatte.
Synthesizer sind heute nicht mehr von professionellen Musikproduktionen wegzudenken. Das Arbeiten mit ihnen macht nicht nur Musikenthusiasten sehr viel Spaß. Wer wissen möchte, wie ein Synthesizer intern funktioniert, erlebt mit Bausätzen wie dem Korg NTS-1 zwar keine Erleuchtung, aber zumindest interessante Einblicke, gerade weil sie minimalistisch gehalten sind. Zur Hilfestellung gibt es auf YouTube zahlreiche informative Videos nicht nur allgemein über Synthesizer, sondern auch speziell über den NTS-1.
Apropos YouTube. Wer noch mehr über den NTS-1 erfahren will. Unter dem Link [12] finden sich Dutzende Videos zu diesem Thema.
Ohnehin ist es spannend, dass es um den NTS-1 inzwischen eine große Community gibt. Nicht schlecht für einen preisgünstigen DiY-Synth. Natürlich lässt der Name des Geräts vermuten, dass es irgendwann auch einen NTS-2 geben könnte. Einige NTS-1-Liebhaber scharren deshalb schon mit ihren Hufen.
Wer den Bausatz erwerben möchte, besucht am besten die Webseiten großer Fachgeschäfte. Für den vorliegenden Artikel hat der Autor sein Exemplar bei Thomann [13] erworben.
URL dieses Artikels:https://www.heise.de/-6658911
Links in diesem Artikel:[1] https://www.youtube.com/watch?v=4SBDH5uhs4Q[2] https://m.youtube.com/watch?v=g_310MHzd0o&feature=emb_logo[3] https://soundcloud.com[4] https://github.com/korginc/logue-sdk[5] https://korginc.github.io/logue-sdk/unit-index/[6] https://www.korg.com/de/products/dj/nts_1/librarian_contents.php[7] https://hammondeggsmusic.ca/logueplugins.html[8] https://korg-nts-1-editor-soundbank.jimdofree.com/#link1[9] https://github.com/oscarrc/nts-web[10] https://korginc.github.io/nts-1-customizations/[11] https://m.youtube.com/watch?v=dL5zSNJrvd8&feature=emb_imp_woyt[12] https://m.youtube.com/results?sp=mAEA&search_query=nts-1[13] https://www.thomann.de/de/korg_nts_1.htm[14] mailto:rme@ix.de
Copyright © 2022 Heise Medien
Die Frage "Ist diese Software-Architektur zukunftssicher?" kann man eigentlich generell mit "nein" beantworten. Schlimmer noch: Die Frage zu stellen, kann schon auf ein falsches Verständnis von Architektur hinweisen.
Die Frage "Ist diese Software-Architektur zukunftssicher?" kann man eigentlich generell mit "nein" beantworten. Schlimmer noch: Die Frage zu stellen, kann schon auf ein falsches Verständnis von Architektur hinweisen.
Die Softwarearchitektur eines IT-Systems umfasst zwei Bereiche: Die Technologien zur Umsetzung und die Strukturierung des Systems in einzelne Module. Geht es um die Zukunftssicherheit von Architekturen, muss man beide Bereiche betrachten.
Eine grobgranulare Struktur eines Systems ist notwendig, damit Menschen das System verstehen und ändern können. Softwaresysteme werden im Team entwickelt. Das führt zu einem Problem: Kein Mensch kann die Arbeit aller Menschen aus dem Team im Detail verstehen. Eine Strukturierung des Systems in Module ermöglicht ein Verständnis auf einer abstrakten Ebene - der Ebene der Module und nicht auf der Ebene einzelner Codezeilen.
Die architekturelle Struktur sollte die Module des Systems so anordnen, dass Funktionalitäten leicht zu ändern und zu verstehen sind. Also hängt die Struktur von den Funktionalitäten und damit von den Anforderungen ab. Das zentrale Problem bei der Softwareentwicklung ist, dass sich Anforderungen ändern – nicht nur weil Kunden neue Anforderungen stellen, sondern auch, weil beim Durchdenken oder bei der Anwendung des Systems Anforderungen klarer werden, sich neue Möglichkeiten offenbaren oder Inkonsistenzen auftauchen und beseitigt werden müssen. Teams, Kundinnen und Anwender lernen ständig mehr über das System und die zu entwickelnde Funktionalität. Dieses neue Wissen zu ignorieren,wäre absurd. Daher ergeben sich zwangsläufig Änderungen.
Einige Änderungen an den Anforderungen sind so signifikant, dass die Strukturierung des Systems und damit die Architektur angepasst werden muss. Ob das System zukunftssicher ist, entzieht sich also prinzipiell unserer Kenntnis, weil wir die Zukunft und die neuen Anforderungen nicht absehen können. Vielleicht passt die Architektur gut zu den neuen Anforderungen, vielleicht sind aber auch größere Änderungen notwendig.
Aber nicht alle neuen Anforderungen sind vollkommen überraschend. Natürlich ist es sinnvoll, absehbare Änderungen in den Entwurf der Architektur einzubeziehen. Wenn die Änderungen dann doch nicht erfolgen, ist die Architektur an einigen Stellen unnötig flexibel und daher möglicherweise an einigen Stellen zu kompliziert. Das ist aber ein weiterer Trade-off in der Architektur. Soll das System auf absehbare Änderungen vorbereitet werden oder nicht? Über solche Fragen nachzudenken und sie individuell zu entscheiden, ist sicher besser, als sie blind mit "You Ain't Gonna Need It" (YAGNI, Du wirst es nicht brauchen) zu beantworten. Dieses Motto stammt aus dem Extreme-Programming-Umfeld der Jahrtausendwende. Es diente dazu, sich gegen übermäßig generische Lösungen abzusetzen. Wenn man nämlich ein System so entwickelt, dass es auf alle denkbaren Änderungen vorbereitet ist, wird es übermäßig komplex. Daher sollte die Architektur nur absehbare Änderungen in Erwägung ziehen und diese auch nur dann in den Architektur einfließen lassen, wenn die Vorteile klar überwiegen.
Dennoch kann man in der Strukturierung eine gewissen Zukunftsfähigkeit des Systems erreichen. Wenn die Strukturierung das Verständnis nicht erleichtert oder wenn Module nicht lose gekoppelt sind und Änderungen dadurch immer größere Teile des System betreffen, dann ist das System schon jetzt nicht einfach wartbar. Das wird sich in Zukunft nicht verbessern.
Wenn zentrale Konzepte der Fachdomäne gar nicht im System abgebildet sind oder fachliche Konzepte generell im System schlecht repräsentiert sind, ist es schwierig die Abbildung der Fachlichkeit auf das System zu verstehen. Verständnis ist aber die Voraussetzung für jede Änderung.
Also kann man die Struktur des Systems möglichst eng an der Fachlichkeit ausrichten und so zukunftsfähig gestalten. Wenn die fachlichen Konzept klar und verständlich umgesetzt sind, kann man sie auch einfach ändern und auf zukünftige Anforderungen anpassen. Über die fachlichen Konzepte hinaus eingebaute Flexibilität schadet dabei mehr als sie hilft: Sie ist meistens an den falschen Stellen und verschlechtert damit die Verständlichkeit. Man kann eben zukünftige Änderungen nicht vorweg erahnen und einfach implementierbar machen.
Neben der Struktur ist auch die Technologieauswahl ein wichtiger Teil der Architektur. Softwareentwicklung unterliegt einem ständigen Technologiewandel. Man kann einem Technologie-Stack dennoch bescheinigen, dass er mehr oder weniger modern ist. Diese Aussage weist schon auf mangelnde Zukunftssicherheit hin: Was heute modern ist, ist morgen veraltet. “Modern” ist zunächst ein relativ inhaltsleerer Begriff: Was nützt es, wenn eine Technologie erst einige Jahre alt ist?
Die Modernität von Technologien darf kein Selbstzweck sein: Schließlich sollen Softwarearchitekturen Geschäftsprobleme lösen – und dazu ist ein möglichst moderner Technologie-Stack nicht zwingend notwendig. Aufwand, der in die Modernisierung von Technologien und das Erlernen neuer Ansätze fließt, sollte vielleicht besser in Aktivitäten fließen, die Geschäftswert erzeugen. Aber irgendwann sind Technologien so alt, dass sie nicht mehr weiter gepflegt werden. Spätestens wenn dann Sicherheitsupdates ausbleiben, muss man aktualisieren oder umsteigen. Sonst kann ein Sicherheitsproblem dazu führen, dass das System nicht mehr nutzbar ist oder gar erheblichen Schaden anrichtet. In beiden Fällen erzeugt das System keinen Geschäftswert mehr, sondern im Extremfall einen Geschäftsverlust. Wenn irgendwann die Technologien so alt sind, dass sich niemand mehr damit beschäftigen will, nimmt der Druck für eine Migration weiter zu.
Es kann natürlich Technologien geben, die scheinbar zukunftssicher sind. Die Programmiersprache Java beispielsweise gibt es seit über 25 Jahren. Aber auch hier gilt: Alte Java-Versionen bekommen keine Sicherheitsupdates mehr. Und Java-Code aus dem letzten Jahrhundert sieht wegen neuer Sprach-Features anders aus als aktueller Code. Schließlich gibt es ganz andere Frameworks oder zumindest neue Versionen der Frameworks. Selbst eine Technologie, die lange existiert, ist also einem Wandel unterworfen und muss ständig aktualisiert werden.
Anders gesagt: Man kommt nicht darum herum, neue Technologien einzusetzen. Der Wunsch nach einer Zukunftssicherheit ist nicht realisierbar.
Container können die Zukunftssicherheit erhöhen: Jeder Container enthält ein eigenes Dateisystem und ist von anderen Containern weitgehend isoliert. Aus Sicht der Software wirkt es fast so, als wäre jeder Container ein getrennter Computer mit einem eigenen Dateisystem, einer eigener Netzwerkschnittstelle usw. Daher können in jedem Container eine eigene Programmiersprache und eigene Frameworks eingesetzt werden. Wenn man beispielsweise mit Microservices die Teile des Systems auf mehrere Container verteilt, kann ein Update auf eine neue Technologie zunächst in einem Container und dann schrittweise in anderen Containern umgesetzt werden. Das ist risikoärmer und macht die Architektur zukunftssicherer, weil die Einführung neuer Technologien einfacher wird.
Container-Technologien sind aber auch irgendwann erfunden worden: Kubernetes gibt es seit 2014, Docker seit 2013. Bis die Technologien im Mainstream angekommen sind, hat es dann noch einige Jahre gedauert. Um sie zu nutzen, muss man ältere Projekte ändern. Diese Innovationen sind nicht vorhersehbar. 2012 kann kein Architektur-Review vorhergesehen haben, dass ein Projekt nicht zukunftssicher ist, weil es keine Container nutzt.
Und eines ist auch bei Containern sicher: Es wird eine Zeit geben, in der man die Nase rümpft, wenn jemand noch Container nutzt, weil es dann eine viel bessere, neue Technologie geben wird.
Hinzu kommt: In einem Frontend mehrere JavaScript-Frameworks gemeinsam zu nutzen bleibt eine echte Herausforderung – aber die Geschwindigkeit, mit der neue JavaScript-Frameworks erscheinen, ist nach wie vor beeindruckend. Also sind diese Probleme gerade da schwer lösbar, wo neue Technologien noch mit einer viel größeren Geschwindigkeit erscheinen.
Man sollte sich also an den Gedanken gewöhnen, dass man im Moment an Lösungen arbeitet, die irgendwann technologisch veraltet sind. Und man kann das Problem höchstens abmildern, aber nicht lösen.
Die Frage nach der Zukunftssicherheit kann sogar ein Hinweis auf ein Problem sein: Wenn eine Architektur zukunftssicher wäre, müsste man sie nicht korrigieren. Das ist aber wünschenswert. Wenn Korrekturen stattdessen als Schwäche einer Architektur interpretiert und daher möglichst wenige zum Ziel werden, kann ein Problem sein. Dann können Hinweise auf eigentlich notwendige Änderungen ignoriert werden, um keine Korrekturen an der Architektur vornehmen zu müssen. Wer will schon gerne eingestehen, dass die Architektur eben nicht zukunftssicher war? Durch das Unterdrücken der Änderungen erscheint die Architektur "zukunftssicher", aber in Wirklichkeit passt die Architektur zunehmend schlechter zum System. Dass Architekturen nicht rechtzeitig an Änderungen angepasst werden, ist vermutlich eine größere Quelle für schlechte Architekturen als Probleme mit dem ursprünglichen Entwurf. So führt der Wunsch nach einer zukunftssicheren Architektur zu einer schlechteren Architektur.
Aber diese Paradoxie muss nicht der einzige Grund für ausbleibende Änderungen an der Architektur sein. Eine Architektur zu ändern ist anstrengend: Schließlich hat man sich mit dem Entwurf viel Mühe gegeben und vielleicht wesentliche Konzepte sogar schon in Prototypen ausprobiert. Von diesen ganzen Mühen Abschied zu nehmen, kann schwer fallen, ist aber manchmal nötig. Und man sollte auch kein schlechtes Gewissen haben, weil die Architektur nun obsolet ist. Softwareentwicklung ist nur in Iterationen umsetzbar. Eine Iteration der Architektur trägt die nächste schon in sich. Dennoch muss man sich bei dem Entwurf der Architektur Mühe geben. Erst wenn man wirklich versucht, die Architektur zu entwerfen, werden sich die Optimierungspotentiale zeigen.
Wenn es notwendig ist, Architekturen ändern zu können, kann die Erstellung der Architektur keine Phase in einem Projekt sein, die irgendwann abgeschlossen ist. Schließlich muss die Architektur ständig an die sich ändernde Welt angepasst werden. Dazu sollte es einen Prozess geben. Wenn es nämlich keinen Prozess für Änderungen an der Architektur gibt, wird sie vermutlich nicht angepasst werden. Dann lassen sich die Funktionalitäten zunehmend schlechter umsetzen.
Die Frage nach einem Architekturänderungsprozess ist also wichtiger als die Frage nach der Zukunftssicherheit der Architektur. Und Projekte, die auf diese Frage keine Antwort haben, setzen sich der Gefahr aus, in Zukunft Schwierigkeiten mit der Architektur zu haben.
Technologische Innovationen und neue Anforderungen machen Änderungen an der Architektur zwingend - sie kann nicht zukunftssicher sein. Lösung: Dieser Realität in die Augen sehen und Architekturen anpassen, wenn notwendig.
Vielen Dank an Gerrit Beine, Martin Eigenbrodt, Joachim Praetorius und Gernot Starke für die Kommentare zu einer früheren Version des Artikels.
URL dieses Artikels:
https://www.heise.de/-6655162
Links in diesem Artikel:
[1] mailto:eberhard.wolff@gmail.com
Copyright © 2022 Heise Medien
Als neues Mitglied der x86-Familie soll Overdrive aus dem Aschenputtel 486SX eine Prinzessin machen. c’t hat im Labor untersucht, ob das gelingt.
Vor 30 Jahren: Dieser Beitrag stammt aus c't 6/1992
Der Reigen neuer Intel-Prozessoren nimmt kein Ende. Am 26. Mai wird ein weiteres Mitglied der x86-Familie offiziell in die Gesellschaft eingeführt. Overdrive heißt der Debütant. Wir hatten bereits vor der Premiere Gelegenheit, Intels jüngstem Sproß auf den Zahn zu fühlen.
Vor knapp einem Jahr stellte Intel als Reaktion auf AMDs 40-MHz-386 den i486SX vor. Die Parole der Marketing-Strategen hieß damals: „Vier ist mehr als Drei“. Die Praxis zeigte allerdings schnell, daß AMDs 40-MHz-386 schneller war als der mit 20 MHz getaktete Kontrahent - vierzig ist eben doch mehr als zwanzig. Inzwischen ist das 486-Kastrat nicht nur im begehrten Plastikgehäuse, sondern auch als 25-MHz-Version erhältlich und wartet so mit etwa der gleichen Leistung wie die AMD-CPU auf.
Gegen diese rein leistungorientierte Argumentation führte Intel das Schlagwort „Upgradability“ in die Diskusion ein. Der Performance-Upgrade-Sockel sollte dem 486SX-Anwender den Weg in die Zukunft offen halten. Bisher sah diese Zukunft allerdings eher wie eine Sackgasse aus: Das einzige real existierende Upgrade war der 487SX, der den SX auf den (Leistungs-)Stand des 25-MHz-DX hob, indem er den Coprozessor nachlieferte. Zu allem Überfluß kostete dieses Upgrade etwa genauso viel wie ein komplettes Motherboard mit dem schnelleren 486/33-Prozessor.
Neue Perspektiven soll jetzt der Overdrive 486SX schaffen. Er arbeitet - wie der bereits in c't 4/92 vorgestellte DX2 - intern mit doppelter Frequenz, hat allerdings ein anderes, dem Upgrade-Sockel angepaßtes Pinout. Außerdem trägt er einen Kühlkörper, der die 50-MHz-Version des Overdrive vor dem Hitzetod bewahren soll. Intern sind die beiden Prozessoren gleich.
Entsprechend fielen auch unsere Testergebnisse aus. Alle Programme, die – wie das 3D-Studio – vorwiegend mit kleinen Schleifen arbeiten, profitieren besonders stark vom höheren internen Takt, da sie innerhalb des 8 KByte großen integrierten Cache ablaufen. Hier ergeben sich Steigerungsraten von bis zu 95 Prozent gegenüber dem 487SX. Je intensiver ein Programm auf I/O- oder Memory-Transfer angewiesen ist, um so stärker wirkt sich die langsamere externe Taktfrequenz aus.
Besonders deutlich zeigt sich das beim Apfelmännchen. Die Version ohne Grafikausgabe läuft doppelt so schnell wie auf dem 487SX. Bei der anderen Version bremst die Grafikausgabe, die Steigerungsrate liegt nur noch bei 64 Prozent. Noch deutlicher sinkt die Performance beim AutoCAD-11-Benchmark. Dieser arbeitet intensiv mit Grafikkarte und Hauptspeicher, so daß der „Over“getriebene Rechner nur noch 59 Prozent schneller als der i487SX ist.
Technisch gesehen ist der Overdrive also auf jeden Fall das bessere Upgrade für den 486SX. Er bietet – im Gegensatz zum i487SX – einen echten Performance-Gewinn gegenüber dem 486. Ob der SX-Anwender das allerdings auch so sieht, hängt von Intels Preispolitik ab. Wenn sich der Preis des Overdrive etwa in der Größenordnung des i487SX einpendelt, hat es sich für den Anwender sicher gelohnt, auf das SX-Pferd zu setzen. Andernfalls bewahrheitet sich allerdings unser bereits bei Einführung des SX geäußerter Verdacht eines Schildbürgerstreichs auf Kosten der Anwender.
Es bleibt zu hoffen, daß Intel dem SX dieses Schicksal erspart, zumal sich die preisliche Positionierung des Overdrive als Nagelprobe für weitere Projekte dieser Art erweisen könnte. Nur wenn der Anwender für den Upgrade-Prozessor deutlich weniger investieren muß als für ein neues Board der gleichen Prozessorklasse, geht die Rechnung auf.
Das nächste Upgrade-Projekt hat Intel bereits auf leisen Sohlen mit dem DX2 begonnen. Bei genauerem Hinsehen stellt man fest, daß dieser Chip ein vom normalen 486DX abweichendes Pinout hat. Fünf Pins sind hinzugekommen: Vier dienen - wie schon beim 50-MHz-486 - als Testpins für den Boundary Scan (TCK, TDI, TDO und TMS), der fünfte ist neu. Mit diesem Upgrade Present Signal (UP) läßt sich der DX2 abschalten.
Wer sich bis ans Ende der Design-Empfehlungen für DX2-Systeme durchkämpft, entdeckt dort auch die Spezifikation des Upgrade-Sockels. Er besteht aus einer 240poligen PGA-Fassung, deren innere 169 Pins kompatibel zum 487SX/Overdrive-Sockel sind. Auf der neu hinzugekommenen äußeren Kontaktreihe befinden sich neben drei Orientierungs-Pins und Masse-Kontakten sieben mit RES 1 bis RES 7 bezeichnete zusätzliche Anschlüsse.
Obwohl Intel keinerlei Informationen über diese neuen Signale preisgibt, erlaubt dieser Sockel doch schon einige Rückschlüsse auf den zu erwartenden neuen Prozessor - nennen wir ihn einmal 586-Overdrive. Wie der DX2 wird auch dieser Chip als Double-Clock-Prozessor arbeiten. Ein höheres Verhältnis zwischen internem und externem Takt erscheint mir aus heutiger Sicht wenig sinnvoll. Auch die Datenbusbreite wird - wie beim DX2 - zumindest extern bei 32 Bit bleiben. Intern ist eine Verbreiterung des Datenbus auf 64 Bit allerdings ohne weiteres möglich.
Der 586-Overdrive wird mit Sicherheit einen integrierten Cache besitzen. Es ist sehr wahrscheinlich, daß dieser deutlich größer als die bisher bei 486-Systemen üblichen 8 KByte wird. Die zusätzlichen Steuerleitungen legen darüber hinaus die Vermutung nahe, daß Intel auch an eine Modifikation der Cache-Strategie denkt. Der DX2 arbeitet wie alle 486er mit einem Write-Through-Cache. Moderne Motherboard-Designs ergänzen diesen meist durch einen externen Write-Buffer. Was liegt also näher, als einen solchen Buffer direkt in die neue CPU zu integrieren? Eine andere Möglichkeit bestünde darin, den integrierten Cache der Upgrade-CPU als Write-Back-System auszuführen.
Intel will nach eigener Aussage in Zukunft für jede Prozessorgeneration einen Upgrade-Sockel spezifizieren. Dieser soll dem Anwender einen Umstieg auf die neue Prozessorgeneration auch ohne Boardwechsel ermöglichen und so die einmal getätigten Investitionen schützen. Intel hat es in der Hand, ob auch der Anwender etwas von den neuen Upgrade-Möglichkeiten hat. Nur ein attraktiver Preis für die Overdrive-CPUs wird zur Akzeptanz der neuen Strategie führen.
Eins ist auf jeden Fall klar: Boardhersteller werden freiwillig keinen Upgrade-Sockel vorsehen. Sie verdienen schließlich nichts daran, wenn ein Kunde in einen Overdrive investiert, statt sich ein neues Board zu kaufen. Nur wenn es gelingt, die Upgrade-Möglichkeit als Qualitätskriterium zu etablieren, werden Hersteller diese auch vorsehen. Die Schlüssel dazu halten der Marktführer und König Kunde in der Hand. Es täte dem Markt gut, wenn Intel durch eine attraktive Preispolitik seinen Teil dazu beitragen würde.
()
URL dieses Artikels:https://www.heise.de/-7103801
Links in diesem Artikel:[1] mailto:gs@ct.de
Copyright © 2022 Heise Medien
Die Frage "Ist diese Software-Architektur zukunftssicher?" kann man eigentlich generell mit "nein" beantworten. Schlimmer noch: Die Frage zu stellen, kann schon auf ein falsches Verständnis von Architektur hinweisen.
Die Softwarearchitektur eines IT-Systems umfasst zwei Bereiche: Die Technologien zur Umsetzung und die Strukturierung des Systems in einzelne Module. Geht es um die Zukunftssicherheit von Architekturen, muss man beide Bereiche betrachten.
Eine grobgranulare Struktur eines Systems ist notwendig, damit Menschen das System verstehen und ändern können. Softwaresysteme werden im Team entwickelt. Das führt zu einem Problem: Kein Mensch kann die Arbeit aller Menschen aus dem Team im Detail verstehen. Eine Strukturierung des Systems in Module ermöglicht ein Verständnis auf einer abstrakten Ebene - der Ebene der Module und nicht auf der Ebene einzelner Codezeilen.
Die architekturelle Struktur sollte die Module des Systems so anordnen, dass Funktionalitäten leicht zu ändern und zu verstehen sind. Also hängt die Struktur von den Funktionalitäten und damit von den Anforderungen ab. Das zentrale Problem bei der Softwareentwicklung ist, dass sich Anforderungen ändern – nicht nur weil Kunden neue Anforderungen stellen, sondern auch, weil beim Durchdenken oder bei der Anwendung des Systems Anforderungen klarer werden, sich neue Möglichkeiten offenbaren oder Inkonsistenzen auftauchen und beseitigt werden müssen. Teams, Kundinnen und Anwender lernen ständig mehr über das System und die zu entwickelnde Funktionalität. Dieses neue Wissen zu ignorieren,wäre absurd. Daher ergeben sich zwangsläufig Änderungen.
Einige Änderungen an den Anforderungen sind so signifikant, dass die Strukturierung des Systems und damit die Architektur angepasst werden muss. Ob das System zukunftssicher ist, entzieht sich also prinzipiell unserer Kenntnis, weil wir die Zukunft und die neuen Anforderungen nicht absehen können. Vielleicht passt die Architektur gut zu den neuen Anforderungen, vielleicht sind aber auch größere Änderungen notwendig.
Aber nicht alle neuen Anforderungen sind vollkommen überraschend. Natürlich ist es sinnvoll, absehbare Änderungen in den Entwurf der Architektur einzubeziehen. Wenn die Änderungen dann doch nicht erfolgen, ist die Architektur an einigen Stellen unnötig flexibel und daher möglicherweise an einigen Stellen zu kompliziert. Das ist aber ein weiterer Trade-off in der Architektur. Soll das System auf absehbare Änderungen vorbereitet werden oder nicht? Über solche Fragen nachzudenken und sie individuell zu entscheiden, ist sicher besser, als sie blind mit "You Ain't Gonna Need It" (YAGNI, Du wirst es nicht brauchen) zu beantworten. Dieses Motto stammt aus dem Extreme-Programming-Umfeld der Jahrtausendwende. Es diente dazu, sich gegen übermäßig generische Lösungen abzusetzen. Wenn man nämlich ein System so entwickelt, dass es auf alle denkbaren Änderungen vorbereitet ist, wird es übermäßig komplex. Daher sollte die Architektur nur absehbare Änderungen in Erwägung ziehen und diese auch nur dann in den Architektur einfließen lassen, wenn die Vorteile klar überwiegen.
Dennoch kann man in der Strukturierung eine gewissen Zukunftsfähigkeit des Systems erreichen. Wenn die Strukturierung das Verständnis nicht erleichtert oder wenn Module nicht lose gekoppelt sind und Änderungen dadurch immer größere Teile des System betreffen, dann ist das System schon jetzt nicht einfach wartbar. Das wird sich in Zukunft nicht verbessern.
Wenn zentrale Konzepte der Fachdomäne gar nicht im System abgebildet sind oder fachliche Konzepte generell im System schlecht repräsentiert sind, ist es schwierig die Abbildung der Fachlichkeit auf das System zu verstehen. Verständnis ist aber die Voraussetzung für jede Änderung.
Also kann man die Struktur des Systems möglichst eng an der Fachlichkeit ausrichten und so zukunftsfähig gestalten. Wenn die fachlichen Konzept klar und verständlich umgesetzt sind, kann man sie auch einfach ändern und auf zukünftige Anforderungen anpassen. Über die fachlichen Konzepte hinaus eingebaute Flexibilität schadet dabei mehr als sie hilft: Sie ist meistens an den falschen Stellen und verschlechtert damit die Verständlichkeit. Man kann eben zukünftige Änderungen nicht vorweg erahnen und einfach implementierbar machen.
Neben der Struktur ist auch die Technologieauswahl ein wichtiger Teil der Architektur. Softwareentwicklung unterliegt einem ständigen Technologiewandel. Man kann einem Technologie-Stack dennoch bescheinigen, dass er mehr oder weniger modern ist. Diese Aussage weist schon auf mangelnde Zukunftssicherheit hin: Was heute modern ist, ist morgen veraltet. “Modern” ist zunächst ein relativ inhaltsleerer Begriff: Was nützt es, wenn eine Technologie erst einige Jahre alt ist?
Die Modernität von Technologien darf kein Selbstzweck sein: Schließlich sollen Softwarearchitekturen Geschäftsprobleme lösen – und dazu ist ein möglichst moderner Technologie-Stack nicht zwingend notwendig. Aufwand, der in die Modernisierung von Technologien und das Erlernen neuer Ansätze fließt, sollte vielleicht besser in Aktivitäten fließen, die Geschäftswert erzeugen. Aber irgendwann sind Technologien so alt, dass sie nicht mehr weiter gepflegt werden. Spätestens wenn dann Sicherheitsupdates ausbleiben, muss man aktualisieren oder umsteigen. Sonst kann ein Sicherheitsproblem dazu führen, dass das System nicht mehr nutzbar ist oder gar erheblichen Schaden anrichtet. In beiden Fällen erzeugt das System keinen Geschäftswert mehr, sondern im Extremfall einen Geschäftsverlust. Wenn irgendwann die Technologien so alt sind, dass sich niemand mehr damit beschäftigen will, nimmt der Druck für eine Migration weiter zu.
Es kann natürlich Technologien geben, die scheinbar zukunftssicher sind. Die Programmiersprache Java beispielsweise gibt es seit über 25 Jahren. Aber auch hier gilt: Alte Java-Versionen bekommen keine Sicherheitsupdates mehr. Und Java-Code aus dem letzten Jahrhundert sieht wegen neuer Sprach-Features anders aus als aktueller Code. Schließlich gibt es ganz andere Frameworks oder zumindest neue Versionen der Frameworks. Selbst eine Technologie, die lange existiert, ist also einem Wandel unterworfen und muss ständig aktualisiert werden.
Anders gesagt: Man kommt nicht darum herum, neue Technologien einzusetzen. Der Wunsch nach einer Zukunftssicherheit ist nicht realisierbar.
Container können die Zukunftssicherheit erhöhen: Jeder Container enthält ein eigenes Dateisystem und ist von anderen Containern weitgehend isoliert. Aus Sicht der Software wirkt es fast so, als wäre jeder Container ein getrennter Computer mit einem eigenen Dateisystem, einer eigener Netzwerkschnittstelle usw. Daher können in jedem Container eine eigene Programmiersprache und eigene Frameworks eingesetzt werden. Wenn man beispielsweise mit Microservices die Teile des Systems auf mehrere Container verteilt, kann ein Update auf eine neue Technologie zunächst in einem Container und dann schrittweise in anderen Containern umgesetzt werden. Das ist risikoärmer und macht die Architektur zukunftssicherer, weil die Einführung neuer Technologien einfacher wird.
Container-Technologien sind aber auch irgendwann erfunden worden: Kubernetes gibt es seit 2014, Docker seit 2013. Bis die Technologien im Mainstream angekommen sind, hat es dann noch einige Jahre gedauert. Um sie zu nutzen, muss man ältere Projekte ändern. Diese Innovationen sind nicht vorhersehbar. 2012 kann kein Architektur-Review vorhergesehen haben, dass ein Projekt nicht zukunftssicher ist, weil es keine Container nutzt.
Und eines ist auch bei Containern sicher: Es wird eine Zeit geben, in der man die Nase rümpft, wenn jemand noch Container nutzt, weil es dann eine viel bessere, neue Technologie geben wird.
Hinzu kommt: In einem Frontend mehrere JavaScript-Frameworks gemeinsam zu nutzen bleibt eine echte Herausforderung – aber die Geschwindigkeit, mit der neue JavaScript-Frameworks erscheinen, ist nach wie vor beeindruckend. Also sind diese Probleme gerade da schwer lösbar, wo neue Technologien noch mit einer viel größeren Geschwindigkeit erscheinen.
Man sollte sich also an den Gedanken gewöhnen, dass man im Moment an Lösungen arbeitet, die irgendwann technologisch veraltet sind. Und man kann das Problem höchstens abmildern, aber nicht lösen.
Die Frage nach der Zukunftssicherheit kann sogar ein Hinweis auf ein Problem sein: Wenn eine Architektur zukunftssicher wäre, müsste man sie nicht korrigieren. Das ist aber wünschenswert. Wenn Korrekturen stattdessen als Schwäche einer Architektur interpretiert und daher möglichst wenige zum Ziel werden, kann ein Problem sein. Dann können Hinweise auf eigentlich notwendige Änderungen ignoriert werden, um keine Korrekturen an der Architektur vornehmen zu müssen. Wer will schon gerne eingestehen, dass die Architektur eben nicht zukunftssicher war? Durch das Unterdrücken der Änderungen erscheint die Architektur "zukunftssicher", aber in Wirklichkeit passt die Architektur zunehmend schlechter zum System. Dass Architekturen nicht rechtzeitig an Änderungen angepasst werden, ist vermutlich eine größere Quelle für schlechte Architekturen als Probleme mit dem ursprünglichen Entwurf. So führt der Wunsch nach einer zukunftssicheren Architektur zu einer schlechteren Architektur.
Aber diese Paradoxie muss nicht der einzige Grund für ausbleibende Änderungen an der Architektur sein. Eine Architektur zu ändern ist anstrengend: Schließlich hat man sich mit dem Entwurf viel Mühe gegeben und vielleicht wesentliche Konzepte sogar schon in Prototypen ausprobiert. Von diesen ganzen Mühen Abschied zu nehmen, kann schwer fallen, ist aber manchmal nötig. Und man sollte auch kein schlechtes Gewissen haben, weil die Architektur nun obsolet ist. Softwareentwicklung ist nur in Iterationen umsetzbar. Eine Iteration der Architektur trägt die nächste schon in sich. Dennoch muss man sich bei dem Entwurf der Architektur Mühe geben. Erst wenn man wirklich versucht, die Architektur zu entwerfen, werden sich die Optimierungspotentiale zeigen.
Wenn es notwendig ist, Architekturen ändern zu können, kann die Erstellung der Architektur keine Phase in einem Projekt sein, die irgendwann abgeschlossen ist. Schließlich muss die Architektur ständig an die sich ändernde Welt angepasst werden. Dazu sollte es einen Prozess geben. Wenn es nämlich keinen Prozess für Änderungen an der Architektur gibt, wird sie vermutlich nicht angepasst werden. Dann lassen sich die Funktionalitäten zunehmend schlechter umsetzen.
Die Frage nach einem Architekturänderungsprozess ist also wichtiger als die Frage nach der Zukunftssicherheit der Architektur. Und Projekte, die auf diese Frage keine Antwort haben, setzen sich der Gefahr aus, in Zukunft Schwierigkeiten mit der Architektur zu haben.
Technologische Innovationen und neue Anforderungen machen Änderungen an der Architektur zwingend - sie kann nicht zukunftssicher sein. Lösung: Dieser Realität in die Augen sehen und Architekturen anpassen, wenn notwendig.
Vielen Dank an Gerrit Beine, Martin Eigenbrodt, Joachim Praetorius und Gernot Starke für die Kommentare zu einer früheren Version des Artikels.
URL dieses Artikels:https://www.heise.de/-6655162
Copyright © 2022 Heise Medien
Der Roboterarm Tinkerkit Braccio Robot verspricht einen kostengünstigen Einstieg in die Robotik. Lohnt sich der Kauf?
Wer sich für Elektronik und Mechanik interessiert, dürfte irgendwann auf Mechatronik und Robotik stoßen, speziell auf interessante Themen wie ferngesteuerte Fahrzeuge oder Roboterarme. Industriell nutzbare Roboterarme a la Kuka und Fanuc sind auch im Kleinformat nahezu unerschwinglich. Was also tun, wenn der Wunsch nach einem einfachen Einstieg in diese Technologie auf den Nägeln brennt? Tut es zur Not auch ein preisgünstiger Baukasten?
In diesem Blog kam das Arduino-Ökosystem schon in zahlreichen Postings zur Sprache. Viele experimentelle Robotikmodelle basieren auf Arduino-Boards. Auf dem Arduino-eigenen Shop [1] und auch woanders gibt es entsprechende Kits, darunter den Tinkerkit Braccio Arduino Robotic Arm für rund 199 € (ohne MwSt). Der Name des Roboterarms ist übrigens mit Bedacht gewählt, weil das italienische “Braccio” dem deutschen Wort “Arm” entspricht.
Der Braccio-Roboterarm besitzt sechs Bewegungsachsen und firmiert daher als 6DOF-Roboterarm (DOF = Degrees of Freedom). Einfache Daumenregel: Jeder Motor fügt in der Regel einen Freiheitgrad hinzu. Natürlich ist für diesen Preis kein Roboter zu erwarten, der viele Kilogramm in höchster Geschwindigkeit, mit vorgebener Trajektorie, und mit großer Präzision bewegen kann - die aktuelle Version kommt auf etwa 150 g Maximallast bei ausgestrecktem Arm und sonst auf bis zu 400 g.
Aber taugt ein solches Kit zumindest für den Einstieg in die Thematik?
Um diese Frage zu beantworten, habe ich den Braccio-Roboterarm von Arduino erworben. Zusätzlich benutzte ich ein Arduino-Board aus eigenen Bestand, das dem Roboterarm über das beigefügte Braccio-Shield Befehle gibt. Dieses Board sollte den Formfaktor eines Arduino Uno, Leonardo oder Mega besitzen und 5V-Logik implementieren, um das Braccio-Shield huckepack aufnehmen und steuern zu können - das Shield verbindet die verschiedenen Servos mit dem Arduino.
Maker:innen können aber auch neuere Arduino-Boards wie MKR- oder Nano-Boards verwenden. Siehe die Dokumentation zur Braccio-Bibliothek [2].
Auf den einschlägigen Verkaufsplattformen kosten Arduino-kompatible Boards ab etwa 9 Euro (Beispielsbezugsquelle [3]). Alternativ lässt sich auch das Braccio Bundle Kit erwerben, in dem für rund 219 € bereits ein Original Arduino Uno Board enthalten ist.
Dass der Baukasten aus elektronischen und mechanischen Einzelteilen sowie Gehäuseteilen besteht (siehe Abb. 1) und von seinem neuen Besitzer erst mal Bastelarbeit abverlangt, ist kein Bug sondern ein Feature. Nur dadurch lassen sich wertvolle Einblicke in die Bestandteile eines zugegebenermaßen sehr einfachen Roboterarms gewinnen.
Zudem bieten Enthusiasten ergänzende Komponenten für den Braccio auf 3D-Modell-Plattformen wie Thingiverse an.
Wer das Löten elektronischer Bauteile scheut, kann übrigens aufatmen: Nach 21 Schritten und 63 Schrauben ist die vollständige Konstruktion geschafft, ganz ohne Löten. Enthalten im Kit sind sechs Servomotoren, zwei des Typs SR 311 und vier des Typs SR 431 mit höherem Drehmoment.
Für den Zusammenbau des Braccio ist das notwendige Werkzeug - ein Philips Schraubenzieher und ein Maulschlüssel - im Kit enthalten, zumindest theoretisch. Der normalerweise enthaltene kleine Maulschlüssel fehlte in meinem Kit. Wer sich vorab Details der Montage zu Gemüte führen möchte, findet die Bauanleitung zum Beispiel hier [4]. Alternativ existiert ein 17-minütiges YouTube-Video [5], das alle Aufbauschritte illustriert. Nicht zu vergessen die Braccio-Dokumentation auf dem Arduino Web [6].
In etwa zwei bis maximal drei Stunden Arbeit lässt sich der Braccio sorgfältig und gemütlich zusammenbauen, wofür sich zum Beispiel ein verregneter Sonntagnachmittag anbietet. Das Endergebnis ist in Abb. 2a und 2b zu sehen.
Wenn einige Teile übrig bleiben, besteht kein Grund zur Panik. Im Kit sind ein paar Ersatzteile vorhanden, speziell für die Teile, die leicht verloren gehen könnten oder Verschleiß ausgesetzt sind.
Was ich als wenig optimal empfinde, ist die sehr leichte Basis des Braccio in Gestalt eines kleinen quadratischen Holzbrettchens. Diese Konstruktion macht den Braccio instabil, wodurch er zum Kippen neigt. Das Anschrauben des Arms auf eine Tischplatte dürfte nur für die wenigsten in Frage kommen. Als Gegenmaßnahme bietet es sich an, entweder ein größeres Holz- oder Aluminiumbrett oder eine verstärkte Basis mit integriertem Gewicht zu bauen. Für letztere Option gibt es auf Thingiverse ein entsprechendes Fundament zum Selbstdrucken [7]. In dieses Fundament lässt sich ein passendes Gewicht integrieren.
Wer aus dem Greifer eine besser zupackende, zangenförmige Hand machen möchte, findet auch hierzu ein passendes 3D-Modell [8]auf Thingiverse.
Für die nachfolgenden Beispiele habe ich einen Arduino Mega-Klone eingesetzt, da dieser mehr Schnittstellen besitzt, sollte man beziehungsweise frau den Braccio später durch eigene Zusatzkomponenten ergänzen wollen. Die bereits erwähnte Braccio-Dokumentation auf arduino.cc bietet hier einige Anregungen.
Entsprechende Arduino-Sketches funktionieren natürlich auch mit einem Arduino Uno oder Leonardo. Sitzt das Braccio-Shield erst mal auf dem auserwählten Arduino-Board, kann die Programmierung beginnen.
Dafür lassen sich diverse IDEs nutzen, darunter Visual Studio Code plus PlatformIO-Addin oder die gute alte Arduino IDE.
Apropos gut und alt: Empfehlenswert ist zwar der Einsatz der aktuellen und überarbeiteten Arduino IDE 2.0. Wer wie ich aber noch eine Version der “klassischen” Arduino IDE auf einem Computer (mit Linux, Windows oder macOS) installiert hat, kann auch diese nutzen.
Nach Start der Arduino-IDE führt der erste Schritt zur Bibliotheksverwaltung. Für die Suche nach der passenden Bibliothek genügt der Begriff “Braccio”, worauf besagte Bibliothek in der Trefferliste erscheint. Ein Klick auf Install genügt und schon installiert die IDE die Braccio-Bibliothek und, sofern noch nicht vorhanden, auch die benötigte Servo-Bibliothek als Abhängigkeit erstgenannter Bibliothek.
Neben der Bibliothek stellt die Arduino-IDE auch die zusätzlich enthaltenen Programmbeispiele zur Verfügung. Insgesamt gibt es davon fünf. Empfehlenswert ist zuallererst die Ausführung des Sketches testBraccio90.
Nach der Initialisierung des Roboterarms, worauf dieser eine Initialposition einnimmt, vollführt der Braccio zunächst einen höflichen Knicks, um abschließend mit nach oben ausgestrecktem Arm zu verweilen. Dadurch können Maker testen, ob sie den Braccio und insbesondere dessen Servos richtig zusammen geschraubt haben.
Der Arduino-Sketch inkludiert zunächst die Header-Dateien für die Braccio- und die Servo-Bibliothek, um danach für alle Servos von base (Basis) bis gripper (Greifer) eine Variable zu definieren.
#include <Braccio.h>
#include <Servo.h>Servo base;
Servo shoulder;
Servo elbow;
Servo wrist_rot;
Servo wrist_ver;
Servo gripper;
Die Methode Braccio.begin() initialisiert die Bibliothek und bewegt alle Servo-Motoren auf initiale Positionen. Die Basis dreht sich auf 90°, die Schulter auf 45°, der Ellbogen ebenso wie das vertikale Handgelenk auf 180°, das Handgelenk selbst rotiert auf 90°, der Greifer auf 10°. Für den Greifer bedeuten 10° eine geöffnete, 73° hingegen eine geschlossene Haltung.
void setup() {
Braccio.begin();
}
In der Dauerschleife loop gibt es nur einen Befehl: Braccio.ServoMovement(delay, M1, M2, M3, M4, M5, M6);
Dieser bewegt die Servomotoren (M1 … M6) auf die angegebenen Winkel, wobei zwischen der abgeschlossenen Bewegung eines Servomotors bis zum Start des nächsten Servomotors eine Pause von delay (in Millisekunden!) einzuhalten ist:
void loop() {
Braccio.ServoMovement(20, 90, 90, 90, 90, 90, 73);
}
Mehr als die öffentlichen Methoden begin() und ServoMovement() existieren in der Bibliothek nicht.
Darüber hinaus gibt es weitere Open-Source-Bibliotheken zur Ansteuerung des Braccio. So hat Lukas Severinghaus die Bibliothek BraccioV2 [9]entworfen, die zusätzliche Funktionalität bietet, sich aber auf die aktuelleren Braccio-Kits mit mindestens Version 4 des Braccio-Shield beschränkt. Zum Beispiel gibt es dort Routinen zur Kalibrierung der Gelenke (Min-, Max-, Mittelposition) und Funktionen für die relative Bewegung des Roboterarms.
Der Braccio-Roboterarm gehört zu den Vertretern der Open Source Hardware. Seine CAD-Dateien stehen auf einer Webseite zum Herunterladen [10] zur Verfügung. Interessenten können daher selbst Hand anlegen, also etwa robustere Teile bauen, das Modell skalieren, leistungsstärkere Motoren integrieren, und einen eigenen Braccio de la casa entwerfen.
Auf den bekannten Seiten mit 3D-Druckmodellen lassen sich wie bereits erwähnt weitere Perlen aufspüren. Der bekannte YouTuber 3D Printing Professor hat einen Controller entworfen (siehe hier [11]), der die Bedienung des Braccio über zwei Mini-Joysticks ermöglicht. Die Mathematik für die Steuerung aller Mittelmotoren bezüglich der Y-Achse implementiert dabei ein Arduino Sketch.
Will Stedden beschreibt auf seiner Webseite [12] eine Simulation des Braccio mit ROS MoveIt [13] und dem Physiksimulator Gazebo [14]. Der Quellcode hierzu findet sich auf GitHub [15]. Interessant in dem kleinen Artikel finde ich vor allem, dass Will Stedden auch auf Einschränkungen des Braccio eingeht, etwa „wie lässt sich der Braccio-Roboterarm genau auf eine Position x bewegen“, was sich durchaus als nichttrivial erweist.
Das Braccio Tinkerkit bietet einen Roboterarm für Maker, dessen Aufbau und Programmierung eine ganze Menge Spaß macht. Damit lassen sich einige Grundlagen über solche Arme erlernen, speziell über die koordinierte Ansteuerung von (Servo-)Motoren per Microcontroller. Natürlich ersetzt ein solcher Baukasten nicht das Erlernen von mathematischen und physikalischen Grundlagen der Robotik. Spätestens, wenn Maker:innen einen Roboterarm mit herausfordernderen Eigenschaften entwickeln möchten, dessen Abläufe eine genaue vorherige Planung benötigen, bedarf es eines ingenieurmäßigen Vorgehens sowie leistungsstärkerer Materialien und Motoren. Aber dafür sind Roboterarme für wenige Hundert Euro auch nicht gedacht. Die gehören eher zum Edutainment und sind dementsprechend als Spielzeuge mit Lerncharakter zu betrachten.
Natürlich ist der Braccio nur ein Beispiel. Wer jetzt auf den Geschmack gekommen ist und sich für 3D Druck begeistert, findet auf Thingiverse komplette Projekte für Roboterarme zum Nachdrucken beziehungsweise Nachbauen, etwa:
URL dieses Artikels:https://www.heise.de/-6541231
Links in diesem Artikel:[1] https://arduino.cc[2] https://www.arduino.cc/reference/en/libraries/braccio/[3] https://amzn.to/35jdWk8[4] https://content.arduino.cc/assets/Braccio%20Quick%20Start%20Guide.pdf?_gl=1*fkmn5l*_ga*NjgzNTc5OTIyLjE2NDU1MjY2NjA.*_ga_NEXN8H46L5*MTY0NTY0NTU1Ni40LjAuMTY0NTY0NTU1Ni4w[5] https://youtu.be/Lwb2ppat_bs[6] https://docs.arduino.cc/retired/getting-started-guides/Braccio#assembly[7] https://www.thingiverse.com/thing:3854294[8] https://www.thingiverse.com/thing:4764542[9] https://www.arduinolibraries.info/libraries/braccio-v2[10] https://bit.ly/3HdBeF8[11] https://www.prusaprinters.org/prints/88418-electroblok-tinkerkit-braccio-robotic-arm-mount[12] https://bonkerfield.org/2020/08/braccio-moveit-gazebo[13] https://moveit.ros.org/[14] http://gazebosim.org/[15] https://github.com/lots-of-things/braccio_moveit_gazebo[16] https://www.thingiverse.com/thing:1454048[17] https://www.thingiverse.com/thing:1693444[18] https://www.thingiverse.com/thing:1629341[19] https://www.amazon.de/Grundlagen-Robotik-Helmut-Maier/dp/3800750708/ref=sr_1_3?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=1MZ7EA7KEXFQX&keywords=robotik&qid=1646661462&rnid=1703609031&s=books&sprefix=robotik%2Caps%2C91&sr=1-3[20] https://link.springer.com/chapter/10.1007/978-1-4302-6838-3_11[21] https://www.theseus.fi/bitstream/handle/10024/93755/Theory%20of%20Robotics%20Arm%20Control%20with%20PLC.pdf;jsessionid=9F3709A4A8DA71C8A80FE0643BF4F1F7?sequence=1
Copyright © 2022 Heise Medien
A few highlights:
Detailed tracked changes.
Full changelog:
:newest updated to PHP 8.1.1 and Apache 2.4.52 #3666latest tag to git #4135Micro-Frontends sind Benutzeroberflächen, die sich aus kleinen isolierten Anwendungen zusammensetzen. Implementieren kann man sie zum Beispiel mit Web Components.
Es handelt sich um die Übertragung des Microservice-Konzepts aus dem Backendbereich auf das Frontend: Größere Anwendungen werden in kleinere, besser zu implementierende und zu wartende Unteranwendungen zerlegt. Entwickler können dabei die Sprachen und Frameworks wählen, die zu ihnen und dem konkreten Anwendungsfall passen. Web Components sind ein möglicher Ansatz zur Implementierung solcher Micro-Frontends.
Es gibt viele Möglichkeiten, Micro-Frontends zu bauen: Unter anderem können Inline Frames (IFrames) eingesetzt werden, in denen unterschiedliche Single-Page-Apps ausgeführt werden. Über jeweils zu implementierende Kommunikationsschichten können diese miteinander Daten austauschen. Die Module Federation in Webpack 5 erlaubt das Nachladen von fremdem Programmcode zur Laufzeit, um dasselbe Ziel zu erreichen – hier nicht in unterschiedlichen Frames, sondern in ein und demselben Browsingkontext. Ganz ähnlich verhält es sich mit Web Components, mit denen sich dieser Artikel beschäftigt.
Web Components [1] sind das eingebaute Komponentenmodell des Web. Entwickler können dabei eigene HTML-Elemente definieren und deren Aussehen sowie Verhalten selbst steuern. Die Technologie ist noch verhältnismäßig neu, funktioniert aber in den vier Evergreen-Browsern Chrome, Edge, Firefox und Safari seit längerem.
Der Datenaustausch erfolgt über benutzerdefinierte DOM-Attribute bzw. -Eigenschaften sowie -Ereignisse, auf der Komponente können auch eigene JavaScript-Methoden definiert werden, das Theming der Komponenten ist dabei über CSS Custom Properties möglich.
Web Components lassen sich mit Plain JavaScript schreiben, es gibt jedoch auch Bibliotheken wie Lit, die das Verfassen solcher Elemente noch einmal deutlich vereinfachen. Weiterhin erlauben auch Frameworks wie Angular (Angular Elements) oder Stencil das Verfassen eigener Web Components. Entwickler können hier einfach einen passenden Unterbau aussuchen, die Komponenten lassen sich anschließend problemlos miteinander kombinieren.
Web Components werden zur Laufzeit durch den Verwender registriert, damit ist auch ein Nachladen beliebiger Komponenten während der Ausführung möglich. Es gilt jedoch zu bedenken , dass der hierfür erforderliche JavaScript-Code innerhalb des eigenen JS-Kontextes ausgeführt wird. Einmal geladen kann der fremde Code etwa den Local Storage oder auch Cookies auslesen, wenn sie für JavaScript sichtbar sind. Wenn dies vermieden werden soll, bieten sich die oben genannten IFrame-Ansätze an.
Vor wenigen Monaten habe ich hier auf dem ÜberKreuz-Blog meinen webbasierten Remake von Microsoft Paint [2] vorgestellt. Es handelt sich dabei um eine Progressive Web App, die komplett alleinstehend betrieben werden kann. Die Anwendung ist zugleich jedoch eine Web Component und kann somit auch in beliebige andere Anwendungen eingebettet werden. Die Paint-Web-Component steht unter dem Paket @christianliebel/paint [3] auf npmjs.org zur Verfügung.
Viele Softwarehersteller setzen Design Systems ein, die Steuerelemente in der eigenen Corporate Identity enthalten. Adobe hat sein Design System namens Spectrum mit Web Components realisiert und quelloffen zur Verfügung gestellt. Unter anderem kommen diese Komponenten beim jüngst eingeführten Photoshop Web [4] zum Einsatz. Zur einfachen Demonstration des Ansatzes wird der Titel des aktuell bearbeiteten Dokuments der Paint-App auf einen Spectrum-Button geschrieben:
<html>
<body>
<paint-app style="width: 600px; height: 480px;"></paint-app>
<sp-theme scale="large" color="dark"><sp-button></sp-button></sp-theme>
<script
src="https://unpkg.com/@christianliebel/paint/dist/elements/index.js"
type="module"></script>
<script
src="https://jspm.dev/@spectrum-web-components/bundle/elements.js"
type="module"></script>
<script>
const paintApp = document.querySelector('paint-app');
const button = document.querySelector('sp-button');
paintApp.addEventListener('titlechange',
evt => button.innerText = evt.detail.title);
</script>
Um zu wissen, welche benutzerdefinierten HTML-Elemente von Drittanbieterpaketen zur Verfügung gestellt werden, gibt es das sogenannte Custom Element Manifest. Es zählt alle Web Components mit den verfügbaren Attributen, Eigenschaften, Ereignissen und CSS-Variablen auf. Für manche Umgebungen gibt es auch Generatoren, um die Manifest-Datei automatisiert erstellen zu lassen.
{
"version": 2,
"tags": [
{
"name": "paint-app",
"description": "An open-source, Web Components-based remake" +
"of MS Paint using modern web capabilities.",
"properties": [],
"events": [
{
"name": "titlechange",
"description": "The titlechange event fires whenever" +
"the document's title changes, for example, " +
"when a document is saved with a new name," +
"or a document was opened from the file system.",
"type": "{ title: string }"
}
],
"slots": [],
"cssProperties": []
}
]
}
Bei Micro-Frontends ergibt sich das Problem, dass eigentlich unabhängige Anwendungen integriert werden müssen. Eventuell gibt es Versionsabhängigkeiten zwischen den Einzelanwendungen, die erfüllt werden müssen. Ist das nicht möglich, funktioniert auch die Gesamtanwendung nicht. Komponentenmarktplätze wie npmjs.org haben sich dieser Problematik durch das Konzept der semantischen Versionierung genähert. Hier ergibt sich durch die Versionsnummer, ob bei einem Update Breaking Changes zu erwarten sind. Ein weiterer Ansatz besteht darin, Schnittstellen dauerhaft abwärtskompatibel zu gestalten. Die Win32-API oder die Web-Plattform sind gute Beispiele hierfür, allerdings bedarf es hierfür passender organisatorischen Strukturen, um dieses Ziel einzuhalten.
Speziell auf Web Components bezogen lassen sich Custom Elements derzeit nur genau einmal registrieren. Mehrere Komponentenversionen nebeneinander ließen sich also nur durch versionierte Komponentennamen (z.B. <my-button-2>) realisieren – ein Antipattern. Die spätere Neuregistrierung einer Web Component, etwa um zur Laufzeit geänderte Versionsabhängigkeiten zu erfüllen, ist nicht möglich. Abhilfe soll hier die Scoped Custom Element Registry [5] schaffen, die bei der Web Platform Incubator Community Group (WICG) vorgeschlagen wurde. Damit ist eine Komponentenregistrierung in untergeordneten Anwendungsscopes möglich. Ein Polyfill ist verfügbar, implementiert ist das Konzept bislang aber in keinem Browser.
Aufgrund der vielen Schnittgrenzen kann der Micro-Frontend-Ansatz schließlich selbst zum Problem werden: Typische Anforderungen, die den Einsatz von Micro-Frontends bedingen, sind hochmodulare Umgebungen mit mehreren Zielanwendungen oder Apps, die von mehreren organisatorisch getrennten Teams mit unterschiedlichen Vorerfahrungen zeitgleich entwickelt werden sollen. Liegt das nicht vor, sind Entwickler mit einem durch passende Architekturmittel gut strukturierten Monolithen eventuell besser aufgehoben.
Wenn wirklich ein Micro-Frontend-Ansatz gebraucht wird, stellen Web Components eine gute Option zur Umsetzung dar. Da sie im selben JavaScript-Kontext ausgeführt werden, sollten nur eigene Komponenten verwendet werden oder nur solche, deren Hersteller vertraut wird. Dann können unterschiedliche Entwicklerteams gleichzeitig unter Zuhilfenahme unterschiedlichster Frameworks eine oder mehrere Anwendungen entwickeln.
URL dieses Artikels:https://www.heise.de/-6328145
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Single-Page-Applications-ohne-Framework-Web-Components-als-Ersatz-fuer-React-Co-4850959.html[2] https://www.heise.de/developer/artikel/paint-js-org-MS-Paint-Remake-als-PWA-mit-Web-Components-und-modernen-Web-Capabilities-6058723.html[3] https://www.npmjs.com/package/@christianliebel/paint[4] https://www.heise.de/developer/artikel/Analyse-Photoshop-jetzt-als-Webanwendung-verfuegbar-6229321.html[5] https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Scoped-Custom-Element-Registries.md
Copyright © 2022 Heise Medien
Im Dezember 2021 sorgte die Sicherheitslücke Log4Shell in dem Logging-Framework Log4j für Java für Aufregung, die vom BSI als kritisch eingeschätzt und auf Warnstufe Rot eingestuft wurde. Nachdem sich der Staub inzwischen gelegt hat, ist es an der Zeit für einen Review: Was lässt sich aus alldem lernen?
Log4j ist praktisch der De-Facto-Standard für Logging in Java. Dennoch handelt es sich bei dem Framework lediglich um ein Werkzeug für Logging, ein Thema, das eher unspektakulär und wenig aufregend klingt. Doch trotzdem (oder vielleicht auch gerade deshalb) verbarg sich in dem Modul eine eklatante Sicherheitslücke, deren Details im CVE 2021-44228 näher beschrieben werden.
Über die technischen Details der Sicherheitslücke, das Angriffsszenario und Strategien zum Schließen der Lücke wurde in den vergangenen Wochen sehr viel berichtet, weshalb es wenig sinnvoll ist, das alles noch einmal zu wiederholen.
Doch es stellen sich darüber hinaus Fragen, die bislang nur wenig diskutiert worden sind, die aber mehr Aufmerksamkeit verdient hätten. Dazu zählt zum einen, welche Ursachen und Gründe es für dieses Problem gibt, wie die ganze Situation überhaupt entstehen konnte, was sie begünstigt hat. Das ist die Frage nach dem "warum". Zum anderen stellt sich die Frage, was sich daraus lernen lässt: Wie lässt sich ein derartiges Fiasko zukünftig verhindern?
Dafür gibt es technische, vor allem aber auch kulturelle und gesellschaftliche Gründe. Der kulturelle Grund ist, dass Java an sich Komplexität fördert. Einfache Lösungen werden nicht favorisiert, sondern es wird auf Komplexität gebaut – und die Log4Shell-Thematik ist das Ergebnis überbordender Komplexität, die nicht mehr zu überblicken oder gar zu meistern ist. Das hat Kristian Köhntopp vor einigen Wochen auch in seinem hervorragenden Kommentar zu Log4j: Es funktioniert wie spezifiziert [1] beschrieben.
Der gesellschaftliche Grund ist, dass zwar faktisch alle Unternehmen sich bei Open Source bedienen und davon abhängen, im Gegenzug aber kaum ein Unternehmen bereit ist, auch etwas beizusteuern oder zurückzugeben. Lizenzen wie AGPL & Co., die die eigentlich viel ehrlicheren Open-Source-Lizenzen sind, weil sie nicht nur Rechte einräumen, sondern auch Pflichten einfordern, werden von nahezu allen Unternehmen als Ausschlusskriterium behandelt, und stattdessen lieber auf die bequemen Alternativen MIT & Co. gesetzt. Und warum?
Weil es zumindest kurzfristig weniger kostet: Weniger Zeit und vor allem weniger Geld. Aber das ist eben nur eine kurzfristig erfolgreiche Strategie. Langfristig wird dieser Ansatz schiefgehen, und genau das ist jetzt mit Log4Shell eindrucksvoll passiert. Doch auch jetzt ist es einfacher, auf Open Source und die Entwicklerinnen und Entwickler dahinter zu schimpfen als sich proaktiv für ein nachhaltiges Modell einzusetzen, das Open Source für alle Beteiligten zum Vorteil werden lässt – nicht nur für die Verwender, sondern auch für die Menschen, die Open Source entwickeln.
An diesem Missstand muss sich dringend etwas ändern. Was wir als IT-Branche benötigen, ist ein tragfähiges Geschäftsmodell für nachhaltige Open-Source-Software. Und wir als Entwicklerinnen und Entwickler von Open Source müssen aufhören, unsere Zeit zu verschenken, als sei sie nichts wert.
Nur dann haben wir eine Chance, dass Open Source ein langfristig erfolgreiches und zugleich auch faires Modell werden kann, das nicht einseitig die belastet, die den Erfolg von Open Source erst ermöglichen.
URL dieses Artikels:https://www.heise.de/-6317678
Links in diesem Artikel:[1] https://www.heise.de/meinung/Kommentar-zu-log4j-Es-funktioniert-wie-spezifiziert-6294476.html
Copyright © 2022 Heise Medien
Detailed tracked changes.
Full changelog:
!pubdate:P3d) #4092e:1639310674957894 or multiple entry IDs (or): e:1639310674957894,1639310674957893
