CM5 - Sequencer Projekt.

[Moogulator]

viewtopic.php?p=356397#356397

und dann hier gucken:

https://www.sequencer.de/synth/index.php ... er_Projekt

Und?

 

[mc4]

Vielen Dank, Thomas , da hast Du eine wahre Fleißarbeit geleistet!

Ich habe ja schon zugesagt, hier mit einem Software Prototypen mitzuwirken, allerdings ziehe ich die nächsten Wochen um, was mein Zeitbudget etwas einschränkt.

 

[intercorni]

Schöne Arbeit!
Kann hier dazu diskutiert werden?
Ich hätte nämlich eine Anmerkung zu den Dreh-Encodern, die mit einem LED-Kranz ausgestattet werden. Wäre es nicht besser, jedem Encoder ein kleines Display zu spendieren, in dem der genaue Wert angezeigt wird?

 

[tho]

Schöne Arbeit!
Kann hier dazu diskutiert werden?
Ich hätte nämlich eine Anmerkung zu den Dreh-Encodern, die mit einem LED-Kranz ausgestattet werden. Wäre es nicht besser, jedem Encoder ein kleines Display zu spendieren, in dem der genaue Wert angezeigt wird?

Das haben wir hier auch schon diskutiert. Ich fände es auch besser so ein Miniaturdisplay mit 3 1/2 Stellen einzubauen. Dann könnte man Zahlenbereiche von -199 bis 199 anzeigen. Und dann habe ich nach dem Zeug gesucht.......und gefunden. Das willst du nicht wissen, was so ein Display kostet und ich will ja davon ja 16 pro Zeile einbauen. Wenn jemand eine Quelle für so Displays hat, dann her damit. Eine Quelle für Encoder mit LED-Kranz wäre mir auch lieb.
Gruß
Thomas

 

[Anonymous]

Die billigste Displaylösung sind wohl die LCD-Text-Displays, im Prinzip so, wie im Mackie Control oder dem Clavia G2.
LED-Anzeigen brauchen recht viel Strom (ist bei der Menge ein Problem). Bezahlbar ist das nur mit einzelnen 7-Segment-Displays und selbstgebauter Ansteuerung - die sind aber (mechanisch) eher zu groß.

Bei den Encodern-Kränzen vermute ich fast, das SMD-LEDs, selber auf die Platine gelötet, das billigste sind. (Eventuell nötige Plastik-Lichtleiter wären eher billig - vor allem wenn man genug davon abnimmt, ob es passende gibt weiß ich zwar nicht, wäre aber guter Dinge. )

Unser Frontplattenmensch baut zwar auch LEDs in Folienfrontplatten - aber dafür will er auch immer 'n Arm und 'n Bein haben, das kann man eigentlich nur für ein paar weniger LEDs/Gerät machen.

 

[Orphu]

Soll doch aber ein LC-Display rankommen ans Grundgerät. Warum dann extra noch welche für die Regler ? Bei der Midibox werden doch ebenfalls alle Zustände auf dem Display dargestellt. Reicht doch. Mit Einzeldisplays geht bloß der Preis in die Höhe. Bin kein Fan von sowas geht für mich nur in Richtung BlingBling-Controller.

 

[mc4]

Drehencoder

Falls jemand einen Tipp hat, welche Drehcodierer man einsetzen könnte, wären wir sehr dankbar dafür.

Thomas,
ich habe reichlich Soundwell Encoder hier, die auch die Leute im MidiBox Forum favorisieren.

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.

 

[mc4]

Harmonische Transposition

Harmonische Transposition

Für eine solche Funktion benötigen wir musiktheoretische Nachhilfe.

auch da habe ich beim Zyklus schon Grundlagenforschung betrieben und kann folgende Technik empfehlen:

Der Sequencer speichert keine Halbtöne, sondern einen Index auf einem Set von Noten ( in der Regel eine musikalische Skala). Dadurch kann einfach zwischen verschiedenen Skalen gewechselt werden. Im Standardfall nimmt man die chromatische Skala und hat seine 12 Halbtöne.

 

[intercorni]

Ich fände es auch besser so ein Miniaturdisplay mit 3 1/2 Stellen einzubauen. Dann könnte man Zahlenbereiche von -199 bis 199 anzeigen.

Ein Segment kostet um die 3,- Euro bei Farnell:
http://de.farnell.com/avago-technologies/hdsp-3901/led-display-0-8-he-rot/dp/1003303?in_merch=

 

[tho]

Die Displayproblematik

Hallo Leute,
die einzelnen Siebensegmentelemente hatten wir auch schon in Augenschein genommen, die sind allesamt zu groß. Ich möchte ja ein Display für jeden Regler haben. Ein breites Textdisplay für 8 Regler, also zwei in einer Reihe in unserem Fall, ist auch nicht gerade billig, aber noch am ehesten machbar. LCDs finde ich aber generell wegen der schlechteren Lesbarkeit nicht so toll, so ein breites Ding sieht auch nicht wirklich gut aus. trotzdem scheint mir das die einzige Alternative zu einem LED-Kranz überhaupt zu sein.
Der Kranz ist natürlich nicht so exakt wie eine numerische Anzeige, aber ich glaube, hier kommt es eher auf den Überblick an, denn der exakte Wert kann ja bei Betätigung des Regler im Hauptdisplay erscheinen.
Im Mackie Control finden sich auch LED-Kränze (zusätzlich), die mit 11 Segmenten etwas schlechter ausgestattet sind, als die von Behringer (15). Ich würde was drum geben, wenn ich diese Einheiten fertig kaufen könnte.
Übrigens: Stromverbrauch ist kein Problem. Auch 1000 LEDs auf einer Front können wir locker betreiben, denn wir werden dem Ding schon ein ordentliches Netzteil verpassen.
Es ist grundsätzlich kein Problem einen Satz SMD-LEDs auf der Leiterplatte zu platzieren, die sind auch bezahlbar, es ergibt sich aber ein rein mechanisches Problem. Wir haben einen Encoder, drumherum LEDs und wollen das ganze hinter einer Frontplatte unterbringen. Da müssen die Höhen schon stimmen. Der Encoder nimmt um die Achse ja schon einiges an Platz weg, da sind die LEDs schon ziemlich weit vom Schuss und dann braucht der Encoder auch noch eine gewisse Höhe, wodurch die LEDs ziemlich weit hinter der Font zu liegen kommen.
Und dann muss man noch durch die Front blicken können, damit man die LEDs auch sieht. Lichtleiter sind schon sehr lästig in dieser Menge und man sieht zumeist Kunststoffringe als Abdeckung, die auch nicht so leicht in die Front zu kriegen sind. Wenn es keine fertige Lösung gibt, dann müssen wir was basteln und aus einzelnen Komponenten zusammenstellen. Da kann ich Hilfe gut gebrauchen.
Die zentrale Frage ist also zunächst: Kranz oder Textstreifen???

 

[tho]

Displaygrab oder nicht

Soll doch aber ein LC-Display rankommen ans Grundgerät. Warum dann extra noch welche für die Regler ? Bei der Midibox werden doch ebenfalls alle Zustände auf dem Display dargestellt. Reicht doch. Mit Einzeldisplays geht bloß der Preis in die Höhe. Bin kein Fan von sowas geht für mich nur in Richtung BlingBling-Controller.

Das ist natürlich auch ein Argument. Displays bezahlen zu müssen, die nice to have sind aber nicht wirklich gebraucht werden, macht auch keinen Spaß. Ich bin bisher davon ausgegangen, dass gerade die Ausstattung das besomndere am CM5 sein soll. Aber es soll nicht unbezahlbar werden.
Ich denke, dass es interessant sein wird, Module mit entsprechendem Display an den Reglern zu haben und dass es auch welche gibt, die auf den Luxus verzichten und dafür billiger kommen. Man kann natürlich auf dem HAuptdisplay die Einstellwerte ablesen und wem das genügt, der kann auf den Aufwand verzichten.
Muss man sich mal Gedanken machen, was im Grundmodul drin sein sollte. Andererseits:
Finden wir eine Lösung für ein preiswertes Display/Kranz, dann ist es sinnvoll alle Comntroller so zu machen. Wenn ich sehe wie billig die Encoder mit Kanz von Behringer sein müssen, bei den Preisen, dann wir mir ganz komisch.

 

[Anonymous]

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 ?

 

[Anonymous]

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.

 

[Moogulator]

Hört sich das doof an, wenn man einfach ein paar BCR2000 ausschlachtet? Das kann man für den Preis nich selbst machen.

 

[Anonymous]

Hört sich das doof an, wenn man einfach ein paar BCR2000 ausschlachtet? Das kann man für den Preis nich selbst machen.

Man kann es nicht zu einem sinnvollen Preis verkaufen.

 

[tho]

Re: Drehencoder + Harmonics

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.

 

[tho]

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.

 

[tho]

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.

 

[intercorni]

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?!

 

[Moogulator]

Soll das denn eine Massenserie werden? Nein? Na, dann kann man immernoch die vielen gebrauchten BCRs ausschlachten, nä'wahr?

Achja. Bei den ganzen Features: Bitte Useability groß schreiben, das muss ein Musikinstrument sein.

 

[mc4]

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?

 

[mc4]

Re: Drehencoder + Harmonics

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

PM mir mal deine volle Adresse.

 

[TK]

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:

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.

 

[Hist]

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

 

[TK]

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.

 

[Hist]

Was sich in diesem Fall auf den Preis des µC auswirkt
Ansonsten ist die mögliche Geschwindigkeit ausschlaggebend.

 

[TK]

Was sich in diesem Fall auf den Preis des µC auswirkt

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.

 

[Hist]

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

 

[TK]

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.

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.

 

[Hist]

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