ultimativer Scancommander-Thread

    Hehe, so ne Nummer hab ich vor mittlerweile über 10 Jahren auch mal gemacht. 40-kanalige K3 wieder eingepackt, großes Siderack daneben. Analogmuco legen usw. war auch mal wieder ganz lustig. Ein-Knopf-eine-Funktion-mischen war echt mal wieder schön.

    Als ich dann aber spontan auf der A-Gitarre den Kompressor einschalten wollte und dann erst mal anfangen musste zu überlegen, ob überhaupt noch ein Comp frei ist, dann ums Pult rum, Dockhouse auf, Insertstecker suchen, patches, nur um dann beim nächsten Kanal wirklich keine Dynamics mehr über zu haben, wusste ich die Digitalwelt doch wieder irgendwie zu schätzen. 😁

    War dennoch ein sehr gemütlicher Abend.

    • Hilfreichste Antwort

    Moin,

    wie ich gerade aus gut unterrichteten Kreisen gehört habe wird MA zur Prolight & Sound in diesem Monat ein umfassendes Update für den Scancommander herausbringen. Was bisher durchgesickert ist:

    - neues, zusätzliches Mainboard auf Raspberry-Pi Basis

    - LCD Update: es wird ein farbiges, kapazitives Touchdisplay angeboten

    - Fader-Upgrade: die Intensity-Fader werden durch ALPS-Motorfader ersetzt

    So wie die geleakten Fotos aussehen findet das Raspberry-Board Platz neben dem weiterhin bestehenden Mainboard, welches dann nur noch die DMX-Ausgabe übernimmt. Die Netzwerkbuchse des Raspberry wird herausgeführt. Das Touchdisplay scheint eine Auflösung von 800x600 zu besitzen und passt nahtlos in das Gehäuse, lediglich das bestehende Deckglas muss entfernt werden vermutlich wegen der Touchfunktion.

    Am Interessantesten finde ich jedoch das Motorfader-Upgrade, angeblich sollen die Fader dann auch nicht mehr nur reine Dimmerfader sein sondern ähnlich wie bei der GrandMA "Executor"-Funktionen übernehmen.

    Das ganze ist wohl ein Projekt zum Thema Nachhaltigkeit in der Veranstaltungsbranche und wird maßgeblich von der Bundesregierung unterstützt. Wir dürfen gespannt sein!

    -skippa-

    Wer noch heute, und nur heute, bestellt, bekommt den Dongle zur Freischaltung des Licon2-Kompatibilitätsmodus gratis dazu 8o

    Nur zwei Dinge sind unendlich, das Weltall und die Dummheit der Menschen, beim Weltall bin ich mir jedoch nicht sicher. (Albert Einstein)

    Und wenn einnistet dieses Forums hier jetzt gut drauf ist, steht das Ding genau so in Frankfurt und das ganze Forum wird ungläubig schauen ;-).

    Ich würde nen scanco nehmen, der irgendwie auch mit z.B. Spiidern klarkommt. Man hat nicht immer zwingend mehr als 16 Lampen am Start.

  • DerNette 12. April 2025 um 18:46

    Hat einen Beitrag als hilfreichste Antwort ausgewählt.

    Moin,

    gestern war es mal wieder so weit, in einem Club in Kiel wurde zur "90er-Party" geladen. Und da ich wusste dass die einen Scancommander im Neuzustand liegen haben wurde der mal wieder rausgeholt. Absoluter Sammlerzustand - perfekt:

    trauma-002.jpg

    ich habe den dann zu den anderen Antiquitäten dazugestellt und die Scanner-DMX-Linie von "Martin LJ2" auf den Scancommander umgesteckt. Denn der Club hat als einer der wenigen 10 wunderbare Martin LED-Scanner1 im Rig. 2x Colorwheel, 2x Gobowheel, Prisma, Fokus, ultraschnelle Bewegung in 16-Bit, genau das richtige für den Scancommander:

    trauma-001.jpg

    und natürlich: Tunnelgobo! Es war ein schöner Abend :)

    -skippa-

    Moin,

    gab es eigentlich jemals Bestrebungen die PAN/TILT-Auflösung im Scancommander auf echte 16Bit zu erhöhen? Die Bedienungsanleitung spricht ja davon dass "dies bisher von wenigen Herstellern genutzt werde".

    scancommander-speed.png

    Waren Ende der 90erjahre aber 16Bit nicht schon gang & gäbe? Was wäre das wohl für ein Aufwand dies in Software zu gießen? Und könnte die CPU das überhaupt schnell genug rechnen? Was waren denn die Beweggründe (was für ein Wortspiel ;)) die PAN/TILT-Auflösung auf 1600 Schritte zu reduzieren?

    -skippa-

    Hi. Skippa,

    der Aufwand wäre enorm.

    Die SW wurde in Assembler geschrieben und der damalige Entwickler ist schon lange in Rente.

    Wenn ich ihn treffe, kann ich mal fragen, ob er sich noch an die Gründe erinnern kann 😅. Ist ja nur 35 Jahre her...

    Michael

    Da ich selber in den 1990ern den 68000 bzw den 68030 in Assembler programmiert habe, könnte ich mir vorstellen, dass einfach die Leistungsfähigkeit des 68020 der limitierende Faktor war. Multiplikationen waren extrem Takt(=zeit)intensiv, wir haben grundsätzlich versucht, Multiplikation durch arithmetical-shift Operationen, Additionen oder table-look-up-Verfahren zu erstetzen, um Taktzyklen zu sparen...

    Für Sinus- oder Cosinuswerte haben wir grundsätzlich bei Programmstart Look-up-Tabellen erstellt, um die Werte in 1/10tel-Grad-Schritten auslesen zu können. Echtzeit-Berechnung hätte einfach zu lange gedauert...

    Ihr müsst nur GUT spielen.

    Laut mach ich dann schon...

    Deswegen hatte der SC zusätzlich einen Floatingpoint Sub-Prozessor (MC68881), der diese Operationen in wenigen Zyklen gemacht hat.

    Für die echten X/Y Berechnungen sind viele Trigonometrischen Funktionen und Multiplikationen notwendig, die der MC68020 auch mit Lookup-Tabellen allein nicht rechnen konnte.

    Einmal editiert, zuletzt von madenau (15. Juni 2026 um 18:28)

    OT SaxoFOHn :

    Ui… jemand aus der Amiga-Scene hier?

    Ich habe den Wechsel vom c64 nie geschafft, weil keine Zeit. Assembler auf dem c64 war damals ein Spaß. Unsere „Zeitung“ hatte damals fast jeder in der Scene („Sex‘n‘Crime“)… und ja, es gab natürlich auch alternativ GenesisP… . Aber das vernachlässigen wir jetzt hier mal…

    Schon witzig. Ich liebe dieses Forum u.a. dafür.

    Zum ScanCo:

    Vielleicht lag es auch daran, dass die Geräte dann deutlich mehr Kanäle gehabt hätten. Es gab doch auch völlig unsinnige 16 Bit Anwendungen zeitweise,, abseits von Bewegungen.

    Ich habe übrigens nach wie vor noch einen im Lager. Allerdings zugegeben seit Jahren nicht mehr genutzt. Aber den gebe ich auch nicht her. Erinnerungsstück an alte Ursprungszeiten als mobile Disco Mitte/Ende der 90er :-).