Beiträge von robert müller

Zitat von "discodude"

Letztendlich ging es mir ja auch noch darum das alle Kanäle in irgen einer Art un Weise immer auf die jeweilige Sampling Frequenz getaktet sind.........
Jetzt kann sich doch jeder vostellen das es da irgendwo ein Veränderung des Audiosignals nach sich zieht... wiederum muss ich jetzt auch die Frage in den Raum werfen ob das nicht vieleicht im zusammenspiel von analog Komponenten nicht zu ähnlichen Effekten kommt????

Ja klar, die Wandler laufen synchron (sollten sie zumindest). Und wo genau macht diese Synchronisierung was mit dem Audiosignal?

Die zeitliche Quantisierung (also das Samplen der Amplitude alle 44100 oder 48000 oder wasauchimmer mal pro Sekunde) jedenfalls macht genau gar nix mit dem Audiosignal, so lange keine Spektralkomponenten oberhalb der Nyquist-Frequenz vorhanden sind. Jedes Signal, das dieser Bedingung genügt, läßt sich nach dem Samplevorgang wieder exakt frequenz- und phasengenau reproduzieren. Die Mathematik dazu würde hier jetzt zu weit führen (und ich kriegs aus dem Kopf ehrlich gesagt nicht mehr mathematisch exakt zusammen), aber jeder Nachrichtentechniker wird dir das bestätigen können.

Aber jetzt zurück zum eigentlichen Threadthema. Ich muß ja ehrlich zugeben - selbst ich als Skeptiker am Grundprinzip, alles (also Oberfläche, Audio-Processing und I/O) auf ein und derselben CPU zu rechnen muß sagen, daß mich die Idee fasziniert. Ich denke mal, wenn wieder ein wenig Geld für Hobbyprojekte frei ist, werd ich da auch mal nen Testballon starten (RME-Hardware ist genug da... )

Zitat von "discodude"

A ist eine nidrige Samplerate und B eine höhere. Die vertikalen Linien beschreiben die jeweiligen Abtastungen die sich aus der Samplerate ergeben.

Nun sieht man das bei A die abtastungen in einem ungünstigen verhältnis zu dem orginalen Audiosignal ( hell Blau )stehen.
Da das System immer nur den augenblicklichen zustand der Welle " sieht ergibt sich dann ein nicht korrektes Abbild ( dunkel ).
Laut den Nyquist Theorem benötigt man min die Doppelte Samplefrequenz vom orginal Signal um eine "Halbwegs" orginal getreue Aufnahme zu bekommen.

Du erwähnst hier das Nyquist-Theorem. Dann schau dir dein Bildchen mal selber nochmal an. Bei A ist nämlich genau dieses verletzt. Deswegen sieht deine Abtastung so kaputt aus. Bei einem korrekt aufgebauten AD-Umsetzer sitzt vor dem eigentlichen Wandler ja ein Tiefpaß, der die in A dargestellte Welle einfach wegfiltern würde. Würde dein Wandler tatsächlich wie in A arbeiten, wäre "Hochtonauflösung" das geringste deiner Probleme. Viel gravierender ist, daß die durch die Fehlabtastung entstehende Welle im tiefen Audiobereich liegt und vor allem absolut in keinem harmonischen Verhältnis mehr zum Originalsignal steht. Das nennt man dann Aliasing.
(Mathematisch gesehen ist das übrigens der gleiche Effekt, der auch bei feinen Strukturen auf Fotos auftritt, wenn diese ohne Antialiasing auf niedrigere Auflösungen umgerechnet werden. Wenn dann die Auflösung nicht mehr zur korrekten Darstellung der feinen Strukturen ausreicht, entstehen oft neue Muster, die im ursprünglichen Bild so gar nicht vorhanden waren.)

Die höhere Samplefrequenz kann dir einige oder alle der folgenden Dinge bringen:
- Größerer Frequenzgang (Da der Tiefpaß vorm Wandler natürlich höher liegen kann)
- Weniger Welligkeit des Tiefpaß im Hochtonbereich (Da der Tiefpaß natürlich auch so tief wie bei 44.1 liegen und dafür flacher abfallen kann) - Das ist bei modernen Wandlern aber kein so großes Problem mehr.
- Digitale Bearbeitungen (hauptsächlich EQs) können je nach Rechenverfahren anders klingen. Im Hochtonbereich ergeben sich bei einfachen digitalen EQ-Algorithmen Verzerrungen der EQ-Kurve (ich bin kein Experte dafür, aber je näher man dem Grenzbereich kommt, desto stärker wird die Kurve von oben her "gequetscht", da sie nicht über die Nyquist-Frequenz reichen kann und damit umso steiler nach oben abfallen muß, je näher man der Nyquist-Frequenz kommt.). Moderne EQ-Algorithmen korrigieren das aber mathematisch wieder. Wenn ich mich nicht irre, ist genau das auch der Unterschied bei den Yamaha-Pulten zwischen den EQs Typ I (alt) und Typ II (neu, mit Korrektur).

Hier muß man nun aber sagen, daß der Unterschied zwischen 44.1 kHz und 48 kHz im Allgemeinen vernachlässigbar ist. Es gibt wohl Wandler, die bei 48kHz anders klingen, wenn ihre Filter nicht optimal auf 44.1kHz-Betrieb eingestellt sind. Die Wandler im Behringer DDX3216 beispielsweise hab ich mal durchgemessen. Bei 44.1 ist der Phasengang alles andere als linear, bei 48kHz schnurgerade. Die ADA8000 vom gleichen Hersteller arbeiten übrigens bei beiden Sampleraten absolut korrekt in dieser Beziehung.

Wenn du nun wirklich besseren Sound aus deinen Plugins rausholen willst, macht eine Erhöhung der Samplerate auf 96kHz mehr Sinn. Ansonsten würd ichs wie WurstWerner halten: Für reine Livejobs ist die Samplerate egal, für Aufzeichnungen würd ich sie vom Zielformat (CD/DVD) abhängig machen.

Zitat von "niggles"

...bis mal das erste Toslink-Kabel (1-8) einen leichten Wackler hat. Dann ist die Aufnahme des laufenden Songs im Eimer, weil sie ein mehrere Sekunden langes "Loch" aufweist.
Die WC-Übertragung über ADAT ist im Verbund extrem fehlerintolerant. Daher empfehlen so gut wie alle Hersteller solche Setups extern zu takten...

Wenn ueber das Toslink-Kabel keine Clock mehr kommt, kommt auch kein Audio mehr. Dann hast du ein ganz anderes Problem. Insofern bringt mir die zusaetzliche Wordclock hier nicht viel, ausser, dass der Recorder auch beim Aufzeichnen der ungewollten Stille sauber getaktet ist...
Ich hab jetzt selber genug Live-Shows ueber ADAT aufgezeichnet, und Clocking war niemals auch nur ansatzweise ein Problem.

Zitat von "janos buttgereit"

d.de/ce/de/product/325125/SPEAKA-WANDLER-OPTISCH-ZU-KOAXIAL/1310121]dieses Gerät[/url] und sein Pendant wohl auch ADAT? Wär dann vielleicht auch ne Option, an so ein paar Meter Chinch Kabel sollte man ja dran kommen können.

Ich hab hier ein CO2 von M-Audio (Bidirektionaler Wandler optisch <-> coax), der mir auch problemlos ADAT nach COAX und zurück übersetzt. Hat wohl damit zu tun, daß das Gerät nicht wirklich das SPDIF-Signal dekodiert und auf der jeweils anderen Schnittstelle neu ausgibt, sondern da wohl wirklich nur das analoge Trägersignal von der einen auf die andere Schnittstelle gewandelt wird. Ich würde mal vermuten, daß die meisten günstigen Opto-Coax-Umsetzer das so machen.
Ich hab auch schon SPDIF selbst mal über größere Strecken gejagt, dazu haben wir Video-Kabel benutzt. Ich glaub bis 30m hatte ich probiert und auch produktiv im Einsatz, das ging. Ob allerdings derart umgeformtes ADAT damit funktioniert, weiß ich nicht. Immerhin ist die Datenrate bei ADAT ca. 4 mal so hoch wie bei SPDIF, insofern dürfte das nicht so tolerant sein, was die Kabellänge angeht.

Ansonsten gibts von Hear Technologies ADAT Extender, die ADAT auf CAT5 umsetzen. Kostenpunkt ca. 120EUR für ein Paar (In- und Out-Box)

Wordclock zum HD24 kannst du dir sparen. Wenn das Pult Master ist und der ADA via Wordclock auf das Pult gesynct ist, kannst du den HD24 einfach auf die optischen Eingänge synchronisieren lassen. Hab das Setup selbst schon so laufen gehabt, das funktioniert problemlos.

Ich hatte in dieser Sache Ende letztes Jahr schon ein wenig mit dem WurstWerner gePMt und mir die Demo der Software mal kurz angeguckt. Als nebenberuflich Tonschaffender, der auch mal als "CubaseKid" angefangen hat, muß ich durchaus zugeben, daß mich diese Sache irgendwo reizt. Ich hab auch schon vor knapp 2 Jahren glaub ich mal nen Bericht über nen Kerl gelesen, der ein komplettes Konzert mit Fireface und 2 ADAT-Wandlern in Logic auf nem Macbook gemischt und parallel nen Livemitschnitt gezogen hat. Prinzipiell sind das alles sehr spannende Entwicklungen für Leute wie mich, die sich das Mischen (auch) auf rechnerbasierten Systemen erarbeitet haben.

Ich hatte nun aber das Glück, in meinem Werdegang sowohl analoge wie digitale Hardwarelösungen als auch eben native Mischsysteme fürs Studio kennenzulernen, und habe einiges über die Stärken und Schwächen der Systeme gelernt. Und als mittlerweile fertig studierter Informatiker, der also auch ein bißchen weiß und versteht, wie die digitale Hard- und Software im Innern so tickt, ist mir bei sogenannten Von-Neumann-artigen Rechner-Architekturen (nichts anderes sind PCs, im Gegensatz zu so ziemlich jeder dedizierten Misch-Hardware) auf Live-Baustellen immer ein wenig unwohl. Ein der Sache inhärentes Problem können nämlich alle derzeit auf PCs laufende Mischsysteme (seis jetzt fürs Studio oder für live) nicht vollständig lösen: Kaputter Programmcode bringt das ganze System zum Absturz oder kann zumindest schwere Störungen hervorrufen. Das muß nicht die Host-Applikation sein, da reicht schon ein falsch programmiertes Plugin, das dummerweise ein paar wichtige Bytes im Speicher der Hostapplikation überschreibt. Wenn man also diese nativen Systeme benutzt, sollte man sich bei jedem verwendeten Plugin sicher sein können, daß der Hersteller bei der gerade eingesetzten Version des jeweiligen Produkts nicht irgendwas doch anders gemacht hat, als es der Entwickler der Hostapplikation sich gedacht hat. Also einfach mal das bevorzugte Hallplugin in ein beliebiges nicht von mir zusammengestelltes System (andere Hostsoftware oder andere Audio-Hardware/-Treiber) reinladen, so wie ich früher einfach meine eigenen FX mit an den FOH bringen konnte is nich. Zumindest würde ich es nicht ohne ausgiebigen Kompatibilitätstest tun. Dafür ist mir im Studio in der Richtung schon zu viel an Inkompatibilität begegnet.

Insofern verfolge ich diese Entwicklung mit Spannung und werd mir sicher auch mal ein eigenes kleines Live-Setup stricken, einfach, weil ichs spannend finde und ich normalerweise keine Rider erfüllen muß (Ich schreib höchstens welche, die dann mangels Wichtigkeit der von mir betreuten Bands ignoriert werden... ). Aber letzten Endes wird das, um wirklich praxistauglich und sicher zu werden, doch irgendwann eine darauf zugeschnittene Hardware-Architektur brauchen. Und dann laufen die PC-Plugins auch wieder nicht. Aber hey, vielleicht entwickelt ja mal jemand ne Standard-Hardware-Plattform für natives Mischen, die inhärent sicher ist (also auch Plugins verschiedener Hersteller voneinander abschottet), und jeder kann Plugins dafür entwickeln...

Gruß,
Robert

Zitat von &quot;MatzeRockt&quot;

Danke - ihr macht mir alle Mut. Meine 3 verbliebenen Weisheitszähnchen müssen nächsten Monat raus :?

Ich hab Angst.

Ich kann dich mal ein wenig beruhigen. Bei mir hat das ganze jetzt mit Sedierung knapp 1,5h gedauert. Nach Abklingen der Betäubung haben die Schmerzen erst mal tierisch genervt. Hab aber ein paar Stunden gekühlt wie mir geraten wurde und behandele jetzt teils homöopatisch und teils mit Ibu nach. Im Moment sitz ich recht gemütlich am Laptop und hab eigentlich nur dann Aua, wenn ich den Mund zu weit aufmach...

Und ich hab jetzt ein schönes Tütchen mit Trophäen hier liegen.

Was viel doofer ist: Heut morgen hab ich das Netzteil zum Laptop daheim vergessen und jetzt ist bald der Akku leer... Und Portal spielen geht nur auf Akku auch nicht lange...

Zahn-OP. So ein wildgewordener Oralchirurg reißt mit gleich 4 Weisheitszähne raus...

Ich muß hier weg...

Klar, die von dir genannten Vorteile sind nicht von der Hand zu weisen. Ich (als jemand, der das nur nebenberuflich betreibt) habe zu Hause auch lediglich einen selbst gebauten, für den Einsatzzweck Audio zugeschnittenen PC laufen (übrigens mit 2 Hammerfalls ), auf dem ein Cubase-System mit diversen Plugins rennt. Das ist ne tolle Kiste, keine Frage. Ich hab die auch ab und an live dabei, wenn ich größere Mitschnitte mache, und das ganze rennt einwandfrei.

Trotzdem ist die Softwarearchitektur Host-Anwendung mit Plugins nichts, was ich in der jetzigen Form in einem Livepult sehen möchte. So sehr ich Digitalpulte (auch und gerade für live) mag, so sehr widerstrebt mir der Gedanke an ein solches System auf einer von mir betreuten Baustelle. Das liegt einfach daran, daß zwischen Plugins und Host-Anwendung weit mehr Wechselwirkungen entstehen können, als das zwischen untereinander per Audio-Schnittstelle verbundenen Hardware-Geräten der Fall ist. Bauchweh macht mir hier vor allem folgender Sachverhalt:
Heutige PC-Betriebssysteme haben etwas, das sich Speicherschutz nennt. Das heißt, es wird genau überwacht, daß ein Prozeß nur in Speicherbereiche schreiben darf, die ihm auch gehören. Das soll verhindern, daß ein Prozeß (böswillig oder unabsichtlich durch Programmierfehler) Speicherbereiche anderer Programme verändert, was diese dann meist zum Absturz bringen würde. Das wurde nicht ohne Grund eingeführt bzw. von großen Systemen übernommen. Viele Stabilitätsprobleme der Vor-Windows-NT-Ära rühren nämlich genau daher, daß es das unter den damaligen Systemen nicht gab.
Für ein Plugin in einem Host-Programm gilt genau dieser Speicherschutz nicht. Es kann zwar nicht auf Speicherbereiche anderer Prozesse zugreifen, aber durchaus auf den kompletten Speicherbereich der Hostanwendung sowie aller darin laufenden Teile (also auch alle anderen Plugins). D. h. ein einzelnes fehlerhaft programmiertes Plugin kann die komplette Host-Software aus dem Tritt bringen.

Mal ein konkretes Beispiel:
Für eine Showproduktion haben wir mal ein recht komplexes Videosetup eingesetzt, unter anderem mit einer VJ-Software. Um dieser nun eine bestimmte Fähigkeit beizubringen, die wir zu Realisierung eines Effekts brauchten, mußte ich eigenes Mixer-Plugin schreiben. Das ist eigentlich eine leichte Aufgabe, es gibt ein SDK, das mir den kompletten Programmrumpf vorgibt, und ich muß letzten Endes nur noch die Anzahl und Art der Ein- und Ausgänge definieren sowie die Hauptroutine schreiben, die die eigentliche Rechenarbeit vornimmt. Diese wiederum tut eigentlich etwas sehr simples: Sie erhält zwei Speicherbereiche, in denen die gerade aktuellen Frames der Videoeingänge liegen, und einen weiteren Speicherbereich, in den das Resultat geschrieben werden soll. Jetzt rennt man mit einer Programmschleife über die kompletten Bereiche drüber und rechnet Pixel für Pixel das Zielbild aus. Jetzt hab ich (natürlich nur in der ersten Testversion) den berühmten Off-By-One-Fehler gemacht, sprich die Abbruchbedingung der Schleife falsch gewählt, so daß diese ein Mal zu oft ausgeführt wurde. Ein Schleifendurchlauf entsprach bei dieser Testfassung einem Bildpunkt, da 32 Bit Farbtiefe also 4 Byte. Ich hab also 4 Byte über das Ende meines Zielbereiches hinausgeschrieben. Das hat schon gelangt, daß die Hauptanwendung beim Anwählen einer bestimmten Aktion im Menü reproduzierbar einen gar spektakulären Crash hingelegt hat. 4 Byte!
Wenn ich mir jetzt vorstelle, ich hab ein System aus einer Hand, da kann ich davon ausgehen, daß der Hersteller das gut getestet und alle möglichen und unmöglichen Konstellationen durchprobiert hat. (Und selbst das reicht nicht immer, wie wir alle sehr gut wissen.)
Bei einem offenen System in der heutigen Bauweise muß ich *allen* Herstellern, die da irgendwas in meinem Pult laufen haben, vertrauen, daß nur ja keiner Bockmist gebaut hat. Vor allem, ob es auch aufgefallen ist. Um beim obigen Beispiel zu bleiben: In einer anderen Hostanwendung hätte es sein können, daß in den von mir überschriebenen 4 Bytes etwas völlig harmloses liegt, z. B. ein anderer Bildpuffer. Da wäre dann irgendwo ein Pixel etwas anders gewesen als erwartet, das wäre beim Testen sicher niemandem wirklich aufgefallen. Dann laden wir das Ganze in die Hostanwendung, bei der dort was kritisches liegt, und *bam* fliegt mir der Laden um die Ohren.

Deswegen bleibe ich dabei - nativ sehe ich noch lange nicht. Mag sein, daß da was am Kommen ist, über das du besser informiert bist als ich, aber ob das sich auf Anhieb durchsetzen wird? Damit das wirklich stabil wird, müssen solche gegenseitige Beeinflussungen der einzelnen Teile untereinander wirksam unterbunden werden, und das sind dann keine nativen Systeme mehr im heutigen Sinne.

So, das war jetzt aber ne Menge offtopic.

Um mal wieder zum Thema zu kommen:
Ich bin sehr gespannt, was von Behringer in nächster Zeit so kommt; ich rechne fest damit, daß da schon so ein wenig Midas- und Klark-Knowhow in den Behringer-Bereich fließen wird. Und ein neues Digipult von Behringer wär auf jeden Fall mal überfällig. Das DDX hab ich damals als Sub-Pult für Funkstrecken bei ner Musicalproduktion gekauft und seitdem regelmäßig im Einsatz, meistens als zentrale Routingmatrix im Studio, manchmal für Budget-Sachen auch live. Wenn die da mal was zeitgemäßes nachschieben würden, wär das sicher ne interessante Sache.

Zitat von &quot;Wurst Werner&quot;

Aber die gesamte Digitalpultgeschichte wird eh bald von rechts mit nativen Systemen überholt. Billiger, leistungsfähiger, wesentlich flexibler in der Personalisierung...

Ich hab das (als meist stiller Mitleser hier) jetzt schon in ein paar anderen Threads von dir gelesen, daher hier mal ne Frage dazu:
Wie genau definierst du denn ein "natives System"? Dieser Ausdruck kommt doch vor allem aus dem Studiobereich, wo man ausdrücken möchte, daß die verwendete Software eben keine speziellen DSPs oder sonstige Coprozessoren benötigt, sondern vollständig auf der Host-CPU des Rechners (eben nativ) ausgeführt wird.
Übertragen auf ein Live-Mixing-System würde das doch heißen, daß ich eben nicht mehr wie jetzt in einem Digitalpult einen Steuerprozessor habe, der sich um Ein- und Ausgabe (Encoder, Fader, Display, Leuchtdioden) kümmert und einen oder mehrere DSPs, die den Audioteil abwickeln, sondern nur noch eine große CPU, die das alles auf einmal übernimmt.
Ich frage mich ernsthaft, ob das so erstrebenswert ist. Wenn man sowas umsetzt, dann muß man ja trotzdem nach wie vor garantieren, daß es sauber läuft, also nicht plötzlich Audio-Aussetzer auftreten, weil ich jetzt grad auf Kanal 71 das entscheidende EQ-Band zu viel aktiviert habe. Das geht meines Erachtens nur mit darauf spezialisierten Echtzeit-Betriebssystemen, die entsprechende Garantien abgeben können. Du brauchst also auf jeden Fall eine andere Infrastruktur als die, die derzeit in PCs vorherrscht, somit kann man auch nicht mal grad so eben in den großen Studio-Plugin-Fundus greifen und das auf nem Digitalpult laufen lassen.
Mal ganz abgesehen von der Stabilität. Wenn ich, wie du in anderen Threads schon angedeutet hast, das Digitalpult nur noch als großen Host für ne Ladung Drittherstellerplugins habe, dann hab ich da aber nen gewaltigen Haufen an Software verschiedenster Programmierbuden, die dann reibungslos zusammenspielen soll. Ich will da irgendwie nicht so recht dran glauben. Auch wenn ich selbst Informatik studiert hab und einige Rezepte kenne, wie man sowas sicherstellen kann, weiß ich doch auch, daß das in der Praxis meist nicht so funktioniert oder umgesetzt wird. Und ich möchte sicher nicht beim nächsten Gig da stehen und einen spektakulären Digipult-Absturz haben, weil das letzte Update meines Lieblings-Compressor-Plugins einen Fehler hat, der leider beim extensiven Test im Lager nicht aufgefallen ist, weil er nur bei einer ganz bestimmten Konstallation auftreten kann, die beim Test nicht dabei war.
Ich behaupte jetzt einfach mal, daß wir mit Digitalpulten, so wie wir sie jetzt kennen, noch eine ganze Zeit lang leben werden. Sicher, die Bedienkonzepte werden sich verändern - das sieht man ja jetzt schon bei iLive, Vi4/6 und Konsorten, aber eine komplett offene Architektur wie beispielsweise die VST-Architektur im Studio sehe ich noch lange nicht am Horizont. Vielleicht werden sich die Hersteller ja mal auf eine Schnittstelle zum Austausch von Audiodaten zwischen Prozessoren einigen, so daß man seine Lieblingshersteller in Form von Steckkarten ins Pult einbauen kann. Da können dann beispielsweise auf der Waves-Karte Plugins von Waves laufen, unabhängig von der Software des Pultes. Die Waves-Karte kann nicht durch Software-Eigenheiten des Pults aus dem Tritt gebracht werden und umgekehrt, denn eigentlich ist die Karte nur eine Art Siderack, das durch ein digitales Multicore (eben der Steckverbindung zur Karte) mit dem Pult verbunden ist.
Evtl. wirds noch einen Standard geben, wie die Karte dem Pult die GUI-Elemente der Plugins mitteilen kann und das Pult Parameteränderungen an die Karte überträgt. Damit ließe sich ein recht stabiles Digitalpult konstruieren, und wenn die Karten standardisiert sind, läßt sich das auch einfach für verschiedene Anforderungen konfigurieren. Der Headliner-Tech beim nächsten Wacken, der unbedingt ein spezielles Lexicon-Hall-Plugin möchte, bringt halt notfalls seine Karte noch selber mit und steckt sie dann dort in einen freien FX-Slot im Pult, genau so, wie er heute halt noch sein eigenes kleines Spezial-FX-Rack mitbringt und über analoge oder digitale Anschlüsse mit dem Pult verbindet.

So, jetzt hab ich mich hier tatsächlich zum Spinnen hinreißen lassen. Ein "natives System" in dem Sinne, daß eine Haupt-CPU alles macht, ist das jedenfalls nicht mehr. Aber wie gesagt, ich glaube da für Live noch nicht so wirklich dran, denn dafür isses dann einfach zu wackelig. Oder würdest du dich wohlfühlen mit nem Rechner mit zwei Hammerfallkarten und Wandlern sowie ner Faderbox als Live-Mixing-System?

Gruß,
Robert

Probier doch mal noch GetDataBack for FAT von RuntimeSoftware (http://www.runtime.org/gdb.zip). Kann in der Demo die gefundenen Dateien nur mit einem auf die Dateiendung assoziierten Programm anzeigen, vielleicht reicht dir das ja schon. Die Vollversion erlaubt dann auch das einfache Kopieren der gefundenen Dateien auf einen anderen Datentraeger.

Hallo,
bin leider erst jetzt zum Testen gekommen.
Jedenfalls geht das - so zumindest - nicht. Im Studio Manager (und auch am Pult) kann der Group Fader gar nicht selektiert werden. Auch das direkt im Layer Window über dem entsprechenden Fader angezeigte "GrpX" läßt sich nicht ändern.

Offenbar ist das nicht vorgesehen, daß man die Namen der Gruppenmaster ändert. Also doch wieder Bäpper aufs Pult machen oder Zuordnung merken. Schade, ist aber auch nicht lebensnotwendig. Ich war ja ehrlich gesagt schon positiv überrascht, daß das DM2000 überhaupt was DCA-artiges anbietet.

Hallo Gemeinde, ich haette da mal eine Frage.

Ich hab mit dieser Tage mal mit der Group Master Fader-Funktion beim DM2000 auseinandergesetzt. Diese erlaubt es mir ja, wenn ich Fadergruppen definiert habe, diese wie VCAs bzw. DCAs zu handhaben. Den Fader selbst kann ich mir auf einem selbstdefinierten Layer auch frei irgendwo hinlegen. Soweit funktioniert das auch alles so wies soll, nur wuerd ich gerne dem Masterfader auch einen eigenen Namen geben. Im Moment steht im Display ueber dem Fader immer der Name "GrpX". Ich haette da gerne sowas wie "Drum" stehen. Geht das ueberhaupt? Hab in den Menues und der Anleitung dazu nix gefunden.

Danke schonmal im Voraus,
Robert

Chefs von VA-Firmen, die mir ein Mischpult abkaufen wollen, die ersten zwei Termine absagen, den dritten platzen lassen und dann einfach nicht mehr erreichbar sind und nicht mal in der Lage sind, ne Mail mit ner Absage oder Entschuldigung zu schreiben...

Zitat von &quot;dasich&quot;

Ja es übersteuert, zumindest ein LS9, M7 und ein PM5D

Das find ich aber mal seltsam. Ich hab daheim neben dem Audio-Rechner ein olles DDX3216 vom Hersteller mit dem Ohr stehen, da passiert das nicht. Kanaele faehrt man sowieso selten auf Pegel ueber 0dBFS, aber bei Gruppen kann das schon mal passieren. Auch viele relativ niedrig gepegelte Kanaele koennen sich auf dem (hier ja virtuellen) Summenbus zu ueber 0dBFS addieren. Jedes heute erhaeltliche Digitalpult sollte da eigentlich einen entsprechenden Headroom haben. Entweder, es wird in Festkommatechnik gerechnet, da kommts dann drauf an, wie viele Bits "vor dem Komma" stehen. Bei in Fliesskommatechnik ausgefuehrten Pulten sollte man in der Praxis ueberhaupt keine interne Uebersteuerung mehr produzieren koennen (32Bit-Fliesskommazahlen ermoeglichen bei Standard-Implementierung nach IEEE einen Headroom von ca. 762dB ueber 0dBFS, das sollte reichen).

Wichtig ist natuerlich, dass der Masterfader so weit runtergezogen wird, dass das Summensignal vor der DA-Wandlung wieder unter 0dBFS kommt - das sollte jedem klar sein. Gleiches gilt natuerlich fuer alle Sends zu externen Geraeten, egal ob analog oder digital eingebunden.

Mich wuerde wundern, wenn das bei Yamaha anders waere, ich hab aber grad kein Pult in Reichweite, um das zu verifizieren.

Ich hatte mal unerklärliche Probleme mit den analogen Ausgängen meines DDX, nachdem ich den Lüfter getauscht hatte. Es stellte sich heraus, daß ich beim Auseinander- und Wiederzusammenbauen des Pults versehentlich das Kabel, das die Platine mit den analogen Ausgängen anbindet, halb gelöst hatte.
Wenn ich mich recht erinnere, sollten in dem Pult eigentlich alle Steckverbindungen mit Heißkleber gesichert sein. Vielleicht ist da aber trotzdem was lose oder korrodiert.

Zitat von &quot;hunterstudios&quot;

Jetzt wollte ich den DEQ auch bei meinem unplugged-Duo einsetzten, nur wollte ich diesen jetzt einfach per Adat insert einbinden. Und hier kommt das Problem, ich bekomme alle 3 Minuten einen Syncfehler in dem das System für 1 Sekunde Stumm bleibt.

Hmm, aber das 01v96 laeuft immer noch als Master, oder? Manche machen bei solchen Schleifenverkabelungen den Denkfehler, alle Geraete auf Slave zu stellen. Das synct dann - irgendwie. Aber da sich die Geraete alle gegenseitig "hinterherlaufen", bricht das irgendwann zusammen.

Gruss,
Robert

Zitat von &quot;mirkot&quot;

[Hier läuft übrigens alles prima, gleich ist die Show rum, alle wirken entspannt...n stündchen noch - gell ]

Ist ja schön zu hören, daß das bei Euch im weiteren Verlauf noch so gut ging. Mich habense gestern dank fehlender Backstage-Pässe nach Spielbann leider nicht mehr in den Backstage-Bereich gelassen, sonst hätt ich ja wenigstens noch Tschüs gesagt...

Immerhin konnte ich auf der anderen Seite an der Surferbasis beim Grillen den Rest des Festivals 1a hören. Nur der Baß hats nicht ganz so druckvoll über den See geschafft... Trotzdem schon toll, was so ein Linearray alles kann, wenns windstill ist.

Ach Mirko: Sorry für die etwas plötzlich einsetzenden +48V auf dem HH-Kanal - ich geb dir demnächst mal einen aus...

Gruß,
Robert

Fuer den Puristen ist die Loesung mit dem zwischengeschalteten DDX allerdings auch nicht unbedingt das Wahre: Das DDX synct naemlich nicht das ganze Pult auf den SPDIF-Eingang, sondern lediglich der Eingang selbst synct sich auf Quellen (ich glaub 30-50kHz Samplerate sind moeglich). Danach sitzt ein Sampleratenkonverter, der das Signal grundsaetzlich auf die gerade aktive DDX-Clock wandelt. Den SPDIF-Eingang kann man auch nicht als Sync-Quelle anwaehlen.

Wenn es also darum geht, die alten Baender bitgenau zu archivieren, hat man mit dem DDX ohne Weiteres keine Chance. Ich koennte mir hoechstens vorstellen, das Clocksignal irgendwie aus dem SPDIF zu extrahieren und dem DDX als Wordclock zur Verfuegung zu stellen.

Jedenfalls koennte darin auch eine Erklaerung liegen, warum das EMU nicht mit dem DAT zusammenspielen will. Evtl. ist naemlich die DAT-Clock nicht mehr so ganz sauber, und das EMU kommt dann auch in seinen Grenzbereich und synct nicht mehr sauber. Das DDX kommt vielleicht damit klar, und da das EMU danach eh die DDX-Clock sieht, hat es mit der evtl. kaputten Clock des DATs nicht mehr zu kaempfen.

Gruss,
Robert

Zitat von &quot;nojunk&quot;

:oops: mal ne ganz dumme frage am rande:
wie machen eigentlich "In Extremo" das mit ihren dudelsäcken?

Ich hab mit In Extremo noch nix zu tun gehabt, aber Corvus Corax bzw. Tanzwut haben zwei Kanaele Funk an ihren Dudelsaecken dran und halt besagte Schwanenhalsmikros an den Pfeifen. Saltatio Mortis macht das glaub ich ebenfalls so. Hatte vor ein paar Jahren mal mit einem der Jungs zu tun, da waren glaub ich irgendwelche dynamischen AKG-Klemmmikros dran, ich weiss aber nicht mehr welche.