Interface - UA Apollo Twin Duo USB, SPL Crimson, audient ID14?

[adrachin]

Phantomspeisung auf einem Dynamischen? Na und. Und ne, das ist hoffnungslos. Dagegen ist kein Kraut gewachsen....

 

[mjmueller]

Jetzt ists schon Ende Januar 2016 und noch immer ist das Apollo USB Twin nicht lieferbar :-(

Universal Audio Apollo Twin USB Duo​

​

 

[adrachin]

Tja, scheint nicht so einfach zu sein, ein Interface auf eine andere Schnittstelle und auch noch ein anderes OS zu transferieren. Wobei Windows sowieso immer Stiefkind war bei UAD. Ich wäre da vorsichtig. Gegebenenfalls, falls es um die DSP geht, würde auch ein Quad Satellit Firewire gehen. Zim Beispiel. Gebraucht ab 400......

 

[Telefunky]

Wobei Windows sowieso immer Stiefkind war bei UAD.

kann ich gut verstehen
die WIN APIs sind in ihrer Logik manchen Geschichten Franz Kaffkas nicht unähnlich...

cheers, Tom

 

[mjmueller]

die WIN APIs sind in ihrer Logik manchen Geschichten Franz Kaffkas nicht unähnlich...

Für den Satz hättest Du einen Preis verdient !

 

[adrachin]

Dann muß ich eine Kafkaeske Logik haben. Hatte nie Mühe mit den WIN APIs .... (;

 

[Reflex]

Wenn eine Mac-affine Firma ein Produkt für Windows herausbringt, sollte man immer sehr vorsichtig sein.
Viele kriegen das nicht gescheit gebacken.

 

[Telefunky]

Dann muß ich eine Kafkaeske Logik haben.

wenn du mit gutem Gewissen behaupten kannst, einen der hier vorgestellten Lösungsvorschläge selbstständig entwickeln zu können, dann dürfte das zutreffen
ich habe einfach den erstbesten link zu 'wpf und enumerated' auf stackoverflow.com herausgegriffen
(die vermutlich meistgefragte unabhängige website zu .net und ähnlichen Themen)

wpf steht für Windows Presentation Foundation, der Nachfolger des alten WinGDI
'enumerated' sind angeblich 'elegant' einsetzbare Datentypen - zb in Konstrukten wie 'for each' in C#
ein kompletter Schmarrn...

auch wer kein Programmierer ist darf gern mal einen Blick auf die verlinkte Seite werfen
man muss das gar nicht verstehen um die literarische Analogie unmittelbar nachvollziehen zu können...

cheers, Tom

 

[adrachin]

Na ja, das ist halt Objektorientierte Programmierung. Da sieht jeder Syntax aus wie Chinesisch von einem anderen Planeten, wenn man den Dialekt nicht kennt. Stackoverflow habe ich intensiv genutzt als ich am Wochenende mal ein Programm geschrieben habe, das aus Excel Tabellen Daten gelesen hat, diese Daten dann anhand verschiedener Kriterien über Google Suchanfragen verifiziert hat und dann wieder in Excel zurückgeschrieben hat. Ich hatte vorher weder C# verwendet noch die neue Version von Visual Studio. Aber programmiert in VBS, ebenfalls Objektorientiert. So richtig dolle schwierig fand ich das nicht. Vielleicht doch Kafkaeske Logik in meinem Kopf.... (;

Aber jetzt wieder zurück zu den Interfaces......

 

[Telefunky]

Aber jetzt wieder zurück zu den Interfaces......

genau, aber einmal muss ich noch kurz zurückblenden, weil die Aussage so symptomatisch wie charakteristisch ist:
Zitat: ...Stackoverflow habe ich intensiv genutzt als ich am Wochenende mal ein Programm geschrieben habe...
so gehen 19 von 20 'Programmierern' vor
ein Teil, weil er gar nicht durchblickt (lässt sich schon an der jeweiligen Fragestellung auf der Seite ablesen)
andere, weil sie dem Basis-Konzept geistig nicht folgen können (dazu zähle ich mich...)
die Synthax ist gar nicht das Problem - es ist die Unmöglichkeit, damit methodisch effiziente Lösungen zu formulieren
ich habe oben selbstständig nicht ohne Grund fett geschrieben

dasselbe Problem haben aber auch Anbieter, die Hardware in's System integrieren wollen
sie müssen dem geistigen Dünnschiss des grössten BS-Anbieters der Welt folgen
wenn der .net und managed code schreit, dann müssen sie springen... es gibt keine Wahl
und wird an der Oberfläche schon so gewuselt, muss man äusserst naiv sein, darunter ein solides Fundament zu vermuten

cheers, Tom

 

[mjmueller]

Aber jetzt wieder zurück zu den Interfaces......

Och nööö ... dauert doch sowieso noch (lt. großem T) bis Ende Februar, bis das Apollo lieferbar sein soll. Bis dahin folge ich gerne Eurer Diskussion ...

 

[adrachin]

bis Ende Februar

Voraussichtlich.....

selbstständig

Programmierst Du Deine Compiler selbst? Oder eventuell die Programmiersprache die Du nutzt? Die Libraries etwa auf die Du zugreifst?

dasselbe Problem haben aber auch Anbieter, die Hardware in's System integrieren wollen
sie müssen dem geistigen Dünnschiss des grössten BS-Anbieters der Welt folgen
wenn der .net und managed code schreit, dann müssen sie springen...

Es wird ja niemand gezwungen seine Programme in einer .net Programmierumgebung zu schreiben. Das kann man, muß aber nicht. Und was da an Hardware nahen Bestandteilen in Windows rumliegt ist eben Hardware nah. Das greift auf keine API zu. Das ist das interne Uhrwerk, das seine Funktionen nach außen als API darstellt. API = advanced programming interface. Das ist natürlich ganz anders gestrickt als der Rest, der auf .net aufsetzt. Und ich finde, das funktioniert ganz hervorragend. Vor allem seit es die Initiative des MS Hardware Quality Labs gibt:

https://de.wikipedia.org/wiki/Windows_Hardware_Quality_Labs

da kann jeder nachlesen, was er tun muß, um einen stabilen Treiber Code zu schreiben. Was war das früher immer für ein Geschiß mit Hardware. Irgendwas angesteckt und puff, Blue Screen. Seit der Einführung von WHQL gehört das der Vergangenheit an. Zumindest Normalsterbliche sehen das in der Regel nicht mehr. Es gibt weltweit hunderttausende von Hardware Geräten, die auch noch an hunderttausenden unterschiedlichen Kombinationen von Hardware sicher funktionieren. Ich finde, das ist schon eine enorme Leistung. Und so schlecht kann dann ja wohl der Unterbau nicht sein, wenn sowas möglich ist. Übrigens hat nicht nur MS das Problem der Myriaden an Kombinationen von Hardware. Das hat auch Linux. Die müssen und wollen auch überall funktionieren und wenn möglich auch noch abwärts kompatibel.

Apple macht es sich einfach. Die haben eine überschaubare Anzahl von Modellen und sagen irgendwann, ne, das neue OS geht mit der Steinalt Hardware nicht mehr. Wobei dann die Steinalt Hardware gerade mal 5 Jahre auf dem Buckel hat. Das ist keine große Kunst.

Um mal wieder den Bogen zum Interface zu spannen, sieh Dir mal RME an. Die können Treiber schreiben. Für MAC, und MS. Und die funktionieren. Oder Focusrite. Die haben gerade einen Thunderbolt Treiber für Windows geschrieben. Auf meinem HP Laptop funktioniert der prima. Auf einem Asus Board mit TB nicht. Und fragt man dann bei Asus an, warum nicht, dann sagen die, na ja, der ist eigentlich nur als Display Anschluß gedacht. Im Datenblatt steht aber Thunderbolt 2 kompatibel. Die haben offensichtlich die Spezifikation nicht gelesen. Und wer ist da jetzt Schuld, wenn es nicht geht? 99 von hundert würden sagen MS.....

 

[Telefunky]

Um mal wieder den Bogen zum Interface zu spannen, sieh Dir mal RME an. Die können Treiber schreiben. Für MAC, und MS. Und die funktionieren.

ja, sehr schön - aber krieg dich wieder ein... sie machen seit 20 Jahren nichts anderes
davon haben sie sich (iirc) mindestens 5 Jahre aktiv geweigert, USB überhaupt nur anzudenken
nebenbei: USB ist eins der wenigen Apple Produkte, die ich nie verstanden habe
(selbst wenn das Design von Intel ist, hat es Apple mit der ersten Generation iMacs zum Standard durchgeprügelt)

das RME Forum früherer Jahre war gespickt mit bitterböser Kritik am universellen störenden Bus
(10 Jahre und mehrere Generationen Chipsätze später sieht die Lage etwas entspannter aus...)
aber als alle mit USB Probleme hatten, war RME keineswegs die Lichtgestalt in der Not
sie haben einfach gesagt: so einen Schwachsinn unterstützen wir nicht...

wie sie auch davon abgesehen haben für bestimmte Karten kernel-streaming driver 'nachzulegen'
machen wir nicht - kauft die nächste Generation Karten - da ist das an Bord

da sollte man bei einem newcomer wie UAD vielleicht etwas nachsichtiger sein

Apple hat früher jegliche Hardware mit jedem System unterstützt - in MacOS gab es eine Komponente, die das regelte
man brauchte das nicht mal installieren
(die Kopie einer beliebigen Installation reichte - oder einfach der Einbau der 'anderen' Festplatte)
das hat den Umsatz nachhaltig geschmälert, weil die Nutzungszeiten der Systeme gegen unendlich tendierten
deswegen wurde das stufenweise verschärft bis hin zur Übernahme von Geräte-IDs in die Firmware
Apples Kundenbasis hätte nie freiwillig auf OSX gewechselt (das war bis 10.4 eine üble Baustelle)
dass Maschinen ausgegrenzt werden, ist weder Unfähigkeit noch Bequemlichkeit, sondern bewusste Entscheidung

Programmierst Du Deine Compiler selbst? Oder eventuell die Programmiersprache die Du nutzt? Die Libraries etwa auf die Du zugreifst?

Compilerbau ist nicht mein Metier
aber ich nutze heute tatsächlich grösstenteils eigene Bibliotheken und eine eigene Datenbank-Engine
(zumindest kommt das der Funktion am nächsten)
angefangen habe ich mit Oracle und dem OpenInterface Framework von NeuronData (objektorientiert/ansi-C)
die header files enthielten gleich die komplette Dokumentation (sehr praktisch), insgesamt rund 1 MB Text

wer so etwas mal gelesen hat, weiss erst auf welchem Kindergarten-Niveau in Redmond gedacht wird
das soll keine Polemik sein - es war eine Diskrepanz die dem Unterschied Vorschule-Abitursklasse entspricht
ich habe nie etwas besseres zum Thema OO-Programmierung gelesen
man konnt damit rekursive spreadsheets definieren, bei denen die Zellen aus spreadsheets bestanden
grafisch richtig schnell unterwegs und gerade mal 1,5 MB Objektcode als Runtime iirc
wohlgemerkt: das war die Zeit, in der Windows von Nummer 3.0 auf 95 wechselte

ich bin zwar (zugegeben) kein grosser Anhänger von C, habe es durch dieses System aber zu schätzen gelernt

für mich geht es in erster Linie darum, meine Ideen möglichst effizient umsetzen zu können
dann muss der Preis stimmen und der Rest ist mir egal
(ich habe meine bezahlte Lizenz für Visual Studio keineswegs nur zur Dekoration)
aber meine Erfahrungen prägen auch meinen persönlichen Massstab, deswegen nehme ich da kein Blatt vor den Mund

cheers, Tom

 

[mjmueller]

Hallo!
Jetzt ist das UA Apollo Twin Duo USB lieferbar. Und bis Ende März gibt es noch ein paar PlugIns obendrauf (zB UA610A).
Sollte ich noch was warten und erste Konsumentenfeedbacks abwarten ?

 

[adrachin]

Sollte ich noch was warten und erste Konsumentenfeedbacks abwarten ?

Lange kann das nicht dauern mit den Kommentaren. Diese Woche sollte eines im Postkasten landen. Und wenn dem so ist, wird es spätestens am Wochenende in die Mangel genommen.... (;

 

[mjmueller]

Ooooch ... ja dann warte ich noch ein wenig

 

[joeck]

und...?

Gibt es schon erste Erfahrungen mit dem USB-Twin? Ich habe offen gestanden ja Zweifel daran, dass die Performance ähnlich hoch ist wie bei dem Thunderbolt-System, lasse mich aber sehr gerne überraschen...

 

[adrachin]

Insgesamt schlägt sich das sehr gut. Es ist eben eine etwas andere Philosophie dahinter. Die Latenz durch die DAW ist mit minimal 8.7 ms im Vergleich zur den Mitbewerbern eher hoch. Minimale Puffer Größe ist 64 Samples und da kommen wohl noch ein paar extra Puffer dazu. So zeigt es zumindest die DAW:

also Monitoring durch die DAW ist eher nicht zum empfehlen. Intern im Interface sind das aber dann knapp unter 2 ms. Das ist natürlich eine Ansage für direktes Monitoring währen der Aufnahme. Insgesamt können pro Kanal 4 Plugins eingesetzt werden ohne merkliche Vergrößerung der Latenz. Mit einem Button wählt man dann, ob die Effekte an die DAW weitergeleitet werden sollen, oder nur auf das Monitoring gehen sollen.

In der DAW gibt es ein Plugin, mit der man die Plugin Belegung im Interface mit dem Projekt abspeichern kann.

In der Praxis verwendet man die DAW idealer Weise nur als Aufnahme- und Abspielgerät. Also beim Aufnehmen zusätzlicher Spuren geht es dann aus der DAW mit der Ausgangslatenz von 3.61 ms und dann auf den Ausgang, wahlweise noch durch Plugins mit kaum wahrnehmbarer Latenz. Damit kann man leben.

Was den Track Count und den Plugin Count beim Abspielen angeht, da liegt das Apollo USB fast gleichauf mit dem Clarett Thunderbolt. Im einzelnen habe ich das nicht bei allen möglichen Sampling Frequenzen und Puffer Größen ausprobiert. Für mich ist nur max Puffer relevant. Wobei dann gleichauf bedeutet, da geht nicht so viel wie mit dem Clarett. Das hat max Puffer 1024, das Apollo 2048.

Also die USB Variante kann unmöglich gleichziehen mit der Thunderbolt Variante. Technisch nicht möglich. Thunderbolt geht direkt auf den PCIe Bus währen USB das Subsystem der Soft- und Hardware passieren muss.

Trotzdem, für das kleine Recording Studio zuhause ist das eine prima Lösung. Die geringere Latenz von Thunderbolt Interfaces nutzt mir in der Praxis wenig, wenn ich alle Plugins, die ich gerne beim Aufnehmen verwenden will in die DAW pflanzen muss. Das spielt dann nicht lange mit minimaler Puffergröße und ich bin auf 0 ms Latenz Plugins angewiesen.

Portabel ist es auch. Also mal schnell unterwegs was Jammen auch an einem eher schmalbrüstigen Netbook ist kein Problem.

Die Details gefallen auch. Gummifüsse die angeschraubt sind statt geklebt. Stromanschluss mit Verriegelung. Und der fette Drehknopf für Monitor und Kopfhörer mit riesigen LED Segmenten. Damit regelt man auch den Eingangspegel und auch da stehen die LED als Rückmeldung zur Verfügung. Da kommt schon fast das Drehschalter Feeling eines Hardware Amps auf.......

 

[joeck]

Vielen Dank - das ist doch mal eine Aussage! Wenn sich das Teil nun auch noch mit dem Softube Amp-Plugin als Amp-Alternative vernümftig nutzen liesse, wäre ich wohl schon dabei, meinen Dispo zu liebkosen, aber darüber habe ich noch nichts nennenswert gutes an Meinung gefunden (über das Plugin, nicht über meinen Dispo...)

 

[adrachin]

darüber habe ich noch nichts nennenswert gutes an Meinung gefunden

Du kannst Dir die Meinung selbst bilden. Die Mehrzahl der UAD Amp Plugins sind von Softtube und brainworx. Von denen gibt es Demo Versionen. Die klingen nativ nichts anders als über DSP.....