Beiträge von marcoboy

Zitat von floger

Kann es sein, dass das Wing direkt aus der Datei bootet?

Was passiert, wenn man alle Dateien löscht?

gar nichts . Beim booten wird geschaut ob eine neue Firmware dort liegt und wenn ja wird sie auf dem Pult ausgerollt.

Zitat von Wurst Werner

Huhu, ich hab ne gute und ne schlechte Nachricht about Dante & WSG.

Et is so: Beide kommen wohl jetzt doch auch als Optionskarte für den extrenen Slot. Heißt SD Recorder raus und eine von den Karten rein. Machbar ist auch beide zuverbauen. Eine intern die andere über den Tasuch mit der SD Recorder Karte. Alles cool.

Weniger schön is halt, dat die Entwicklung beider Karten noch dauern werden und sie deshalb wohl nicht zum Verkauftsstart available sind.

LG
WW

Der Blitz schlug ein ... Die Frage ist auch ob sich einen extra Karte überhaupt lohnt, bzw. sich dafür einen bedarf ergibt. Wenn man das nicht so macht, das die für den externen Slot nur ein riser ist, der die Karte trägt die auch intern verbaut wird müsste man die Sache zwei mal konstruieren werden.

Zitat von Wurst Werner

MADI & ADAT kommt, wird dann ne Optionskarte, die man mit dem WING SD Recorder tauschen muss. DANTE & SG kommen als interne Optionskarte, die man über den Service einbauen lassen muss.

Genau hier runzle ich mit der Stirn.. Da kann man nur hoffen das die Waves über den externen Slot läuft und der Header ausschließlich für das Dante Modul verwendet wird. Vielleicht trifft jemanden im Hause Behringer noch der Blitz. Warum das mit Waves so lange dauert liegt wohl dran das diese die Karten bauen und das kann wohl dauern.

Dante intern und Waves extern wäre ja im Interesse des Anwenders.

Zitat von HenrySalayne

Wer liefert denn für 3000 € mehr? Also unabhängig davon, dass hier wieder Behringer auf der Kiste steht und man argumentieren könnte, dass das Pult dadurch gefühlt weniger wert ist.

Mehr ist immer relativ betrachtet.. Man hat aber anderes wie beim X32 damals jede menge Mitbewerber in dem Preissegment.

Wenn man den ganzen Schnickschnack mal weg lässt sehe ich keine Wahnsinnigen technischen Fortschritte. Auch keinen Grund mein GLD auf das Abstellgleis zu schieben, auch wenn es nicht in 7sec bootet.

Mal eine Betrachtungsweise. Warum sollte ich das Produkt kaufen ???

Wenn ich jetzt meine alte GLD-80 aus dem Jahr 2013 ins Rennen schicke gibt es kaum etwas was sich ihr gegenüber diesen Produkt abheben würde.

Geraucht bekommt man so eine GLD-80 inkl. Hardware für die Bühne für das selbe Geld nach geworfen.

Der Rausch der Innovation hält sich bei mir in grenzen...

Damals gegenüber dem X32 nur der Preis interessant, erkauft mit einem geringen Funktionsumfang. Stellt man jetzt ein SQ daneben gibt es nur wenig Argumente warum es nun eine Wing sein müsste. Für 3000€ liefern andere Herstelle mittlerweile mehr.

kann man machen...

https://www.neutrik.com/de/produkt/nc5fxx

Die Pins halten bis zu 7,5A Strom aus. Was 24V schon einige Meter wären. Spannung ist auch kein Problem < 50V. Die maximale Leitungsquerschnitt beträgt 1qmm.

wenn es schon XLR sein muss dann ewt. https://www.neutrik.com/de/produkt/nc4mxx

der macht schon 10A pro Kontakt und ist zur Strom inkl. Datenversorgung nicht unüblich. Verwechseln mit DMX ist durch die 4-pol Version nicht möglich. Aber auch die 5-pol Version sollte 24V auf egal welchen Pin überstehen. Die frage ist aber ob da Suppressor Dioden drin sind, die vermutlich dir dann auf den PIN 2-3 etwas kurz schließen. Welche Spannung sie bemessen sind, steht dem Hersteller offen.

Allerdings bedenke das DMX Kabel so Querschnitte von 0,22qmm bzw. 0x34qmm haben. 4x1qmm bekommt man in den XLR rein. Früher waren ja auch Lautsprecherkabel mit XLR üblich.

Dante/waves wird wohl über den expansion slot laufen.. Warum sollte sich dies ändern, jedes mal das Pult auf zuschrauben wäre wohl keine gute Lösung. Mit den internen Pin Header hält man sich Erweiterungen offen, die aus eigenen Hause entstehen könnten. AES67 oder auch AVB. Man hätte zwar auch mit dante AES67 aber nur mit 48khz, da es Audinate nur so implementiert hat. AES67 wäre gar nicht so dumm, da es im Broadcast Bereich weit verbreitet ist.

Anbei mal die SQLITE Datenbank.

Man kann sie mit jedem SQLITE Browser öffnen. https://sqlitebrowser.org/

Hallo...

so ich bin jetzt erst mal zu weit das alle Descriptoren in der Datenbank gespeichert werden. Allerdings ergibt das noch immer keine Sinnvolle Struktur ;). Der nächste Schritt ist jetzt zu schauen wie man die Tabellen untereinander Sinnvoll nutzt. Also als "KEY" ist die entity_id relativ ungeeignet da sie als BLOB gespeichert werden muss. SQLITE kann nicht mit unsigned 64bit umgehen. Besser man nutzt die ROW_ID aus der Tabelle ENTITY_LIST. Denn der Zugriff auf die DB dauert zu lange, ich kann dies nicht blocken bis diese fertig ist. Dann könnte es sein das wenn ein Geräte kurz verschwindet und wieder kommt das sich alt und neu nicht auseinanderhalten lassen. Es bekommt dann eine neue ROW_ID und ein Thread räumt dann alle Daten aus der DB auf die keinen Entity mit der ROW_ID zugeordnet werden können welches in meine linked List steht, diese ist atomar. So die Idee... So kann man wenn Zeit ist alle paar Sekunden schauen ob man die DB mal aufräumt und erzeugt nicht jedes mal große DB trafic..

Hmm also ich habe aus Interesse heraus diese Veranstaltung besucht https://www.proaudio.academy/index.php/naechstes-seminar.

Wirklich informativ fand ich die Beiträge von Andreas Hildebrand (ALC) und Stefan Ledergerber (Simplexity).

Zumal ich Festellen musste ich mich mit meinen Projekt der von NMOS https://amwa-tv.github.io/nmos/ nicht so weit entfernt liege.

Daraus hat sich ergeben das ich darüber nachdenken werde die AVB Geräte in einer NMOS Node zu Verfügung zu stellen. Um Geräte auch außerhalb der AVB Wolke zu koppeln müssten diese aber ein Streamformat implementieren welches RTP Streams auf UDP Basis anbietet. Genau das lässt der AVB Standard ja zu und ich werde dies in den xmos Stack einbauen. Schauen wir mal, in wie weit es gelingt AVB und AES67 Geräte per Flow zu verbinden.

Der Beitrag über AVB/Milan war er eine Enttäuschung, das man unter Milan gegen den IEEE Standard arbeitet ist von mir zu verurteilen. Milan sollte auf den Standard aufsetzen und in diesen zugelassene Erweiterungen nutzten. Für mich unklar warum man Header vom Protokoll eigenständig entgegen dem Standard verändert.

Das Controller Projekt "Hive" wird hochgelobt und dessen stellt er einige Dinge gar nicht oder nur unzureichend zur Verfügung. Der Standard hat mehr zu bieten als "Audio" Nur mein Projekt scheint der einzige Controller zu sein der auch mit "Video und Sensor" Units klar kommt und außerdem "control" vollständig unterstützt. Da mögen die RME Geräte dies auch unterstützen, es bringt nichts wenn kein Controller die Descriptoren und die Möglichkeiten zur Verfügung stellt.

Für mich war der Besuch der Veranstaltungen Motivation an dem Thema dran zubleiben und vor allen auch Ideen von Projekten aus der Praxis mitzunehmen. Um sie natürlich in mein Projekt umzusetzen ..

Filterbauteile sind teuer und die Filter selber wenn sie gut sind auch Aufwendig.

Früher war das teuerste der Trafo und die Leistungstrasitoren. Heute lässt sich mit billigen Bauteilen viel bauen und am Filter spart man eben so gut wie es geht. EMV ist ein weiterer Aspekt den der Filter erfüllen muss. Solche Verstärker machen sonst alles Platt was sich in ihrem Umfeld befindet. Die Oberwellen sind auch deswegen kritisch.

Beliebt sind sie nur weil sich durch diese Technologie Leistungsstarke, kompakte und billige Geräte bauen lassen. Genau das was die Branche verlangt.

Aus meiner Sicht haben sich Endstufen mit Schaltnetzteil und AB Stufe bewährt. Denn der Filter hat auch Nachteile im Dämpfungsfaktor und mit billigen Filter um so mehr. Z.Bsp viel zu geringe Querschnitte der Spulen usw.

Abgebrannte, defekte Geräte gesucht. Ich hätte hier einen Probanden wo je eine Seite durch ist. Eigentlich ein Fall für die Tonne, bevor ich aber anfange Stangen weise Transistoren zu kaufen und zu matchen hat jemand vielleicht im Elektroschrott etwas herum liegen. Kein kommerzielles Projekt, er zu Schulungszwecken. Wirtschaftlich nicht tragbar, deswegen nur Interesse beim akzeptablen preis.

1% entspricht der HIFI Norm und Lautsprecher haben deutlich mehr...

Wenn dir 0,1%THD zu viel sind dann beschäftige dich mal mit D- Class Endstufen bei 10KHZ . Da reden wir je nach Preislage der Filter um 10% und mehr und keiner stört sich wirklich daran.

Ich hänge man den aktuellen Workspace mit an...

Naja es würde mir ja schon reichen wenn jemanden über die API schaut. Ob man diese so verwenden und wie HATEOAS dort integriert werden kann. Meine Angst ist das ich aufgrund der Null Vorerfahrung etwas baue was mir gut gefällt aber von Ansatz her irrend wie nicht gut verwendbar ist. Die JSON API muss einen Status erreichen der Fix ist, bzw. die Regeln wie sie erzeugt werden.

Wenn als Ergebnis ein paar funktionale Seiten heraus kommen z.Bsp. (finden,auflisten und verbinden von Geräten) wäre das eine Tolle Sache. So muss ich an dem Thema nicht viel Zeit verlieren. Die File API ist ja schon seit langen integriert, der Controller ist also in der Lage den HTML und Javascript Code auch auszuliefern.

In Normalfall hat man für so etwas ein Team, mit dem man solche Dinge besprechen kann.

Das Problem ist er erwartet eine Bunter Oberfläche .. Da er auch verständlicherweise nicht die Technologie versteht... Wie ein Browser aus den zur verfügen gestellten Daten per Javascript und HTML5 genau das baut. Hierzu muss er dann auch keine Software installieren, einen Browser hat jedes Gerät.

Nicht nur das auch andere Geräte z.Bsp Sprachassistenten, Mikrocontroller ohne OS kommen mit der HTML Schnittstelle klar.

Sprachassistenten ?? Wer will mit seinen Mischpult reden .. Das nicht aber im Auto schon, wenn du die Sitzheizung hoch stellen willst und das Auto per AVB/TSN verkabelt wurde. HTML mit REST ist leicht in vielen Dingen zu integrieren.

Durch die Datenbank ist es möglich große Mengen an Geräten mit Eigenschaften zu verwalten. Auch von mehren Standorten. Bisher gibt es keinen Controller der über das Internet ins Layer2 funktionieren würde. Es gibt keinen funktionierenden im Standard vorgesehene Proxy und den braucht man auf beiden Seiten.

Zuletzt könnte das Projekt die Möglichkeit bieten AES67 mit AVB Geräten zu verbinden.

Der Controller könnte auch ein Display etc. besitzen. Von SD oder USB könnte man Konfigurationen in die Geräte spielen... Ja so etwas wäre möglich....

Das einzige Problem ist eben das ich mich alleine Abmühe und immer wieder neue Herausforderung auf einen zu kommen. Die gelöst werden wollen und ich dafür kein Cent bisher bekommen habe.

Jemand der mit HTML und Javascript gut umgehen kann wäre Gold wert... Dann könnte man auch nochmal über die REST API reden. Durch die Datenbank ergeben sich völlig neue Möglichkeiten.

Genau der baut eine simple Oberfläche, der Ansatzweise die Möglichkeiten aufzeigen. In der Hoffnung das dann die Dinge von alleine Fahrt aufnehmen.

So mal ein Einblick in das Thema Datenbank. Viola.. Jetzt ergeben sich völlig neue Möglichkeiten. Hier suche in der DB nach Geräten die den selben Modell Identifier besitzen.

Noch unklar ist ob ich die Descriptoren in je einer Tabelle ablege oder als Blob in einer pro entity.

Wenn man pro Descriptor Type eine Tabelle verwendet, ließen sich weitere Filter anwenden. Z.Bsp suche noch den gleichen Streamformat etc.

Nunja es ist deutlich komplizierter ;). Denn die IEEE 1722.1 beschreibt die Geräte umfassend. Genau das was bei AES67 und eben auch bei Dante fehlt. Mit der AES70 wird ähnliches versucht Geräte zu beschreiben und Steuerungsmöglichkeiten zu vereinheitlichen.

Es wird ein AVB 1722.1 Controller, der sich aber auch mit dem Mechanismen des AES67 ausstatteten ließe. Somit zu einen universellen Controller, der mit kniffen sogar in der Lage wäre AES67<-> AVB Geräte zu verbinden. Das Projekt könnte auf einer Switch laufen und somit auch SRP Attribute etc. anzeigen. Die REST API ist ja vorhanden und das Webinterface liefert den Controller gleich mit.

Zahlen muss laut jetziger Planung keiner etwas, trotz die vielen Arbeit.

https://www.l-acoustics.com/en/hotnews/l-a…s10-avb-switch/ kenne ich und ich vermute auch auf welcher Basis die Hardware basiert. Aus dem Grund bin ich gespannt, wie konform mit der Norm das Gerät wirklich ist. Angesichts der über 2000 Seiten nur beim Thema 802.1Q eine spannende Frage

Kurt entschuldige Bitte die schlechte Grammatik und wenn du etwas nicht verstanden hast frage einfach nach

Hier mal ein kleines update...

Ich arbeite ein einen Datenbank basierten speicher.... Da die bisherige Form alles in ein File zu schreiben den Anforderungen nicht mehr gerecht werden kann. Das Problem besteht vor allen daran mapping Tables zu speichern und wenn diese dynamisch erfolgen werden diese nicht einmal über einen descriptor beschrieben.

Das speichern und vor allen das suchen in einen unorganisierten File ist nicht gerade performant und zielführend. Sich darüber Gedanken zu machen wie es lösbar wäre verbraucht genau oder mehr Energie als gleich eine Datenbanklösung einzubauen.

Es wird doch eine SQL Lösung... Die Wahl viel auf sqlite https://www.sqlite.org..

Dadurch ergeben sich Möglichkeiten die dem Projekt sehr förderlich sind. Man könnte sich auch seine eigenen JSON oder XML Antworten zusammen bauen.

Da der SQL Syntax weitestgehend portable wäre eine Anbindung an eine externe Datenbank möglich.

Ich arbeite an den Tabellen um das DB tauglich umzusetzen. Funktionalitäten gab es erst mal keine, "unsolicited notification" funktioniert so lange sich die Daten in einen Descriptor abbilden lassen werden diese auch aktualisiert. Wer an den aktuellen Stand interessiert ist möge sich melden...

p.s der RPI läuft seit 3 Monaten durch ..