Warum Atari ST?

[MacroDX]

Hab ich noch, nutze ich aber im moment nicht.
C-Lab Polyframe und Synthworks für Proteus, SY77, K1, M1, DX/TX.

Also falls du mal zu dem Schluß kommst die nicht mehr zu benötigen darfst du mir gerne Bescheid sagen

 

[MacroDX]

Gibt es da einen Test den man machen kann, um zu sehen ob der Weg durch die Schichten, der heutigen Abstraktionen, nicht doch schnell genug ist, damit das alles nicht wirklich in Gewicht fällt, bei der sehr langsamen Geschwindigkeit von MIDI?

EIne Möglichkeit: Nimm dir einen Sampler oder Synthesizer, mit dem du einen möglichst kurzen Puls erzeugen kannst. Dann spiel den mit jeweil Atari und PC möglichst schnell an. Das ganze nimmst du als Audiofiles auf und vergleichst dann die beiden Files, also die Äbstände zwischen den Pulsen.

 

[micromoog]

Die Impulse in sich werden im Abstand nicht größer, nur der Offset, da fehlt dann der Bezug zu einer Referenz,
Evtl. schwanken die Abstände etwas im Abstand („eiern“).

 

[MacroDX]

Evtl. schwanken die Abstände etwas im Abstand („eiern“).

Im Wesentlichen gings mir genau darum. Als Bezug würde ich dann jeweils den ersten Puls nehmen.

 

[renewerk]

Die Impulse in sich werden im Abstand nicht größer, nur der Offset, da fehlt dann der Bezug zu einer Referenz,
Evtl. schwanken die Abstände etwas im Abstand („eiern“).

Bei meinem 2box E-drumset habe ich Audio & Midi in Cubase gleichzeitig eingespielt, Die 5ms Latenz des Audiointerface angepasst und dann den Impact Start Punkt der High Hat bei beiden Spuren (Midi & Audio) über 10 Minuten immer wieder verglichen und auch gemerkt, dass die Schwankungen im Timing nicht konstant sind. Die Möglichkeiten bei Cubase, die Spur im Timing + - anzupassen bringt daher nichts. Ich werde, sobald ich wieder fit bin und das Kabel habe das AMT8 über Seriell über RS422 anschließen und den Versuch wiederholen.

 

[Rsdr]

Also hat man bei PC ein Jitter und bei Atari nicht? Aber beim Atari muss man dann darauf achten auf welcher Midispur man ein genaues Timing haben möchte, da nicht jede Spur gleichberechtigt ist?

 

[micromoog]

Jein, wie @microbug schon schrieb wird im Atari relativ zügig mit der Hardware „kommuniziert“ während im PC die Daten erstmal durch „diverse Paketzentren“ geschickt werden. „Böse“ ausgedrückt „Kurier“ vs. „Hermes“.

Sorry Dietmar wenn sich dir in der „blumigen“ Ausdrucksweise die Haare sträuben sollten

Zum Thema Spurbelegung: Betrifft eigentlich nur Notator/Creator, dort haben die Spuren nach Reihenfolge Vorrang,1 zuerst - 16 als letzte, bei Cubase wurde das nicht festgestellt.

Das "Dilemma" ist halt das serielle Midi selbst. Wenn ich Spur 16 vorziehe, kann es je nach Auslastung des gesamten Patterninhalts passieren, dass Spur 16 sichtbar vorne sitzt. Das kann man sich so vorstellen: Alles Daten warten in der (nennen wir es) "Economy-Line" in der Midi Warteschlange. Die Daten von Spur 16 wären somit als letzter dran. Durch das Vorziehen "überholen" die Daten auf der -nennen wir sie - "VIP-Line", d.h. sie kommen ggf. nicht gleichzeitig mit Spur 1, 2 ... sonder noch vor Spur 1 etc.

Aber alles heißer gekocht als gegessen, ein Großteil der POP/Dance/Elektronik-Musik wurde genau mit diesen MIDI Unzulänglichkeiten seit dem letzten Drittel der 80er produziert. Hat so gut wie keinen gestört.

 

[Rsdr]

Das Prinzip ist mir klar. Aber bei der lächerlichen Geschwindigkeit von MIDI sollte sich USB und alle Schichten des OS zu Tode langweilen. Ist schon richtig dass Windows keine Echtzeit garantieren kann, aber für MIDI sollte das doch alles wirklich sowas von locker reichen.

 

[Klaus P Rausch]

Zum Thema Spurbelegung: Betrifft eigentlich nur Notator/Creator, dort haben die Spuren nach Reihenfolge Vorrang,1 zuerst - 16 als letzte, bei Cubase wurde das nicht festgestellt.

...

Aber alles heißer gekocht als gegessen, ein Großteil der POP/Dance/Elektronik-Musik wurde genau mit diesen MIDI Unzulänglichkeiten seit dem letzten Drittel der 80er produziert. Hat so gut wie keinen gestört.

So ist es, außer:

Das Thema taucht überhaupt nur dann auf, wenn man alle Spuren bespielt - und die vor allem hart quantisiert auf 8tel oder 16tel.

Wer stattdessen ohne Quantisierung aufnimmt, merkt allenfalls, dass er selber keinen gescheiten Groove drauf hat oder hier und dort mal schlechtes Timing. Muss man halt solange üben, bis es hinhaut.

 

[waveformer]

Spaß^^

Geht unitor + log3 eigentlich auch mit cubase oder nur mit notator?

Unitor geht auch mit Cubase. Log3 weiss ich nicht, glaube eher nicht.

 

[microbug]

Das "Dilemma" ist halt das serielle Midi selbst. Wenn ich Spur 16 vorziehe, kann es je nach Auslastung des gesamten Patterninhalts passieren, dass Spur 16 sichtbar vorne sitzt. Das kann man sich so vorstellen: Alles Daten warten in der (nennen wir es) "Economy-Line" in der Midi Warteschlange. Die Daten von Spur 16 wären somit als letzter dran. Durch das Vorziehen "überholen" die Daten auf der -nennen wir sie - "VIP-Line", d.h. sie kommen ggf. nicht gleichzeitig mit Spur 1, 2 ... sonder noch vor Spur 1 etc.

Beim Atari ging das ja noch, vor allem durch den Direktzugriff auf die Hardwareports und die Expander am ROM-Port, ebenso bei den PC-Steckkarten bzw Gameport-basierten Interfaces.

Als allerdings die ersten externen Multiport-Interfaces mit seriellen und Parallelen Ports aufkamen, hätte man das Problem des Zeitversatzes zwischen den Ports, daher erfand man die Technik des Hardware-Timestampings. Diese überträgt die Daten vorher ans Interface und versieht sie mit einem Zeitstempel für die Ausgabe, was dann Intelligenz und Speicher in den Interfaces erforderlich machte und den Preis dieser Teile nach oben schraubte. Bei Emagic nannte sich die Technik AMT, bei MOTU MTS und bei Steinberg habe ich den Namen vergessen, war wohl angeblich sogar eine Waldorf-Entwicklung?

Das Prinzip ist mir klar. Aber bei der lächerlichen Geschwindigkeit von MIDI sollte sich USB und alle Schichten des OS zu Tode langweilen. Ist schon richtig dass Windows keine Echtzeit garantieren kann, aber für MIDI sollte das doch alles wirklich sowas von locker reichen.

Mit Windows hat das weniger zu tun als mit USB selbst, denn USB ist nicht echtzeitfähig, eil es immer die CPU braucht, FireWire schon, weil es DMA kann. USB hat zudem eine Blockstruktur, d.h. Es wird erst der Block gefüllt und dann gesendet, während MIDI jedes Byte sofort sendet. Könnte man theoretisch im Treiber umgehen, macht nur keiner, bzw. hat Roland wohl bei einem Interface mal gemacht. Angeblich wäre es sogar einfacher, so Daten wie MIDI Clock direkt durchzureichen, macht nur irgendwie keiner. Genau das ist auch der Grund, warum man aus einer DAW über USB niemals eine stabile MIDI Clock bekommt.

Unitor geht auch mit Cubase. Log3 weiss ich nicht, glaube eher nicht.

LOG3 war in erster Linie für den Falcon gebaut worden, weil Atari am ROM-Port zwei vorher getrennte Leitungen zusammengeführt hat, läuft aber auch am normalen ST, die Ports selbst sollten aber auch mit Cubase gehen, weil kompatibel zum früheren Unitor II, allerdings gibt es einen Port mehr als beim Unitor II, und ob der angesprochen werden kann, weiß ich nimmer.

 

[Rsdr]

Mit Windows hat das weniger zu tun als mit USB selbst, denn USB ist nicht echtzeitfähig, eil es immer die CPU braucht, FireWire schon, weil es DMA kann. USB hat zudem eine Blockstruktur, d.h. Es wird erst der Block gefüllt und dann gesendet, während MIDI jedes Byte sofort sendet.

Aber die Baurate(31250 Bit/s) von MIDI lässt doch gar kein Sofort Senden zu. Auch bei direktem Ansprechen einer Seriellen Schnittstele muss immer zuerst auf das Taktsignal gewartet werden bis was gesendet wird. Das ist doch bei Midi so lahm, dass das Block Device schon längt den Buffer gefüllt hat bevor der nächste Takt kommt.

Sei mir nicht böse, ich will es nur technisch verstehen warum Audio über USB kein Problem ist, die Daten für den nächsten MIDI Takt von 31250 Bit/s aber nicht schnell genug da sein sollen bevor die nächste Flanke des Taktes die Übertragung freigibt.

 

[microbug]

Aber die Baurate(31250 Bit/s) von MIDI lässt doch gar kein Sofort Senden zu.

Was bitte hat die Baudrate mit sofortigem starten der Übertragung zu tun?

Auch bei direktem Ansprechen einer Seriellen Schnittstele muss immer zuerst auf das Taktsignal gewartet werden bis was gesendet wird. Das ist doch bei Midi so lahm, dass das Block Device schon längt den Buffer gefüllt hat bevor der nächste Takt kommt.

Schau Dir mal an, wie ein UART funktioniert, da ist das Taktsignal des Rechners bzw der Hardwareumgebung entscheidend und nicht der Sendetakt der Schnittstelle, und es gibt einen Sendepuffer.

ich will es nur technisch verstehen warum Audio über USB kein Problem ist, die Daten für den nächsten MIDI Takt von 31250 Bit/s aber nicht schnell genug da sein sollen bevor die nächste Flanke des Taktes die Übertragung freigibt.

Nochmal: USB Audio ist ein konstanter, synchroner Datenstrom, MIDI bzw anderes Serielles dagehen nicht, das sind dann einzelne Blocks.

Vielleicht kann @mink99 das mal aus Entwicklersicht kommentieren.

 

[Rsdr]

Was bitte hat die Baudrate mit sofortigem starten der Übertragung zu tun

Aber ich muss mir UART mal durchlesen wie da festgestellt wird dass Daten übernommen werden sollen.

Ah ok, alles klar das läuft asynchron, sorry für das Missverständnis meinerseits.

 

[einseinsnull]

Nochmal: USB Audio ist ein konstanter, synchroner Datenstrom, MIDI bzw anderes Serielles dagehen nicht, das sind dann einzelne Blocks.

USB MIDI gibt es aber doch gar nicht; MIDI devices werden als USB AUDIO klassifiziert.

und seriell ist USB sowieso immer.

 

[microbug]

Aber ich muss mir UART mal durchlesen wie da festgestellt wird dass Daten übernommen werden sollen.

Der UART sendet jedes Byte sofort wenn man eins ins Datenregister schreibt, kann man auch anders einstellen, wenn Hardware-Handshake im Spiel wäre wie bei RS-232/423, aber MIDI hat das nicht.

MIDI devices werden als USB AUDIO klassifiziert.

Höchstens bei Windows XP, ansonsten ist USB MIDI eine eigene (Geräte)Klasse.

 

[einseinsnull]

ich will es nur technisch verstehen warum Audio über USB kein Problem ist, die Daten für den nächsten MIDI Takt von 31250 Bit/s aber nicht schnell genug da sein sollen bevor die nächste Flanke des Taktes die Übertragung freigibt.

man vergleiche mal die taktrate der schnittstelle mit der von cubase für atari.

 

[einseinsnull]

Höchstens bei Windows XP, ansonsten ist USB MIDI eine eigene (Geräte)Klasse.

eine midi class ist mir nicht bekannt. jedenfalls bei der einführung von USB interfaces gab es das noch nicht.

allerdings dürfte es relativ egal sein, da unsere semipro/musiker interfaces ja eh nicht class compliant sind und alle ihren eigenen device treiber haben.
da kann dann also theoretisch sonstwas durchgeschickt werden, und "sonstwas" ist ja auch unumgänglich z.b. beim timestamping.

 

[einseinsnull]

hab mal nachgeschlagen... in der USB welt gibt es eine midi class... bei midi.org nicht. whatever.

 

[GeoTeknique]

Ist schon richtig dass Windows keine Echtzeit garantieren kann

Das ist nicht ausschließlich ein Problem von Windows. Seit der Einführung von UEFI gibt es faktisch keinen direkten Hardwarezugriff mehr. Alles ist abstrahiert - nicht ohne Grund.
Zum einen ist das bei Computern die am Internet hängen durchaus sinnvoll Software von Hardware zu trennen. Zum anderen wird erst so wirkliches Plug and Play geschaffen. Mir stellen sich noch heute die Nackenhaare auf, wenn ich an die alten Jumper-Zeiten der 90er und 80er mit IRQ und DMA zurückdenke. Auch Macs sind heute technisch ein und das selbe wie PCs, nämlich x86-Maschinen auf EFI-Basis, nur das OS ist anders.

Zum USB-Buffer - es wir ja permanent ein Clock-Signal gesenet, das sollte doch ausreichen um den Buffer so zu füllen, dass auch die Notenwiedergabe zeitlich hinhaut?!

Echtzeitbetriebssysteme gibt es durchaus, z.B. QNX, was in abgewandelter Form Kernkraftwerke steuert, die ja def. zeitlich hochpräzise Steuerung benötigen.

 

[microbug]

Zum USB-Buffer - es wir ja permanent ein Clock-Signal gesenet, das sollte doch ausreichen um den Buffer so zu füllen, dass auch die Notenwiedergabe zeitlich hinhaut?!

Das ist es eben, es wird nicht wie bei MIDI zeitnah, also im richtigen Zeitabstand, gesendet, sondern auf einen Schlag, wenn der Buffer voll ist. Wäre das eine konstante Verzögerung, ließe sich da ja gegensteuern, so hängt es aber vom Hintergrunddienst ab, wann dieser wieder dran ist, und das macht den Jitter aus. Man kann im Treiber allerdings die Blockstruktur auch umgehen und jedes Byte sofort senden lassen, macht aber keiner, obwohl es laut den Entwicklern von ESI sogar einfacher wäre.

Windows ist mit entsprechenden Treibern durchaus echtzeitfähig, nur sind diese halt auch aufwendiger, laut Aussage entsprechender Entwickler.

 

[Rsdr]

Ich glaube nicht dass Windows echtzeitfähig ist. Dazu müsste das OS garantiert in einer bestimmten Zeit eine Antwort generieren können und das immer ohne jegliche Ausnahme. Aber in der Thematik bin ich nicht wirklich drin.

Das mit dem Midi interssiert mich aber immer noch sehr.

 

[micromoog]

Glaube wir jammern hier alle auf sehr hohem Niveau.

wenn alles so schlecht wäre, würde keiner damit arbeiten.
Man muss halt ein wenig Disziplin im Umgang mit Midi haben, es geht da halt kein Maschinengewehrfeuer an Daten.

 

[Rsdr]

Ich denke auch nicht dass das im Alltag irgend eine Relevanz hat, die nun ein Stück Musik schlechter klingen lässt. Aber interessant finde ich schon warum USB schlechter sein soll als eine Atari ST Schnittstelle. Dazu bräuchte man mal Beispiele oder Messprotokolle.

 

[Summa]

Aber interessant finde ich schon warum USB schlechter sein soll als eine Atari ST Schnittstelle. Dazu bräuchte man mal Beispiele oder Messprotokolle.

Echt jetzt, wo es doch so viele wirklich einleuchtende Gründe dafür gibt, brauchst du noch ein Messprotokoll?

 

[Rsdr]

Ja, mich würde interessieren was das in der Praxis ausmacht. Kann mir nur schwer vorstellen, wenn ich die großen Hans Zimmer Studios oder so mit PC sehe dass die irgendein MIDI-Problem haben, was mit einem Atari ST besser zu lösen wäre. Oder meinetwegen auch der PC von Deadmaus um mal ein wenig bei rein elektronischer Musik zu bleiben.

Gibt es nicht ein einziges Beispiel, mit einem aktuellen PC und einem Atari ST, wo man dann ganz klar das Problem als solches hört oder sieht?

 

[Summa]

Kann mir nur schwer vorstellen, wenn ich die großen Hans Zimmer Studios oder so mit PC sehe dass die irgendein MIDI-Problem haben

Du meinst Mac und kein MIDI sondern zum großen Teil Software und es ist der Film der das Timing bestimmt, die Sachen müssen sich nach dem Timing des Videos richten.

 

[einseinsnull]

"kein midi" halte ich für ein wenig übertrieben. hans zimmer hat zu seinen besten zeiten alleine 10 emu sampler gehabt. die aus gutem grund 2 midi ins hatten.

 

[Rsdr]

Mac PC ist doch egal was man nutzt, auf jeden Fall USB im Vergleich zu ATARI ST MIDI

 

[Summa]

"kein midi" halte ich für ein wenig übertrieben. hans zimmer hat zu seinen besten zeiten alleine 10 emu sampler gehabt. die aus gutem grund 2 midi ins hatten.

Ob er damals auch mit 'nem USB MIDI Interface gearbeitet hat? Ich denke @Reisender geht es um den aktuellen Zustand.