Beiträge von Jens Droessler

Zitat von "klauston"

Also ganz ehrlich:

Wenn man von professionell spricht, dann sollte es diese Diskussion gar nicht geben.
Denn es ist einfach nur unprofessionell , wenn man ein Pult im Verleih hat, welches nicht wirklich zeitnah updates bekommt.

Und wenn es das erste mal dazu kommt, dass ein Pult wegen eines neuen Bugs abschmiert, das ist dann professionell? Glaubst du, dein Auftraggeber interessiert sich dafür, dass du ja nichts für den Bug kannst?

Zitat

Was bei einem Analogpult der Service war, ist eben bei einem Digitalpult die Verwaltung der Software.

Eben. "Verwaltung" heißt aber nicht zwingend, sofort alles zu aktualisieren, sondern zu entscheiden, welche Vorgehensweise sinnvoll ist.

Zitat

Wenn ein Fader beim Analogen alt ist und nicht geht, wartet man ja auch nicht 1 Monat, ob nicht noch ein Fader eingeht, oder??

Ein an den Haaren herbeigezogener Vergleich. Ein feature release "repariert" das Pult nicht. bugfix-releases werden gleich eingespielt, genauso wie ein Analogpult möglichst bald repariert wird.

Zitat

Ich finde es ehrlich gesagt wirklich schrecklich , das man über sowas diskutieren muß.
Das Einzige was ich verstehe, wenn zB Komerzmusiker ein Pult haben und das über Jahre so spielen lassen, das kann ich noch mal nachvollziehen, aber Profis?????

Als Profi sollte ich mir also mehr Gedanken um Aktualität als um die Gewährleistung eines sicheren Showablaufs machen? Ja, du hattest noch nie solche Bugs, aber zu sagen, dass das deshalb nie passieren wird, ist genauso blauäugig wie zu sagen, dass man nie einen Platten am Auto haben wird, weil man bisher nie einen hatte. Mir ist einfach unwohl bei dem Gedanken. Ich habe ja nicht gesagt, dass man die Version gar nicht installieren sollte, ich bin einfach nur vorsichtig.

Letztlich kann man telefonisch klären, ob man die neueste braucht, dann kann man sie immernoch rechtzeitig draufpacken, oder ob das File nicht eh noch von der alten Version stammt.

Da hast du mich falsch verstanden: Ich habe erklärt, warum ich bei "major-", auch "feature-release" genannten neuen Versionen warte, und warum ich es gerechtfertigt finde, da zu warten. Wenn du dagegen lieber immer topaktuell sein möchtest, ist das dein gutes Recht. Ich will bestenfalls erreichen, dass du meinen Standpunkt akzeptierst.

Ob es das nun schon gab oder nicht, passieren kann es. Es muss doch nicht immer gewartet werden, bis was passiert, bevor man sich Gedanken darum macht. Man lässt doch die Bremsen am Auto auch nicht erst machen, nachdem man schon ein anderes Auto gerammt hat, weil sie nicht mehr funktioniert haben, oder? Zum anderen muss auch so ein Bug nicht zu denen gehören, die man per einfachem Knopfdruck aktiviert. Das kann gut versteckt sein, vielleicht entdeckt den nur ein einzelner Anwender, meldet es und es wird still gefixt. Ich würde solche Bugs auch nicht im Changelog erwähnen, damit die Anwender keine Angst vorm Update bekommen. Denn natürlich kann nicht jeder zwei bis vier Wochen warten, bis er die neue Firmware draufzieht, denn dann würden ja auch keine Bugs entdeckt werden und die Wartezeit wäre sinnlos.

Da musst du dich verlesen haben. Die Xilicas haben deutlich mehr als zwei PEQs pro Ausgang.

Aber was ist, wenn die Version dann wirklich einen Bug in der Größenordnung Showstopper hat, der erst nach einer Woche gefixt wird? Mir wärs lieber, der Techniker bastelt wenns gar nicht anders geht das Setup neu als das Risiko einzugehen, der Entdecker eines bösen Bugs zu werden. Leider sind wir ja heutzutage alle anteilig Betatester. Wie gesagt, reine Bugfix-Versionen packe ich auch so schnell wie möglich drauf.

Naja, das ist dann aber auch Schuld des Anwenders. Mehr als über Änderungen informieren kann der Hersteller ja nicht...

Ich sehe das wie wora. Wenn eine "major"-version kommt, warte ich zwei bis vier Wochen, dann kommt sie drauf. bugfix-Versionen kommen dagegen nach zwei drei Tagen drauf, wenn keine neuen Features dazu kamen. Mein Job als Anbieter ist ja nicht nur die Wartung und Instandhaltung, sondern auch die Qualitätssicherung. Im EDV-Bereich wurde ich ein Testsystem mit dem Update bestücken und "ein wenig" testen. Bei Pulten kann ich mir das nicht leisten...

Zitat von "Mechwerkandi"

"Produktänderungen, die dem technischen Fortschritt dienen, vorbehalten."

Ist ja richtig, aber zumindest kam es mir bei Eighteensound noch nie unter, dass sowas ohne Änderungen am Datenblatt stattfindet. Ich könnte mich noch nichtmal dran erinnern, dass sie mal ein Modell überarbeitet haben ohne gleich auch die Bezeichnung zu ändern.

Jaja, die Tücken der modernen Technik. Hätts früher beim analogtisch nicht gegeben

Ich sehe es so: Man sollte die aktuellste oder zumindest eine File-kompatible Version der Firmware drauf haben. Das gebietet schon die Logik: Neue Firmwares können alte Pultfiles laden, veraltete Firmwares aber selten neue Files. Damit ist dieser Teil für mich gegessen. Das gilt für alle Systeme, mit denen ein Fremdnutzer konfrontiert wird. Etwas anderes sind Firmwares z.B. für Controller. Ich habe auch nicht alle meine Nexo NX auf dem letzten Stand, aber das hat auch seinen Grund: Es sind mit der Zeit einige für mich wichtige PreSets rausgefallen. Die veralteten Versionen spielen aber keine Rolle, da an den PreSets für meine Systeme schon ewig nichts mehr verändert wurde.

Ich denke, dass zwei Wochen aber etwas kurz sind, um auf Bugreports zu warten. Wenn ich sehe, dass Firmware 2.1 rauskommt, da einige Fehler drinstecken, es aber vier bis sechs Wochen dauert, bis eine gefixte Version herauskommt, die dann "dringend empfohlen" aufegspielt werden muss, weil die vorige Version kritische Fehler enthielt, dann scheint mir eher das die richtige Wartezeit zu sein. Ich würde bis die 2.11 raukommt dann auch eher die 2.0 bevorzugen, wenn sie diese kritischen Fehler nicht beinhaltet.
Andererseits würde ich keinen Fremdtechniker meine Pulte updaten lassen (rein hypothetisch gesprochen). Er dürfte mich gerne darum bitten, dass Update durchzuführen, dann kann ich mit ihm diskutieren, warum eben noch nicht die neueste Version drauf ist und gegebenenfalls dieses tatsächlich auf die Hardware packen. ICH mache das dann, niemand sonst. Nicht mal meine Mitarbeiter machen das im Lager, nur ich! Ich bin dafür verantwortlich, ich habe den Überblick darüber, was wo welchen Stand hat. Und aus schlechten Erfahrungen heraus würde ich auch kein Update auf der Veranstaltung oder direkt vor der Veranstaltung machen. Dafür ist schon zu oft Mist passiert, das möchte ich nicht riskieren. Erst recht nicht mit Files aus letztlich unbekannter Quelle.

Nanana, wir sind hier ja nicht bei den China-Chassis. Eighteensound hatte nach meiner Erfahrung eine ganz gute Konstanz über die Chargen hinweg. Nur wenn dann Produktverbesserungen anstehen hat sich schon mal was verändert, obwohls das eigentlich nicht hätte sollen.

Nun, natürlich gibt es Ausnahmen zum von mir geschriebenen. Wenn ein Techniker ein bestimmtes Pult fordert, sollte man davon ausgehen dürfen, dass er es auch im Griff hat und ein Pultbetreuer nicht vor Ort sein muss, es sei denn es ist eine Riesenbaustelle und er muss schon allein wegen des Routings anwesend sein. Wenn man mir ein oLive oder ein Yamaha hinstellt, braucht da auch keiner zu betreuen. Da reicht's wenn einer sagen kann, wo was hingeroutet würde (Front, Monitore, Infill, evtl. Subs etc.) oder such wine Liste. Mir wäen jetzt auch nur wenige Techniker bekannt, die zur Bedienung eines sagen wir GL4000 eine Soufleuse brauchen.

Ich bin vielleicht tatsächlich zu idealistisch in meinen Ansichten, aber so arbeite ich auch.

So sehe ich das auch. Ein Pultbetreuer, der das Pult nicht bedienen kann, ist irgendwie fehl am Platz. Er ist ja gerade dafür da, dem Gasttechniker weiterhelfen zu können. Ich betreue nur Pulte, die ich gut kenne. Und wenn ich angefragt werde, eins zu betreuen oder zu bedienen, was ich nicht kenne, nehme ich mir entweder die Zeit, mich da einzuarbeiten oder wenn es diese Zeit nicht gibt, lehne ich ab. Das ist meiner Meinung nach korrektes und professionelles Verhalten. Keiner hat etwas davon, wenn am Ende weder Gasttechniker noch Betreuer mit dem Pult umgehen können. Auch dem Chef oder Auftraggeber des "Betreuers" kann die Freude über das verdiente Geld und das Lachen durchaus vergehen, wenn die Beschwerden kommen und dieser Kunde nicht wiederkommt.

Ich nehme grundlegend erstmal die PEQs, um die aufstellungs- und systembedingten Probleme zu beheben, zumindest wenn es keine Controllerbox mit Monitoring-Preset ist (ja, man könnte sich ja ein eigenes PreSet für den eigenen Controller basteln, aber warum nochmal hin und her wandeln und auch die Latenz in Kauf nehmen, wenns nicht sein muss?). Das reicht oftmals schon aus. Wenn nicht, kommt dann der GEQ zum Einsatz. Jeder Fremdtechniker bekommt dann meine PEQ-Settings "vorinstalliert" (sodenn es denn meine Monitorboxen sind, bei denen ich weiß, wo es hängt) und kann am GEQ tun, wie er möchte.

Zitat von "wora"

und manchmal liegen die terzfrequenzen auch für systemmessungen günstig

Aber die Güte, die Güte!

Es sieht so aus, als wäre die Bandanzahl beim GEQ auch gestiegen und die Frequenzen unterhalb 63Hz auch auf dem GEQ.

Ich hoffe, dass jeder Multibandkompressorslot im Effektrack mehrere Ein- und Ausgänge hat, sodass man für vier Vocals nicht gleich zwei oder gar vier Effektslots verballern muss. Den DynEQ hätte ich mir als umschaltbarer Ersatz für Limiter/Deesser anstatt als Effektblock gewünscht (Ja, die Hardwareknöpfe passen dann nicht, aber sollte man sich davon wirklich abhalten lassen, die Funktionalität zu optimieren? Ich meine, die Frequenzskala an den EQ-Knöpfen passt ja im full-Modus auch nicht). Einerseits braucht man beides gleichzeitig kaum, andererseits möchte ich dafür ungern Effektslots hergeben. Auch brauche ich zumindest kaum mehr als ein DynEQ-Band pro Input. Da es aber jetzt nur als Effektslot gedacht ist, hoffe ich wie beim Multibandkompressor auf mehrere bearbeitbare Kanäle pro "Instanz".

Weiterhin sichtbar im Blog sind ja iDR/xDR mit AES/EBU-Ausgängen. Es sieht aber so aus, als würden diese Ausgänge die entsprechende Anzahl an analogen Outs ersetzen. Sehr schade und unflexibel. Warum nicht umschaltbar oder zusätzliche Buchsen, die parallel laufen? Auch AES/EBU-Ins an iDR/xDR wären fein gewesen, wenn man eh schon an der Hardware arbeitet...

Alles in Allem sieht man aber, dass es voran geht, dass Features gebracht werden, die gewünscht und sinnvoll sind. Das System wird immer "fetter", immer mehr Pluspunkte bei Leuten mit Ahnung, sehr schön. So sieht mans als Kunde gerne!
Wenn sie jetzt noch den Speakermatrixprozessor zum vollwertigen Controller aufbohren, wären alle Fälle erschlagen

Die Sennheisers bei 1,8GHz werden wohl neben dem LTE-Band liegen. Man wird ja kaum mit "Sicherheit vor LTE-Störungen" werben, wenn man das neue Produkt direkt in einem anderen LTE-Bereich platziert. Die Bänder, in denen LTE arbeitet, sind ja nun schon lange bekannt.

Wenns jemand ist, den ich kenne und entsprechend einzuschätzen weiß, mache ich ihn natürlich auf so etwas aufmerksam. Wenn jemand "Guck mal mit und sag Bescheid, wenn dir was auffällt" dann natürlich auch. Aber ohne Weiteres sage ich einem Fremdtechniker nicht, dass was falsch läuft. Das gab schon zu oft Ärger. Dass mir gegenüber der Techniker dann unfreundlich wird, kommt selten vor und ist auch nicht sooo schlimm, aber so jemand geht dann zum Veranstalter und sagt präventiv "Was habt ihr denn da für einen Betreuer? Der kann ja gar nix", nur falls ich dann dem Veranstalter erzählen möchte, wo der Techniker Mist gebaut hat.

Vielleicht sollte man es im Hinterkopf behalten, wenn man nicht interferenzfrei (destruktiv) genug Material clustern kann, um den nötigen Wurf/Pegel zu erreichen. Wenn ich eigentlich sagen wir 10 Tops pro Seite mit 35x35° bräuchte, aber nur noch 60x40° habe, kann man es so zum Double Hang aufteilen, kommt auf ähnliche Abstrahlung ohne derartige Probleme und kann pro Hang höhere Pegel erzielen. Man muss ja nicht zwangsläufig nur die Vocals auf den zweiten Hang packen, man kann es ja auch insgesamt zwischen den beiden PAs ausbalancieren, dass beide ungefähr gleich belastet werden.

Oder auf LAs übertragen: Wenn ich nur noch kleinere Systeme übrig habe, davon aber genug. Jetzt mag der eine oder andere sagen "dann hänge ich einfach eine längere Line". Das kann aber auch scheitern, u.A. weil bei all der Kopplung in Mitten und Tiefmitten die Hochtöner leistungsmäßig nicht mehr mitkommen. Die Kompaktklasse ist ja nicht unbedingt für 30 Teile pro Seite ausgelegt, um auf Längen zu kommen, wie sie die großen Module schon mit 15 erreichen, daher wird am Hochtöner dann auch schon mal gespart gegenüber den großen Brüdern. Mal abgesehen davon, dass die Flughardware das schon nicht mehr hergeben könnte.

@ billbo: Das ist ja auch vollkommen richtig, und nebenbei noch ein Aspekt, warum "heftig" klarifiziert werden sollte. Bei der einen Schallquelle sind 6dB heftig, weil sie schon kräftig verstärkt werden muss (und somit auch alle "Störschallquellen"), bei der anderen ist das normales Arbeitsniveau.
Ich halte meine Kompressoren gut im Auge, wenn der Mix in der Entstehung ist, und auch später wird immer wieder kontrolliert, ob alles so läuft, wie ich es mir vorstelle. Kompression bereits ohne Gesang, nur durch genannte Störschallquellen kann ja nur falsch sein und zu Problemen führen, das ist keiner Diskussion wert. Allerdings rede ich fremden Gastmischern da nicht rein. Man macht sich da nur unbeliebt.

Aber um wieder auf Splitts zu kommen, und um normal darüber zu reden: Ich hatte mal eine gute Erklärung bekommen, warum man Splitts nicht einfach per Y machen sollte, wenn a) die Leitungen nach dem Splitt grob unterschiedlich lang und/oder b) die Geräte unterschiedlich sind. Es hatte zu der Zeit auch physikalisch für mich als E-Technikstudent Sinn ergeben, ich muss aber zugeben, dass ich diese Erklärung vergessen habe und nur das Fazit bei mir behalten habe. Darum habe ich immer einen Trafosplitt benutzt, es sei denn für lokales Splitting am selben Pult oder wenn zwei gleiche Digi-Stageboxen nebeneinander stehen. Dass ein einfecher Y-Splitt funktioniert war dabei auch nicht mein Bedenken, sondern mögliche Wechselwirkungen zwischen Geräten, Kabellängen etc.

@ billbo: Ok, mir war einfach nicht klar, worauf du hinaus willst. Was ein Kompressor tut weiß ich nicht nur von Google, aber meine eigene Arbeitsweise bringt mich nicht in Berührung mit so hohen Kompressionen und den damit verbundenen Problemen im kleineren Kreis, daher habe ich die auch nicht weiter bedacht. Trotzdem steht doch zur Debatte, was "heftig" für den Threadstarter bedeutet. Vielleicht empfindet er 6dB Reduktion heftig, du gehst bei heftig aber vielleicht von 20dB aus. Deswegen meinte ich, man müsste es erstmal in Zahlen fassen, bevor man sich darüber streitet. Ich habe ja nicht gesagt, dass du unrecht hast, nur dass ihr eventuell aneinander vorbei redet.

Ich verlasse mich lieber auf Standardkomponenten von Netzwerkherstellern, die wissen was sie tun, als ein doch recht kompliziertes System wie WiFi auch noch einem chinesischen Audiohardwaredesigner anzuvertrauen. Gerade, wenns dann auch noch mehr Controller werden, finde ichs eher hinderlich.

Und ob der Rest da auch so fortschrittlich ist müsste erst noch geklärt werden. Was mir auf anhieb überhaupt nicht gefällt, sind fehlende PEQs in den Eingängen. Die Grafik-EQs sind definitiv kein Ersatz, die PEQs im Ausgang auch nicht, da sie das Phasenverhältnis zwischen den Ausgängen beeinflussen. Auch dass es im Eingang keinen einstellbaren Hochpass gibt, finde ich nicht mehr so recht zeitgemäß.
Wenn es stimmt, dass die interne Verarbeitung nur mit 32bit abläuft, dürften die Filter gerade im Bassbereich nicht besonders gut klingen. FIR-Filter werden ja rückgekoppelt, es addieren sich Ungenauigkeiten bei der Berechnung auf. Ist die Bitbreite gering (und 32bit wird bei sowas als gering betrachtet), sind die Ungenauigkeiten groß und werden gerade im Bassbereich, wo aufgrund der geringen Signalfrequenzen öfter "pro Welle" zurückgekoppelt wird, hörbar.
Der Limiter ist da auch ein Mysterium. Ist das nun ein Peak-Limiter oder ein RMS-Limiter? Was bringt die Einstellung Compressor im Unterschied, wenn man keine Ratio einstellen kann?

Erstaunlich, und wird vielleicht dem einen oder anderen weiterhelfen. Aber ich habe zu diesem Thema mal eine Schaltpläne von RS232-zu-RS485-Wandlern gewälzt und festgestellt, dass sie alle RTS brauchen, manche sogar noch DTR. Keiner braucht CTS, erstaunlicherweise. Ich vermute, dass der DCX auch auf CTS verzichten kann.