Beiträge von guma

Zitat von "Karel Noon"

..zum einen die Akkulaufzeit meines Ipad1, das aber noch recht neu ist, kommt an seine grenzen, denn trotz des angeschloßenenen ladegerätes hat das Pad mehr Strom verbraucht als es aus dem Lader bekommen hat, ich muß noch mal genau überprüfen warum?!
bei den Letzten bands habe ich dann das Ipad zwischendurch ausgemacht, da ich es nur beim Umbau brauchte.

Das ist merkwürdig. Mein ipad akku hält gefühlt ewig ( ~10 - 12 h )

Zitat von "Karel Noon"

Außerdem hatte ich seltsame phänomene am pult in den EQs, das die nach drehen des Encoders relativ lange brauchten bis sie an die richtige (oder eben doch nicht richtige) position wandersten, sowohl gain als auch freq und Q. das war schon nervig,

Dieses Phänomen wurde schon mal von einem anderen user beobachtet ( finde gerade nicht die passende Stelle :? ) Da ich das nicht habe, ( stinknormale Fritzbox als Router ) würde ich auf den Router tippen. Vielleicht können sich ja mal die WLan Experten dazu äussern ???

Zitat von "oton"

Das können wir gerne machen. Bin allerdings drei Wochen unterwegs. Ich schicke es dir trotzdem mal zu....

Kannst Du bitte das file parallel auch noch zum support von Atlantic schicken, damit das wasserdicht wird ?

Zitat von "oton"

...Wenn ich das File habe schicke ich es dir zu, dann kannst du es dir gerne mal ansehen. Als ich abgebaut habe hat der Örtliche schon den Strom gezogen.

Besser wäre es, wir würden einen Termin machen gerne bei mir oder auch im Lager der PA-Firma. Möglicherweise kann man den falschen Schritt auch nicht dem file entnehmen sondern ihn nur entdecken, während Du ihn machst.

Zitat von "oton"

... aus meinem Delay wurde diesmal ein Chorus, das Ganze habe ich dann zurückprogrammiert, während der Show hat dann das Delay seinen Input verloren, dafür hatte ich rechts in der Dreierreihe Encoder dann gleich 4x das Delay, obwohl es in der Ansicht auf dem Screen weiterhin nur einmal existierte ....

Das, lieber Marcus, ist kompletter Unfug und hört sich nach 100% User-Fehler an. Du überschreibst Dir ständig Deine Effekte selbst. Ich denke, ich weiß auch, wie Du das machst. Gerne können wir das bei mir im Lager nochmals durchgehen. Bring einfach Dein "böses" file mit. :wink:
Dein Selbstbewusstsein in Ehren, aber dieses Mal ist es nicht das pöse, pöse Mischpult und der Schlußkommentar ist so ein bisschen vorschnell !

Schade, dass sich der Threadstarter von damals nicht mehr meldet. :roll:

Ich habe den alten Thread wieder ausgegraben, weil hier frei nach dem alten Zierenbergschen Motto: "Es gibt kaum schlechte Mikrofone aber öfter mal ein Mikrofon am falschen Platz" im europäischen Markt so eine strategische Totgeburt produziert wurde, wie man es dämlicher nicht machen konnte.

Das Mikro wurde 1978 auf den Markt gebracht, also deutlich nach SM57 und SM58, hier nochmal der o.g. link zur coutant Seite: http://www.coutant.org/shursm59/index.html.

Der Entwickler hatte wohl die Aufgabe etliche Eigenschaften gleichzeitig zu optimieren so eine Art "best possible dynamic".

- weitgehende Linearisierung des Frequenzgangs des Tauchspulenwandlers ohne die SM57/SM58 typische Präsenzanhebung vornehmlich durch Dämpfung und das Design des Hochtonresonators.
- milde Reduktion des Naheffekts schon durch die Größe des Einsprechkorbs
- bestmögliche Einhaltung der Richtcharakteristik über den Frequenzgang
- maximale Unterdrückung von Pop- und Körperschall

Das hatte allerdings zur Folge, dass der Wirkungsgrad b.z.w. die für Mikrofone angegebene Empfindlichkeit massiv unter den Abstimmungsmaßnahmen litt, sprich das Ding wurde durch die genannte Optimierung verdammt leise. Das wäre für einen stimmgewaltigen US Entertainer noch machbar gewesen, im europäischen Markt wurde das Teil allerdings für Kirchenbeschallung und Chorabnahme empfohlen ( wer wohl auf diese Idee kam :roll: ) leicht vorstellbar, dass dieses Ding für diese Aufgabe mit den dabei üblichen großen Mikrofonabständen, den Murmel-Usern und den bei Einführung noch zu nahezu 100% üblichen Breitband-Elasäulen selbst bei Rechtsanschlag der 100V Verstärkerchen kaum eine nennenswerte Verbesserung von Lautstärke oder gar Sprachverständlichkeit erzeugte. Kein Wunder also, dass es wieder in der Versenkung verschwand.

Aber:

Ist die Quelle laut genug, kann dieses Ding sogar ganz gewaltig punkten. So habe ich das mal vor einen Gitarrenamp gestellt, einen Trompeter hineinblasen lassen und spasseshalber auch eine Snare damit abgenommen ( die Platzierung dieses Kolbens war zugegebenermaßen nicht ganz einfach ) Was soll ich sagen ? An lauten Quellen macht sich die Arbeit des Entwicklers sehr positiv bemerkbar. Insbesondere ist dabei die von mir so oft geforderte Freiheit am Kanal-EQ also, die Eigenschaft, dass man nicht erst mal den Mikrofonfrequenzgang weg-EQen muß, maximal gegeben. Es wird die Umgebung im Sinne des maximal Machbaren ausgeblendet und auch extreme EQ-Einstellungen sehr gutmütig toleriert. Wer also mal über so ein Teil stolpert: Es macht wirklich Spaß, damit zu experimentieren, so könnte ich mir das Teil als Lösung für den einen oder anderen "Schreihals derr härteren Gangart mit Monitorschwerhörigkeit" vorstellen und das Design ist natürlich ein garantierter Hingucker.

Das mit der subnet Maske habe ich auch vorher im Manual gelesen und stumpf so gemacht. Bei mir waren die access violations nach Einschränkung des IP Bereichs nach den o.g. Spielregeln schlagartig weg... und zwar genau danach !

Für MAC User wird es in Kürze eine TI geben, sobald die da ist, mache ich die in irgend einer Form zugänglich.

Probleme mit Zahnfüllungen am besten im Zahnarztforum besprechen..... :wink:

Was ist denn nun aus dem guten Stück geworden ?

Natürlich gehört das prinzipiell so und der Weg über die remote ist ein 'workaround'. Ich kann mich noch sehr genau an mein dämliches Gesicht erinnern, als 1994 die erste CPU meines AMEK eine völlige VCA Grütze nach einem unerwünschten 'Steckerziehereignis' lieferte. Das gab allerdings nach einiger Zeit eine neue Prozessorplatine mit solidem Stromausfallsgedächtnis. Bis dahin mußte ich ebenfalls den Umweg über ein Läppe-backup gehen. Von daher bin ich, sagen wir mal, nicht verwöhnt.

Ich habe diese Art Havarie ohne USV oder Läppe-Backup einfach von vorneherein für meine bisherigen SD8 Gigs ausgeschlossen, indem es beide 'Vorrichtungen' bei mir gibt.

Meine Kritikpunkte gehen weiterhin Richtung 'Dokumentation und update -Politik'. So finde ich zwar im Manual den Hinweis 'USV benutzen', allerdings ohne Begründung oder Erläuterung, die dann jeder für sich selbst erforschen darf. Ebenso könnte man das bisschen Netzwerk-Einmaleins, das ich im Tipps-Thread in blau ergänzt habe auch in ein Manual-supplement schreiben, wie das andere Hersteller machen weil:

Bin ich Mischer, kaufe ich Mischpult, bin ich Hobbyinformatiker, kaufe ich SAC.

Jepp, da war der Jürgen sieben Tage schneller als der Frank. :wink:

So jetzt habe ich mal den Stromausfall mit angeschlossenem Remote-Läppe ( ...und intaktem Akku !!! ) simuliert:

Juhu das geht fabelhaft ! Der Läppe zeigt im Netzwerkfenster der SD8 Software zwar eine Fehlermeldung im Feld des vernetzten Pultes, diese verschwindet aber, wenn das Pult wieder Strom hat und durch einen einzigen click auf 'mirror to selected' wird das backup der letzten Pultsituation ins Pult zurückgespiegelt ohne dropout natürlich. Das finde ich völlig OK. :wink:

Und noch eine zweite Ergänzung zu Sicherer Betrieb eines "Consolen-Läppe" Netzwerks

Bitte den zweiten Nachtrag in blau in obigem Thema beachten !

@ billbo

Ich bin sicher, was das Rider-Thema angeht, Deiner Meinung. Allerdings hinkt dieses Beispiel insofern gewaltig, als dass eine geschäftstüchtige Party/Coverband in der Regel weiß, auf welche Jobs sie alles selbst b.z.w. Ihrem Kunden das Malermeister-Müller-Rundum-Sorglos-Paket für einen Preis XY mitbringt und und dann logischerweise keinen Rider schickt.

Für diese Band kann es aber trotzdem in manchen zugegebenermaßen seltenen Fällen sehr sinnvoll sein einen Rider zu haben:
Amateur-Veranstalter Verein XY bucht für 100000 Tausend Jahrfeier 3 Tage lang HKS Verleibude weil man kennt ja den Schorsch. Da kann es schon ganz sinnvoll sein wenn ein Band-Rider eine Art Verhandlungsgrundlage darstellt.

... und dann sind wir da natürlich wieder bei der 'my world - your world' Geschichte:
Der Herr oton bereut z.B. auch eine Cover/Party Band, die auch gern alles selbst mitbringt ( was natürlich den einen oder anderen Euro innerhalb der Gage ausmacht ) wenn sie das nicht soll, bei einer Mehrtagesfestivität, könnte das sehr sinnvoll sein, mal einen Blick in den Rider geworfen zu haben.

Zitat von "klauston"

Schon klar, aber wenn Du schon mal 3 Monate für die Lösung benötigst

Naja, man hat ja auch noch andere 'hobbys' als Pult-Läppe-Netzwerke.

Zitat von "klauston"

Ein Pult kann ( sollte ) doch nicht Programmierungen von Files zulassen, die es dann zum Absturz bringen.

Der Einwand ist berechtigt. Ich kenne jetzt aus der eigenen Erfahrung der letzten drei Monate nur diese 'access violation' meiner remote Netzwerk Versuche. Seit ich das richtig kann, habe ich auch keine 'acess violation' mehr. Wenn ein zweiter Rechner zum Pultrechner dazu kommt, haben aber auch andere 'Mischsysteme' ihre Probleme.

'Access Violation' bedeutet aber, dass Audio weiterläuft und dass es beim reset über den reset button an der Pultrückseite keinen audio drop out gibt und die software auf dem screen danach wieder normal weiter läuft. Das finde ich jetzt nicht so schlimm.

Man sollte also genau wissen, von was für einer Art 'Absturz' der Kollege spricht und wie es dazu kam.

@ oton
... äh, wie ich ja schon sagte: USV

Das Pult will sonst nach dem ( wieder ) Anschalten unbedingt eine session geladen haben. Was ich jetzt mal noch ausprobiere ist, ob ( seit ich das richtig mit der remote kann :wink: ) das 'send session to selected' und 'mirror' vom accugepufferten Läppe aus geht. Da Audio ja sofort wieder spielt, könnte man natürlich auch den tatsächlich letzten Zustand ohne 'drop out' vom remote Rechner schicken, wenn das Netzwerk sich wieder einwählt und vorher die remote im 'mirror' Betrieb lief.

Das kenne ich nicht von innen.

Zitat von "guma"

2. Rack/Mixengine nimmt gains nicht

Folgendes ganz und gar unhübsche Erlebnis:

Ich schicke dem local eine am Rechner generierte session. Dieser baut lobenswerterweise sein Festivalset darum und erzeugt darin ein snapshot mit meinem Kram. Nach dem soundcheck wird der snapshot intern und auf USB gespeichert. Beim Laden des snapshots aus dem internen Speicher zum start meiner show werden visuell auch alle Einstellungen resettet. Beim ersten Bandeinsatz kommt dann aber nur "warme Luft", was der local dankenswerterweise sehr schnell darauf zurückführt, dass das rack/die mix-engine die gains sämtlich nicht genommen hat. :twisted: :twisted: :twisted: :twisted: . Das Problem wurde dann so gelöst, dass alle gains von Hand ein bisschen bewegt wurden, damit das Rack versteht, das von der "Fernsteuerung Pult" jetzt bitte freundlicherweise die gainwerte zu übernehmen wären.

Das ist seehr schade !!!!!!!!!!

Ich bitte um eine Klärung der Ursache für diesen Fehler ( echter software-Bug, madi-Fehler, oder ... ? )

Menschliches Versagen schliesse ich dahingehend aus, dass bei Kontrolle der nach dem soundcheck gespeicherten session die 'scope' - Funktion für den snapshot nicht so eingestellt war, dass es den Fehler erklären würde. Dass der alte snapshot ( vor soundcheck ) geladen wurde, ist ebenfalls auszuschliessen, da die Werte ja richtig angezeigt wurden.

Alles anzeigen

Habe den Babysitter von damals nach Jahr und Tag wieder getroffen:

Jetzt hat er freundlicherweise gebeichtet, das er schlicht doch im snapshot recall scope die gains auf 'nicht recallen' geperrt hatte. Er hat das aber vor dem Speichern wohl wieder geändert, sodaß das in der an bertz geschickten session nicht mehr zu erkennen war.

Also: USERFEHLER !

Ich entschuldige mich hiermit bei allen, denen ich hier unnötig Arbeit oder Ärger bereitet habe !!!!

Jau, je mehr ich mich damit beschäftige, um so mehr komme ich zu der Erkenntnis, dass es sich bei sogenannten "SD8 Ausstiegen" in 99% um User-Fehler handelt. Einzig das bekannte Kompatibilitätsproblem von älteren Files mit der 3.00 Firmware ist ein echter Bug. Ich schreibe noch ein bisschen was darüber in den entsprechenden Threads.