Ich weiss - Presonus...

  • ...aber so richtig daneben scheint mir dieses Mischgerät nicht zu sein. Scheinbar eben rausgekommen:


    StudioLive® Series III SE 16 Digital Console Mixer
    Designed to inspire and built to perform, StudioLive SE delivers pristine, ultra-low noise studio-quality sound to the stage in a unique split-fader frame.…
    eu.presonus.com


    Direkter Konkurrent zum Qu - und neu auch schwarz. Die Farbe scheint wieder in Mode zu kommen :) ;)

  • Zur hilfreichsten Antwort springen
  • ...aber so richtig daneben scheint mir dieses Mischgerät nicht zu sein. Scheinbar eben rausgekommen:


    https://eu.presonus.com/produc…-16-digital-console-mixer


    Direkter Konkurrent zum Qu - und neu auch schwarz. Die Farbe scheint wieder in Mode zu kommen :) ;)

    Die Frage ist, ob man hier jetzt Pre/Post je Kanal und Aux hinbekommen hat und nicht nur global je Bus. Und ob die FXe nun auch besser einzustellen sind. Das ist wirklich speziell bei dem Pult.


    Cool ist auf alle Fälle, das wohl alle "alten" Studiolive 3 Pulte die neue SW bekommen und auf Milan wechseln.

  • "AVB-Netzwerkschnittstelle für den Anschluss von StudioLive Stageboxen und Milan-kompatiblen Geräten"


    Das wäre allerdings wirklich neu, man kann gespannt sein in wie weit Wort gehalten wird. Bisher war die AVB Hardware nicht außerhalb des Kosmos nutzbar.

  • Ich befürchte, dass Presonus bei der Aux Pre/Post-Geschichte pro Kanal nichts angepasst hat... Die Thematik wird bei den Feature-Request's wohl schon seit gefühlten 20 Jahren angesprochen.

  • Ich bin ja wirklich kein Presonus Fan, aber die Milan Sache macht diese Pulte wirklich interessant.

    Die sind zertifiziert, also gehe ich davon aus das sie direkt mit den anderen Milan Geräten zusammen spielen, wie z.b. die Lautsprecher der Linear Serien von uns 😇


    Endlich, Halleluja 8)

    Privater Account mit meiner persönlichen Meinung.

    Sollte es ein Problem mit meiner Neutralität zu einem Thema geben mache ich das im Beitrag kenntlich. :thumbup:

    http://www.noon.ruhr


    Application Support Engineer - HK Audio

  • ...aber so richtig daneben scheint mir dieses Mischgerät nicht zu sein. Scheinbar eben rausgekommen:

    Bin da skeptisch. Habe mir ja in der frühen Post-Corona-Zeit, als man fast nichts bekam, das Series III 24 gebraucht geschossen.


    Auch weil ich mal sehen wollte, was das Zeug so kann, zumal ich einige Ideen da drin ganz spannend fand.

    Leider scheinen wohl an vielen Stellen die Ideen nicht über die "Designstudienphase" hinausgekommen zu sein. Über ca. 3 Firmwaregenerationen sind einige nervige Eigenschaften und Bugs einfach nicht verschwunden oder besser geworden, wie z.B. fehlende Inserts, seltsames Verhalten mit Abgriffpunkten, wenn man die Eingänge (Analog, USB, SD, AVB) hin- und her schaltet, falsche interne USB-Routings, seltsame Fehler bei der Verwendung als DAW-Remote usw.


    Und wenn man sich zu solchen Themen mal im Userforum umgesehen hat, bekam man schon das Gefühl, dass die ihren Ar... nur auf feinsten Marketingsesseln platt sitzen.


    Dass es noch immer keine Companion-API gibt spricht für mich Bände. Werben die doch immerhin mit "house of worship" und "churches". Da sind bei den ernstzunehmenden Streamdecks doch normaler als Unterhosen am Füdli...


    Ach ja:

    Und das 24 Rack, dass ich noch selbstständig oder als Stagebox benutzt habe, hat schon fast 10dB früher verzerrt als die Pegelanzeige einem mitgeteilt hat...

    Hatte mich erstmal bei einer Aufnahme (zum Glück nichts, wo es drauf angekommen wäre) von ein paar Sängern im Nachhinein gewundert, warum es bei den lauten Passagen in den Spitzen so platt klingt. Irgendwann habe ich das Ding mal an die Messstation gehangen.


    Ein MR18 ist dagegen HiEnd...


    ps - Ach ja: Ich habe in meinem Leben 6 Audiogeräte von Presonus besessen. Davon hatten 3 irgendwann einen Netzteilschaden. Nur eines davon war schon etwas älter (noch Linearnetzteil)

    Einmal editiert, zuletzt von audiobo ()

  • Das Betrifft den Stream und was ist mit der Gainsteuerung? Die wäre sogar am 1772.1 standardisiert vorhanden also technisch gesehen könnte das Pult mit anderen Boxen arbeiten. Das Presonus ihre Hardware trotz propagierter AVB Fähigkeiten sich nicht außerhalb nutzen lässt ist eines der größten Enttäuschungen. Dies widerspricht sogar den Gedanken eines Standards.


    Dann auch noch mit 48khz -> A&H QU läuft mit 96KHZ und die Dante Hardware ist im Kosmos vorhanden.

  • Hier wird AVB mit Milan durcheinandergeworfen. AVB stellt ein Set an Spezifikationen bereit, definiert aber nicht, was davon umgesetzt werden muss. Genau das war ja immer die Krux.


    Milan setzt hier an und definiert bewusst die Minimalanforderungen (z. B. Kanäle pro Stream, 48 kHz Support verpflichtend, höhere Samplerates optional, …), um Interoperabilität sicherzustellen. Genau diese Anforderungen erfüllen die Presonus-Geräte durch ihre Milan-Zertifizierung.


    Gainsteuerung gehört aktuell nicht zum Milan-Standard. Das jetzt als Argument gegen Presonus ins Feld zu führen, wirkt weniger wie sachliche Kritik und mehr wie bewusstes Schlechtreden.

  • Nö Milan hat den Standard der IEEE verlassen und sogar an dem genormten Header was heran geklatscht so das es inkompatible wird. Auch hat man die Art des Verbindens modifiziert so das es mit AVB Geräten Probleme gibt.


    Der Grund ist da man sich bei der IEEE mit den Vorschlägen nicht durchsetzte, hat man eben seinen eigenen Kram erfunden.


    Presonus fährt sogar ein drittes Gleis und hat zur Steuerung der Hardware ein weites nicht öffentliches Protokoll eingeführt. Die Absicht ist ganz klar nicht kompatible zu sein und das ist auch der eigentliche Grund weshalb sich die Milan Gruppe nicht auf die Steuerung im Standard einigen konnte.


    Es läuft ja unter Dante ähnlich mit Glück lässt sich die Hardware mit der Hauseignen Software steuern, bei Presonus geht nicht mal das!

  • Ich kann nicht für Presonus sprechen, und meine Uralt-Geräte laufen noch;) wollte aber den Grund verstehen für:
    > und das ist auch der eigentliche Grund weshalb sich die Milan Gruppe nicht auf die Steuerung im Standard einigen konnte.

    Milan ist eine Netzwerk-Spezifikation, absichtlich nicht Audio-Signalverarbeitung oder Mischpult-Steuerung.
    Milan hat nicht versucht das Rad "Steuerung" neu zu erfinden, sondern den existierenden ATDECC Standard von der IEEE verwendet. Hive, Milan Manager und ein paar Hersteller-eigene Applikationen implementieren diesen Standard und sind für alle Milan-Geräte für routing und diagnose nutzbar.

    > Milan hat den Standard der IEEE verlassen und sogar an dem genormten Header was heran geklatscht so das es inkompatible wird.
    Die Avnu erstellt für ein paar IEEE Standards Testpläne und zertifiziert deren Einhaltung.
    An welcher Stelle wurde was geklatscht?

    • Hilfreichste Antwort

    Nö Milan hat den Standard der IEEE verlassen und sogar an dem genormten Header was heran geklatscht so das es inkompatible wird. Auch hat man die Art des Verbindens modifiziert so das es mit AVB Geräten Probleme gibt.


    Der Grund ist da man sich bei der IEEE mit den Vorschlägen nicht durchsetzte, hat man eben seinen eigenen Kram erfunden.

    Sorry, aber das ist komplett falsch. In der letzten Version des 1722.1 wurden in Zusammenarbeit mit den Milan Herstellern sogenannte 'Vendor Specific Commands' eingeführt, die es erlauben, dass bestimmte Profile von AVB - wie z.B. Milan, es ist ein AVB PROFIL - eigene Befehle definieren und implementieren. Das ist also allerhöchstamtlich IEEE 1722.1 konform.
    Der Grund für diesen Weg ist, dass die IEEE selbsterklärtermaßen niemals in der Lage wäre, allen Detailanforderungen der ProAV Industrie vollständig und in angemessener Zeit (!!) gerecht zu werden. Genau deshalb gibt es solche Profile wie Milan, in welchen die Use Case spezifischen Details definiert sind. Aber nichts ist hier 'eigener Kram' oder gar prinzipiell inkompatibel.

    Die Verbindungsprozesse in 1722.1 sind teils unzureichend für größere ProAV Anforderungen und wurden ebenfalls mit Hilfe dieser spezifischen Erweiterungen optimiert. Das alles wird von der Avnu Alliance geprüft und zertifiziert.

    Ich weiß es, weil ich Teil des Vorgangs war und immer noch bin.

  • danieldb

    Hat einen Beitrag als hilfreichste Antwort ausgewählt.
  • Hier wird AVB mit Milan durcheinandergeworfen. AVB stellt ein Set an Spezifikationen bereit, definiert aber nicht, was davon umgesetzt werden muss. Genau das war ja immer die Krux.


    Milan setzt hier an und definiert bewusst die Minimalanforderungen (z. B. Kanäle pro Stream, 48 kHz Support verpflichtend, höhere Samplerates optional, …), um Interoperabilität sicherzustellen. ...

    Ganz kleine Korrektur: Milan enthält keine Verpflichtung zu 48kHz. Es ist vielmehr der einzige (!) Fall, in dem 2 Milan Geräte kein Audio miteinander verbinden können, wenn sie NICHT dieselben Samplerates unterstützen.

    Das erscheint merkwürdig, hat aber den Grund darin, dass es auch Mischpult- und Studiogerätehersteller gab und gibt, die ausschließlich auf 96 kHz oder 192 kHz setzen, und die wollten auch Milan implementieren können, ohne ihre gesamte Hardware umbauen zu müssen. Sample Rate Converter implementieren geht - wie auch immer - nur mit hohem Aufwand.
    Es wird sich auf Dauer zeigen, ob sich Hersteller in Zukunft noch dazu hinreißen lassen, Geräte in den Markt zu bringen, die wg. Vernachlässigung von 48kHz nicht mit allen anderen Milan Geräten interoperabel sind.

    Ich behaupte, dass der Markt das Thema recht schnell erledigen wird, zumal es - Stand heute - eh eine absolute Ausnahme ist.

  • Sorry, aber das ist komplett falsch. In der letzten Version des 1722.1 wurden in Zusammenarbeit mit den Milan Herstellern sogenannte 'Vendor Specific Commands' eingeführt...


    Die gab es schon immer und es wurden Datenfelder unten heran gesetzt welche dann mit dem nachfolgenden Standard 1722.1 nicht harmonierte. Controller mussten Milan Geräte nun erkennen und zwei unterschiedliche Datenpakete auswerten. Mit GET_MILAN mussten Controller erforschen ob das ENTITY ein Milan gerät ist und eine Sonderbehandlung einleiten. Sorry nicht der Sinn eines Standards....


    Der Verbindungsaufbau dauerte mit all seinen Timeouts zu lange und man hat diesen modifiziert. Mit der Folge das es bei einen anderen Big Player der AVB vorantreibt zu Problemen mit Milan Geräten kommt. Auch in der AV Industrie ist Apple weit verbreitet bis heute gelingt es nicht einen Stream ohne Probleme zwischen einem Milan und den Apple AVB Core aufzubauen.


    RME Geräte haben zwei Profile Milan und AVB -> gemischt Ähmm Sorry Probleme. Wenn man nur das aus dem vereinbarten Standard der IEEE genommen hätte würden die Geräte untereinander Problemlos spielen, zumindest wenn das Streamformat passt.


    Ich würde sagen faktisch ins Knie geschossen...

    Einmal editiert, zuletzt von marcoboy ()