EEH Sequenzer Cm4 // Cm5 Konzept gemeinsam

wärs nicht ne überlegung das ganze so zu gestalten dass du 1 Dispaly hast in dem der jeweils aktive step jeweils dargestellt wird ?
Dann wärs aber cool wenn man ne optische rückmeldung hat wenn beim drehen des Encoders ein neuer wert eingestellt wird.
Direkt zu sehen wenn der Encoder beim drehen "greift" finde ich sehr wichtig.

Dazu aber in Displays gaffen zu müssen halte ich für nicht so optimal.
geht so ne "werteverstellungs" LED überhaupt ? müsste oder ?

Die (SMD-)LED-Kränze kann man auch gut auf eine eigene Platine setzen, dann hat man das Bauhöhenproblem nicht.

Die vielen Löcher in der Front könnte man durch eine Plexiglasfront vermeiden, allerdings dürfte eine Alufront mit Folie, in der die LED-Löcher mit durchsichtiger Folie "zu" sind auch machbar sein.

Ist nicht Low-Cost dürfte aber bezahlbar bleiben.

Ohne Anzeige pro Encoder finde ich viele Encoder nutzlos, dann kann ich auch gleich *einen* Encoder nehmen (mit fettem Pluspunkt der Luxusausführung) und dessen Funktion über viele Taster zuweisen.
Damit kann man dann wenigstens die Werte Abfragen ohne was zu verstellen.

Damit ist man aber vom Konzept des "tut so, als ob es festverdrahtet wäre" weg.

Ach und der BCR2000(Preis) - wenn man den will muss man BCR2000 kaufen und eine kleine Kiste mit Controller drin bauen, die den BCR als Benutzer-Oberfläche ansteuert/benutzt.
 
Zuletzt bearbeitet von einem Moderator:
seltsame Idee: Wenn man einfach ein paar BCR2000 ausschlachtet? Das kann man für den Preis nicht selbst machen.
 
Zuletzt bearbeitet:
Re: Drehencoder + Harmonics

mc4 schrieb:
siehe bei ucapps.de:
Bulk Order #3 of SoundWell rotary encoders (like ALPS STEC16B, "Voti" encoders)

Habe die damals für mein Zyklus Sequencer Projekt gekauft.
Kann dir für das Projekt gerne eine Handvoll schicken.
Wenn du die für geeignet hältst, wäre ich für ein paar Muster dankbar.

Zum Thema Harmonic:
Ich hatte mir schon vorgestellt, dass grundsätzlich immer in Vollauflösung gespeichert wird. Dann legt man sich Tabellen an, die bestimmen, wie die Werte ausgegeben werden. Normalerweise x=x. Beschränkt man die Werte darauf, dass die Einstellungen für alle Oktaven gleich sind, hat die Tabelle 12 Stellen. Cdur wäre dann 1,1,3,3,5,6,6,8,8,10,10,11 (ich hoffe man versteht was ioch meine). Cdur wäre aber auch 1,3,3,5,5,6,8,8,10,10,11,11.
Nett an dieser Methode wäre aber auch, dass man nicht nur einen Halbton nach oben oder unten kann, sondern auch komplett umsetzen, indem man zum Beispiel aus jedem D# ein A macht. Die ANzahl der Tabellen brauchen wir nicht zu beschränken.
Mit dieser technischen Umsetzung haben wir kein Problem und jeder Musiker kann sich seine eigenen Transformationen definieren. Aber es sollte natürlich auch sinnvolle defaults geben (die üblichen Scalen) und da kenne ich mich eben nicht aus.
Über die Art dieser Harmonisierungen (oder Deharmonisierungen, Transformationen oder wie immer man das nennen will) kann man noch diskutieren.
Auch ist mir nicht klar, ob es musikalisch nicht zu einseitig ist, sich auf die 12 Halbtöne zu beschränken. Wir können auch größere Tabellen schaffen und damit alle möglichen 128 Halbtöne beliebig umsetzen. Technisch gesehen ist es der gleiche Vorgang und macht nicht mehr Arbeit.

punky schrieb:
wärs nicht ne überlegung das ganze so zu gestalten dass du 1 Dispaly hast in dem der jeweils aktive step jeweils dargestellt wird ?
Dann wärs aber cool wenn man ne optische rückmeldung hat wenn beim drehen des Encoders ein neuer wert eingestellt wird.
Direkt zu sehen wenn der Encoder beim drehen "greift" finde ich sehr wichtig.

Dazu aber in Displays gaffen zu müssen halte ich für nicht so optimal.
geht so ne "werteverstellungs" LED überhaupt ? müsste oder ?
Also das konnte der CM4 schon. Der hatte für jede Zeile ein Zifferndisplay, das immer den Wert des Reglers angezeigt hat, den man gerade bewegt. Das war ein recht großes LED Display, auch für fast blinde noch gut ablesbar. Grundsätzlich wird das auch so bleiben, den Wert des bewegten Reglers wird man auch beim CM5 ablesen können.
Trotzdem ist es aber irgendwie super, wenn du gleich am Regler den eingestellten Wert sehen könntest, undzwar an allen gleichzeitig.
Mit Werteverstellungs-LED meinst du wahrscheinlich die Anzeige über einen Kranz, da ist man ja beschränkt. Wenn es dabei um Pegel geht oder cutoff-frequency, div. CC oder so, ist das völlig in Ordnung. Bei Tonwerten ist es nicht mehr so toll, aber auch da fällt mir was zu ein. Wenn man darauf verzichtet die exakte Tonhöhe zu erkennen, den Halbton kann man auch mit einem Kranz anzeigen, wenn der mindestens 12 LEDs hat. Hat man wie Behringer 15 davon, bleiben sogar noch drei für die Anzeige der Oktave. Nix für Anfänger, aber live super einsetzbar, weil du jede Stelle genau identifizieren und ändern kannst, auch wenn der Sequencer in der Zwischenzeit läuft.
Hier wäre ein Mini-Display natürlich besser, weils gleich die Notennummer zeigen kann, aber bei €40 pro Display mach ich lieber die Augen zu.

Fetz schrieb:
Die (SMD-)LED-Kränze kann man auch gut auf eine eigene Platine setzen, dann hat man das Bauhöhenproblem nicht.

Die vielen Löcher in der Front könnte man durch eine Plexiglasfront vermeiden, allerdings dürfte eine Alufront mit Folie, in der die LED-Löcher mit durchsichtiger Folie "zu" sind auch machbar sein.

Ist nicht Low-Cost dürfte aber bezahlbar bleiben.

Ohne Anzeige pro Encoder finde ich viele Encoder nutzlos, dann kann ich auch gleich *einen* Encoder nehmen (mit fettem Pluspunkt der Luxusausführung) und dessen Funktion über viele Taster zuweisen.
Damit kann man dann wenigstens die Werte Abfragen ohne was zu verstellen.

Damit ist man aber vom Konzept des "tut so, als ob es festverdrahtet wäre" weg.

Ach und der BCR2000(Preis) - wenn man den will muss man BCR2000 kaufen und eine kleine Kiste mit Controller drin bauen, die den BCR als Benutzer-Oberfläche ansteuert/benutzt.
Da ist viel Wahres dran. Eine Leiterplatte mit den LEDs, die über der eigentlichen montiert ist. Die Achsen der Drehcodierer ragen durch Löcher, die man da drin hat und damit kann man die Höhe so nivellieren, wie man es braucht. Die zweite Platine ist nicht wirklich so teuer, als wenn das ein Hindernis wäre und man hätte ohne Bestückungsvariante eine Version mit und eine ohne LEDs. Das wird wohl wirklich die beste Lösung sein.
Die andere Variante, Behringers zu kaufen und zu demontieren haben wir echt überlegt. Aber ich käme mir echt blöd vor. Wenn es da mal einen Lieferengpass gibt oder Behringer die Dinger einstellt ist für uns auch Feierabend.
Und es ist tatsächlich war: ohne Einzelanzeigen kann man auch gleich die einzelnen Encoder weglassen. dann geht wirklich auch eine Tastenreihe mit einem großen Drehrad.
 
Zuletzt bearbeitet von einem Moderator:
tho schrieb:
Fetz schrieb:
Die andere Variante, Behringers zu kaufen und zu demontieren haben wir echt überlegt. Aber ich käme mir echt blöd vor. Wenn es da mal einen Lieferengpass gibt oder Behringer die Dinger einstellt ist für uns auch Feierabend.
Vielleicht kann man Behringer Kontaktieren und die bauen einen gleich die bestückten Encoder-Platinen nebs LED Kranz?!
 
Soll das denn eine größere Serie (mehr als 50 Stk) werden? Nein? Na, dann kann man immernoch die vielen gebrauchten BCRs ausschlachten?
Achja. Bei den ganzen Features: Bitte Useability groß schreiben, das muss ein Musikinstrument sein.
 
Moogulator schrieb:
Soll das denn eine Massenserie werden? Nein? Na, dann kann man immernoch die vielen gebrauchten BCRs ausschlachten, nä'wahr?
.

Ich glaube irgendwo mal gelesen zu haben, daß die BCR Encoder und LEDs direkt auf der Haupt-Platine sitzen, also keine separaten Komponenten sind.
Kann das jemand bestätigen?

Re: Drehencoder + Harmonics

tho schrieb:
Wenn du die für geeignet hältst, wäre ich für ein paar Muster dankbar.

PM mir mal deine volle Adresse.
 
Zuletzt bearbeitet von einem Moderator:
Hallo,

zur Aussage:
Im die Diskussion von vorn herein einzugrenzen: USB sehen wir momentan nicht als Alternative für Ethernet an. USB klebt immer an einem Rechner, Ethernet verbindet in ein Netz (notfalls Internet), was wir deutlich universeller finden. PCs haben ohnehin immer beide Schnittstellen.

moechte ich eine Anmerkung loswerden: USB hat den wesentlichen Vorteil, dass es hierfuer einen standardisierten MIDI Transport Layer gibt, der von jedem gaengigen Betriebssystem unterstuetzt wird, so dass kein eigener Treiber entwickelt werden muss. USB-MIDI bietet (IMHO) die beste Moeglichkeit, virtuelle Instrumente mit einem Hardware Sequencer anzusteuern.

Folgendes Bild demonstriert die Performance recht eindrucksvoll. Ich habe mit meinem DIY Sequenzer jeweils 128 Note On und 128 Note Off Events gesendet, und mit Logic Audio (auf einem Mac) aufgenommen:

mbseqv4_tight_timings.png


Der linke duenne rote Balken besteht aus 256 MIDI Events, die ueber USB versendet wurden. Der Streifen ist 2 mS "lang". So macht die Ansteuerung von perkussiven Klaengen spass!

Beim zweiten Balken wurden 256 Events ueber einen UART Port bei normaler MIDI Baudrate versendet. Die Events sind auf Running Status optimiert, trotzdem dauert der Transfer 164 mS

Beim dritten Balken wurden 256 Events unoptimiert versendet (was fuer die Praxis relevanter ist, denn die Instrumente liegen sicherlich nicht auf dem gleichen Kanal)


Thema Ethernet: hier etabliert sich so langsam OSC als Uebertragungsstandard fuer Synth-Parameter. Auch hiermit habe ich bereits herumexperimentiert, bspw. um Instrumente in Reaktor anzusteuern. Bei Bedarf koennte ich auch hier mal Performancemessungen machen, doch sie ist bei weitem nicht so gut wie bei USB, zumal der Rechner durch die vielen Packete, die in Realtime geparst und weiterverarbeitet werden muessen, zusaetzlich ausgelastet wird. Auch der Mikrocontroller hat wesentlich mehr zu tun, es bleibt also weniger Luft fuer andere performancelastige Features.

Im Praxistest zeigt sich im Vergleich zu USB-MIDI eine zusaetzliche CPU Auslastung, die den Audio Output von Reaktor sehr schnell zum "knacken" bringt - aus diesem Grund sehe ich Ethernet lediglich als experimentelles Feature fuer Musikinstrumente; es ist hauptsaechlich relevant fuer die Vernetzung von MIDI Controllern, oder eben fuer diesen hippen iPhone-Kram.

Gruss, Thorsten.
 
Naja als Benutzer oder Programmierer würde ich ein gut definiertes OSC Inteface einem Sysex/Controller Krempel vorziehen.
Ausserdem ist GBLan verdammt schnell.
 
Hist schrieb:
Naja als Benutzer oder Programmierer würde ich ein gut definiertes OSC Inteface einem Sysex/Controller Krempel vorziehen.

Auch ich spiele gerne mit OSC herum, bspw. um von Reaktor aus die Oszillatoren und analoge Filter meines HW Synthies zu modulieren (der Pfad "/sid<sid>/<l|r>/<1|2|3>/direct/frq" laesst sich einfacher merken als abstrakte NRPN Nummern). Doch wenn ich merke, dass ab einer bestimmten Updaterate entweder der Rechner oder der Mikrocontroller wegen des zusaetzlichen Protokoll Overheads (und hiermit meine ich nicht nur den obersten OSC Layer) nicht mehr nachkommt, greife ich frueher oder spaeter dann doch lieber zu einer performanteren Loesung.

Ausserdem ist GBLan verdammt schnell.

Du verwechselst Uebertragungsgeschwindigkeit mit Verarbeitungsgeschwindigkeit.

Gruss, Thorsten.
 
Was sich in diesem Fall auf den Preis des µC auswirkt :sad:
Ansonsten ist die mögliche Geschwindigkeit ausschlaggebend.
 
Hist schrieb:
Was sich in diesem Fall auf den Preis des µC auswirkt :sad:

Sprich: lieber gleich einen EEEPC kaufen statt sich mit dem Mikrocontroller herumzuschlagen?

Ansonsten ist die mögliche Geschwindigkeit ausschlaggebend.

Jein.

Geschwindigkeit ist die eine Seite. Kompatibiliaet die andere.

In anderen Worten: mit USB-MIDI kann man derzeit jede mir bekannte MIDI Applikation ohne Kompatibilitaetsprobleme ansprechen, und die bessere Performance ist nicht von von der Hand zu weissen.

Um auf den urspruenglichen Thread zurueckzukommen: warum sollte man unter diesen Umstaenden MIDI ueber USB aussen vor lassen?

Falls dieses Posting zu aggressiv klingt: ich habe es nur gut gemeint! ;-)

Gruss, Thorsten.
 
Ne EEEPC hat ne Scheiß FPU ;-)
Falls dieses Posting zu aggressiv klingt: ich habe es nur gut gemeint! Wink
Kein Problem :)
Naja man kann für jedes OSC Interface ziemlich einfach einen Wrapper bauen der Midi ausspuckt. Von daher ist OSC auf jeden Fall auch kompatibel.
Wieviele USB Geräte kannst du an deinen Rechner anschließen? 3,4?
Danach brauchst du ein USB Hub, Geschwindigkeit ist dann auch nicht mehr so gegeben(wofür überhaupt die große Geschwindigkeit, denke der Seq gibt die Noten aus ).
Bei OSC holtst du dir einfach ein Switch, packst es an das Kabel vom Router und fertig.
Ist zwar alles schön und gut, aber im Endeffekt ist OSC teurer in Hardware einzubauen, und vor allem zu futuristisch für Musiker.
Für Hardware ist meiner Meinung nach der Standard, IN/OUT/THROUGH und USB Anschluss die gängigere, einfachere und preiswertere Variante.
Obwohl ich es schon cool fände meine Geräte irgendwann nur noch über GB-Wlan zu betreieben ;-)
 
Hist schrieb:
Naja man kann für jedes OSC Interface ziemlich einfach einen Wrapper bauen der Midi ausspuckt. Von daher ist OSC auf jeden Fall auch kompatibel.

Klar, deshalb hier auch nochmal der gleiche Test mit einem OSC->MIDI Proxy.

mbseq_osc_timings.png


Erster Balken: 256 MIDI Events ueber USB-MIDI (ca. 2 mS)
Zweiter Balken: 256 MIDI Events in 256 einzelnen OSC Datagrammen (ca. 46 mS)
Dritter Balken: 256 MIDI Events in 32 OSC Bundels (ca. 11 mS)

Was man hier nicht sieht: beim Versenden der OSC Datagrammen war der Mikrocontroller voll ausgelastet. Zum Einsatz kommt ein STM32F103, Cortex-M3 CPU, 72 MHz, Ankopplung an Ethernet via ENC28J60, 10 MBit/s.
Der OSC->MIDI Proxy auf dem Mac ist eine C Applikation die auf portmidi aufbaut.


Was natuerlich mal interessant waere: welche Bandbreite laesst sich mit anderen Mikrocontrollern realisieren?

Wieviele USB Geräte kannst du an deinen Rechner anschließen? 3,4?
Danach brauchst du ein USB Hub, Geschwindigkeit ist dann auch nicht mehr so gegeben

Der Hub, der zwischen meinem Sequenzer und dem Mac sitzt wirkt sich nicht auf die Geschwindigkeit aus. Ich nutze ihn u.A auch zur Spannungsversorgung der angeschlossenen Geraete, insofern eine praktische Loesung die durch einen Ethernet Switch nicht gegeben ist.

(wofür überhaupt die große Geschwindigkeit, denke der Seq gibt die Noten aus ).

Gerade bei perkussiven Sounds (bspw. Drums) ist es wichtig, dass Events moeglich gleichzeitig ausgeloest werden, ansonsten hakt es im Groove. Nun bietet OSC ja Timestamps mit denen sich der zeitliche Versatz ausgleichen laesst, doch dies fuehrt dann auch zu einer zusaetzlichen Latenz in der Sequenzer->Audio Kette... deshalb dann doch lieber Realtime.

Ausserdem ist eine hohe Bandbreite sehr willkommen fuer sanfte, interpolierte Parameterverlaeufe.


Ist zwar alles schön und gut, aber im Endeffekt ist OSC teurer in Hardware einzubauen, und vor allem zu futuristisch für Musiker.

Die OSC Option hat mich ca. 15 EUR gekostet ;-)
Teurer wird es, wenn der Mikrocontroller noch soviel nebenher erledigen soll, dass die Performance fuer eine Realtime Uebertragung nicht mehr ausreicht.

Auch fuer den PC/Mac muss man mehr investieren, denn der OSC Proxy lastet den Rechner bis zu +10% aus, obwohl er nicht viel zu tun hat, und direkt auf MacOS/POSIX Funktionen zugreift.

Da stellt sich natuerlich die Frage, ob man den Proxy nicht lieber in einem zweiten Mikrocontroller auslagert, und diesen via USB an den Rechner anschliesst... ;-)

Gruss, Thorsten.
 
15 Euro? Cool, aber was ist mit der Ethernet-Implementierung?
Einfach statische IP(oder DHCP)? Woher die Software, Kostenrahmen etc.
 
Hist schrieb:
15 Euro? Cool, aber was ist mit der Ethernet-Implementierung?
Einfach statische IP(oder DHCP)? Woher die Software, Kostenrahmen etc.

Fuer Ethernet verwende ich uIP als Grundlage, damit geht auch DHCP. Der OSC Layer kommt von mir (weil mir die vorhandenen Loesungen zu resourcenhungrig waren). Bezahlt habe ich fuer die Software nichts - DIY ;-)

Doch das wird langsam Off-Topic hier, vielleicht sollte man den Thread splitten.

Gruss, Thorsten.
 
Hallo Thomas Hopf,

wie schön, daß an einen Nachfolger des CM4 gedacht wird. Ich benutze meinen CM4 immer noch, aber auch der CM2 befindet sich im Umbau (neuer Prozessor,MIDI hat er schon, Realtime-Tranpose über MIDI-in, Speicher etc.)
Meine Idee an den CM5 : 1. Realtime-Tranpose 2. Stufenschalter zur realtime-Tranpose der einzelnen Steps (für jede Note einen Stufenschalter für Tonhöhe und ! Oktave). Dadurch wird es zwar eine breitere (2x19") Kiste, aber wer mit analogen Dinos arbeitet, hat ja genügend Platz ... Platz ... Platz... . Ich lasse gerade einen bereits vorhandenen Sequenzer entsprechend modifizieren ...
 
kleine Korrektur über den Werdegang der CM4:

ich habe damals zwei CM4-Sequenzer gekauft (einen von Reinhold Heil, der andere von ?). diesen zweiten habe ich dann an Frank verkauft, der natürlich ebenfalls gerne einen haben wollte.
Aus dem damaligen Studio von Chris Franke habe ich erst einmal testweise das große Projekt-Elektronik-Modularsystem in unser Studio geschleppt, zusammen mit den beiden Silver-Racks mit Moog-Voice,einigen Spezial-Drumcomputern (unter anderem mit Mäuseklaviatur), einem Gatetime-Verlängerungsmodul für die Cymbaleinheit im Chris.Franke-Drumcomputer, der heute von meinem CM2-angesteuert wird. Die Silverracks benutze ich (darin befindet sich u.a. auch noch der CM4). Das PE-Modularsystem (Stahlblech, ca. 400 kg schwer, 2,5 m breit) war leider nicht mehr komplett vorhanden, da viele Module (besonders die Moog-Sequenzer, Time-Controller u.a.) in alle Welt verstreut waren. Durch die interne Vorverpatchung (die Signale und Steuerspannungen aller Module wurden über spezielle Schaltmodule neben jedem ! Modul geroutet), war eine vollständige Funktionsweise nicht mehr gegeben. Ich nahm daher vom Kauf Abstand.
Bein Interesse, ich habe einige Bilder vom teilweise zerlegten System.
 
Danke für die Info, Mirko! Ich konnte nur das kolportieren, was ich selbst seinerzeit vor Äonen mal kolportiert bekommen hatte.

Und jetzt weiß ich auch, warum meine Anfrage bei Herrn Franke bzgl. des Projekt Elektronik Systems nie beantwortet wurde...

Stephen
 
wie gewünscht, hier einige Fotos
 

Anhänge

  • PE1 075.jpg
    PE1 075.jpg
    46 KB · Aufrufe: 154
  • PE-System 03 & Crumar GDS 02 htm.jpg
    PE-System 03 & Crumar GDS 02 htm.jpg
    89,5 KB · Aufrufe: 155
und noch eins ...
 

Anhänge

  • EEH Cm2-8 s.jpg
    EEH Cm2-8 s.jpg
    174,9 KB · Aufrufe: 157
  • EEH Cm4-5.JPG
    EEH Cm4-5.JPG
    89,4 KB · Aufrufe: 156
Ich faß´ es nicht, da steht ein Crumar GDS hochkant in der Ecke... fehlen nur noch die Töpfchen mit den Kakteen oben drauf, wie seinerzeit auf Rolf Trostels CS-80...

Was ist eigentlich jetzt aus dem CM-4(CM-5)-Clone geworden? Ich habe ein bißchen den Faden verloren, nachdem das Ganze wieder mehr in die Nerd-Ecke zu rutschen drohte und unnötig verkompliziert wurde, so von wegen modularem Aufbau, zipp und zapp, blah und blubb... da habe ich mich dann doch wieder ausgeklinkt.

Stephen
 
intercorni schrieb:
Schöne Bilder, danke :)

habe auch noch fotos von den modulen, sogar von hinten, wobei dann herauskommt, das die filter und vco*s, alles
andere wohl auch, ARP nachbauten sind. da hätte ich PE etwas mehr zugetraut. :shock:
 
intercorni schrieb:
moog2face schrieb:
habe auch noch fotos von den modulen, sogar von hinten, wobei dann herauskommt, das die filter und vco*s, alles
andere wohl auch, ARP nachbauten sind. da hätte ich PE etwas mehr zugetraut. :shock:
Würde mich sehr interessieren!!!

sieht schon fast übel aus. aber dieses ist auch das schlimmste.
 

Anhänge

  • IM000780.jpg
    IM000780.jpg
    120,8 KB · Aufrufe: 116
Erklärung zum GDS-System:

ich habe es vom Klaus bekommen (Keyboard-Teil,Computer und CBM-Monitor). Leider stellte es sich heraus, daß das ganze System total fertig war. Wenn man von den 8-Zoll !! - Disks den Synthesizer-Synthese-Teil lud und die Tastatur bediente, stürzte das System mit schöner Regelmäßigkeit ab (aufgrund diverser Verunreinigen wie Kaffee,Asche, Alkohol und anderer undefinierbarer Flüssigkeiten und Feststoffen). Dafür war mir der Preis, den Klaus haben wollte, dann doch zu hoch, zumal es auch niemandem gab, der das System hätte wieder un Schuss bringen können (ohne erheblichen finanziellen Aufwand). Ich bekam das Gerät in einer Sturm.- und Drangzeit, zusammen mit den beiden 19-Zoll-Silverracks, dem PE-System und weiteren 19-Zoll-Racks von Chris, als auch mit dem CM2-Sequenzer und dem Moog-Vocoder von Klaus (neben dem PPG-System und dem Arp-Odyssee+Arp-Seq. von Klaus). In der damaligen 1-Zimmer-Wohnung von Frank ging es hoch her, alle Synths (die eigenen als auch die Testgeräte) wurden an die Wände gestellt, während das riesige 2,50 m breite, 400-kg-schwere PE-System in die Mitte des Wohnzimmers gestellt wurde. Aufgrund des vorhandenen Gewichtes hatten wir erhebliche Bedenken, daß der Boden einstürzen würde. Er tat es Gott sei Dank ....... nicht !
Alle PE-Module mußten erst wieder eingebaut werden (wenigstens die vorhandenen), dann mußte noch Hartmut Heinze kommen (der das System damals mit gebaut hat) und das System in Gang bringen (aufgrund der internen Verkabelung aller !! Module kamen da mal locker 20000 !! Kabel zusammen !!
Nur wie gesagt, es fehlten alle Programmer, Sequenzer und Time-Controller, die wie erwähnt in alle Winde verstreut waren ...
Hartmut Heinze habe ich dann später noch mal benötigt, damit er mir den Arp 2600,den Peter Baumann von TD benutzte, den ich per Zufall bekam, dann aufgrund der vielfachen Modifikationen, die das Gerät besitzt, dann halbwegs in Schuss brachte. Dank auch an Riehl, der das Gerät schließlich komplett restaurierte...
Wie gesagt .. eine Sturm.- und Drangzeit, die ich dann ein paar jahre später erneut durchmachte. Mit dem Ergebnis. daß jetzt (fast) alle Oldie-Flagschiffe sich in meinem Besitz befinden (siehe Keyboards 12-2004). Dafür ist leider das Haus auf den Kap-Verdischen Inseln draufgegangen ...
 

Anhänge

  • Keyboards 12-04 Freaks at home 2as3.jpg
    Keyboards 12-04 Freaks at home 2as3.jpg
    65,6 KB · Aufrufe: 105
ICh erinnere mich, daß Rainer Bloss, der den GDS damals wohl häufiger spielte, seine Kippen immer auf der Tastatur ablegte, was dann irgendwann zur Folge hatte, daß alle Tasten von D bis G auf einmal mit runtergedrückt wurden. Und das Ding stank nach Bier, Cola, und Zigaretten.

Stoney Stockell in den USA hätte doch mit Sicherheit bei der Instandsetzung -- vor allem, was die Softwareseite anging -- mithelfen können.

Was ist eigentlich aus dem GDS von Franke geworden, der angeblich für den "Thief"-Soundtrack verwendet wurde?

Stephen
 


News


Zurück
Oben