Brainstorm Ich möchte meinen eigenen MIDI-Sequencer programmieren

Wilde Suche nach Themen, Ideen …
noch mal was anderes zum thema "editieren" vs RAM.


es gibt ja datenmengen, deren größe stets gleich ist.

wenn man z.b. audio aufnehmen will, kann man zunächst das "wo" im speicher festlegen (adresse, name), und dann auch bis wohin. man reserviert also z.b. den ganzen speicher für eine minute aufnahme von anfang an.

sobald man das getan hat, ist eine tonspur jetzt bereits schon da, es ist nur noch nichts drauf außer nullen.
und man kann stundenlang daran herumeditieren und einzelne werte verändern, oder auch erneut bereiche einfach nicht benutzen und sie beim lesen auslassen, die größe des reserveirten/adressierten speichers bleibt immer gleich.

weiß man vorher noch nicht wie lange man aufnimmt, werden neue speicherbereiche in blöcken schrittweise neu zugewiesen. unter umständen sind diese sogar identisch strukturiert mit denen, die beim aufnehmen auf einen massenspeicher auch verwendet werden würden.


beim midi sequencer ist das ja nun anders. der könnte z.b. bei der logischen delta zeit 3 sekunden nach start die kompletten sysex bänke von 5 geräten gleichzeit losschicken wollen, oder 127 control change befehle auf einmal. während andere stellen im schnitt nur 0,1 note events aufweisen werden.

man kann also so ohne weiteres nicht einfach eine feste größe und auch keine maximalgröße festlegen.
auch willst du sich heutzutage unter umständen nicht auf eine fester zeitraster der marke "1920 ppq" begnügen sondern z.b. lieber mit ms in float arbeiten o.ä.


wie wäre es also damit: man unterteilt die speicher in kurze schnipsel, z.b. immer ein takt. wenn jetzt nach dem echtzeit-editieren, z.b. dem verschieben oder einfügen eines neuen ereignisses, aus irgendeinem grund die daten neu sortiert werden müssen, findet dieses sortieren nunmehr nur innerhalb einer sehr kleinen datenmenge statt.

wird durch das editieren ausnahmesweise mal irgendwo die vorläufig festgelegte größe überschritten, wird dafür ein zweiter block erzeugt.

die meisten datenbank anwendungen machen doch ähnliches, die haben blöcke oder chunks - und auch die von euch oben bereits angesprochenen temporären edit-buffer - und wird mehr platz gebraucht, werden neue blöcke erzeugt.
 
Zuletzt bearbeitet:
Das hier bei den aktuellen Prozessoren eine spürbare Latenz auftritt, kann ich mir eigentlich nicht vorstellen, aber vielleicht gehe ich zu sehr von Desktop-Prozessoren aus.

es war wohl ein arduino oder aehnliches als plattform angedacht.
da waere dann ram und rechenzeit schon eher knapp...
auf heutigen desktop pcs kann man sich ein wenig suchen sicher leisten.
ob das mit mpe und vielen control-parametern auf vielen spuren auch so bleibt?
hab ich aber auch nie durchgerechnet. prinzipiell faende ich eben 'random access' wie bei
einem stepsequenzer schon nett. etwa um midi genauso beahndeln zu koennen wie audio bei einem "beatslicer".
 
Nein, als rotierendes, segmentiertes Tetraeder.
Vermutlich sollte das witzig sein? Auf jeden Fall sehr qualifiziert.

Wer vor Komplexität bereits im Vorfeld kapituliert, sollte es vielleicht auch einfach ganz lassen und seine Zeit anderweitig sinnvoller verbringen?
Ok, also wenn Du das sagst, dann ist da wohl was dran. Dann lasse ich einfach die Finger davon. Ich höre gerne auf Leute, die richtig Ahnung haben und wirklich gute Tipps fürs Leben auf Lager haben.

Dann machen wir hier einfach dicht. Das ist ja sicher in Deinem Sinne
 
Vermutlich sollte das witzig sein? Auf jeden Fall sehr qualifiziert.
Nun, für mich war die Aussage, auf die sich der Kommentar bezog, recht eindeutig. Deswegen verwirrte mich dein Nachfragen, und ja, das war genau aus dem Grund eher ein Spaßkommentar.

Ok, also wenn Du das sagst, dann ist da wohl was dran. Dann lasse ich einfach die Finger davon.

Meine Aussage ging in die Richtung: wie viele Sequenzer mit MIDI 1.x existieren bereits? Wie viele braucht die Welt wohl noch? Wäre es nicht sinnvoll, sich gleich einen Schritt weiter zu trauen, wenn man sich schon als "guter Programmierer" bezeichnet? Aber selbstverständlich darfst du gerne den 100.000.00x-ten 1.x Sequenzer schreiben und hoffen, dass der so gut wird, dass den tatsächlich jemand benötigt.

Liegt mir fern, Leute vom Programmieren fernzuhalten, zumindest in einem Bereich, der mit Musik zu tun hat. Gibt Schlimmeres, was man mit seiner Zeit anfangen kann.
 
wie viele Sequenzer mit MIDI 1.x existieren bereits? Wie viele braucht die Welt wohl noch?
Welche ohne faule Kompromisse und dafür mit sinnvollen Funktionen. Aktuell kaufbare reine MIDI Sequenzer gibts nicht so sehr viele, und so einfache wie geniale Geräte wie Kawai Q-80(EX), Roland MC-50 oder Alesis MMT-8 sucht man heute vergebens.

Alesis MMT-8 mit seiner Bandmaschinen-Bedienung ist nach wie vor genial, dem fehlt allerdings Massenspeicher, er bräuchte mehr Tracks und mehr MIDI Ports, also mindestens mal 16 oder 32 Spuren, mit 3x MIDI OUT und 2x MIDI IN. Größeres Display und Encoder statt der plusminus-Taster. Ich hatte mal einen Entwurf einer Frontplatte gemacht …

Roland MC-50 hat diese genialen Drummaps, damit konnte man zwischen verschiedenen Geräten quasi konvertieren. Hat bis heute kein mir bekannter Hardwaresequenzer.

Kawai Q-80 mit seiner Matrixbedienung und dem Data Dial ist immer noch fein, vorzugsweise in der EX Version (steht noch hier, wird aber demnächst verkauft), denn die hat mehr Speicher, einen 2. MIDI OUT und kann sowohl DOS Disketten als auch MIDI Files verarbeiten. War mein erster Sequenzer und ließ sich trotz des Displays recht gut nutzen.

Ja, es gibt den Retrokits RK-008, der ein neuer MMT8 sein soll, aber MIDI als fuckin‘ Miniklinke geht einfach garnicht, jedenfalls nicht als alleiniger Anschluß.
Die ganzen anderen Dinger sind alle Lauflicht oder sowas, und wieder mit blöden Anschlüssen.

Was fehlt, ist ein klassischer MIDI Sequenzer mit einem echten Songmodus, also ein Modus, der nicht nur Pattern verkettet, sondern auch selbst Daten enthalten kann, sozusagen Linear sein kann. Das gab es zuletzt bei der Yamaha RS7000.

Lauflicht bzw. bunte Tasten-Sequenzer gibts reichlich, aber wenige mit klassischer Displayanzeige. Gut, 2x16 ist lange zu klein, ein Riesenbildschirm wie beim QY700 muß auch nicht sein, vor allen wenn er wie dort, so wenig sinnvoll genutzt wurde. Ein 240x64 wie beim Cirklon oder 240x128 dürfte wahrscheinlich völlig ausreichen, auch sowas wie das XL Display für die alten MPCs würde vielleicht auch noch gehen.

Was MIDI 2.0 angeht: das ist ein Computer2computer-Protokoll, also völlig überkandidelt für einen Hardwaresequenzer, da steht der Zusatzaufwand einfach in keinem Verhältnis zum Nutzen.
MIDI wurde als Protokoll für die Verbindung von Musikinstrumenten entwickelt und hat sich nun wirklich lange bewährt, MIDI 2.0 wird sich erst noch beweisen müssen.

Was die Programmierung angeht ist es vielleicht keine schlechte Idee, sich mal den Code von alten Hardwaresequenzern anzuschauen, das ist allerdings Assembler (8031 beim MMT8, 64180/Z80 beim Q-80 und beim MC-50). Die ROM Binaries sind ja im Netz zu finden (zur Not hab ich sie hier) und entsprechende Disassembler sind auch verfügbar, wenn man sich da ransetzen will. Hab ich früher viel gemacht und viel draus gelernt, allerdings fast ausschließlich 6502/6802/6803, mit dem Intelkram stand und stehe ich immer noch auf Kriegsfuß.

Bei den Daten würde ich ein Array immer einer verketteten Liste vorziehen, einfach weil es den direkten statt eines sequentiellen Zugriffs bietet, schließlich haben moderne CPUs genug Register, die man als Zeiger nutzen kann. Ich denke bei sowas halt immer noch auf Assembler-Ebene :)

Bei den CPUs würde ich nicht auf Arduino setzen, wie schon vom Kollegen weiter vorne angemerkt. Wenn man sich mal den MIDISeq anschaut, der inzwischen auf STM32 oder gar Neuer läuft und der Cirklon V1 mit einem STM32F103 mit 64MHz anfing und aktuell beim V2 mit STM32F767NIH6 mit 216MHz angekommen ist, lohnt es sich schon, bissl mehr Reserven zu haben, auch beim FlashROM. Die Dinger gibts ja teils als fertige Boards/Module, sodaß man sich nicht mit dem mit „Hausmitteln“ unmöglichem Löten von BGAs herumplagen muß.
 
Zuletzt bearbeitet:
Was MIDI 2.0 angeht: das ist ein Computer2computer-Protokoll, also völlig überkandidelt für einen Hardwaresequenzer, da steht der Zusatzaufwand einfach in keinem Verhältnis zum Nutzen.
MIDI wurde als Protokoll für die Verbindung von Musikinstrumenten entwickelt und hat sich nun wirklich lange bewährt, MIDI 2.0 wird sich erst noch beweisen müssen.

Korrekt. Darüber hinaus ist MIDI 1.0 eine Teilmenge von 2.0, weil die Rückwärtskompatibilität zum Konzept gehört. Da kommt man also keinesfalls drumherum.
 
Meine Vorstellung von einem MIDI-Sequencer wäre, dass es ein großes hochauflösendes Farbdisplay gibt. Touch muss nicht sein. Drahtlose Maus + PC-Tastatur für Beschriftungen der Spuren usw. sollten unterstützt werden.
Für MIDI-Spuren Ordner zum Gruppieren. Überlappende Patterns, Pianorolle, wo man mehrere Spuren gleichzeitig bearbeiten kann, wie z.B. Bass und Akkorde, oder Bass und Drums, oder Bläser-, Streicher-Sections usw.
Lauflicht finde ich für Grooves auch cool. Solche Patterns könnte man auf die Spuren legen und festlegen, über welche Takte welche Patterns spielen. Natürlich grafische Kurven für Controller usw. SysEx sollte man auch bearbeiten können. Tempo-Spur muss natürlich auch sein.
 
Was MIDI 2.0 angeht: das ist ein Computer2computer-Protokoll

es ist schon weit mehr als nur das, aber auch bei dem ganzen anderen zeug, was es noch so ist, brauchen das im moment eher nur wenige leute.

z.b. gibt es bislang keinen einzigen hardware synth, der tatsächlich in nennenswertem umfang von der höheren parameterauflösung gebrauch machen würde. ergo muss man das auch nicht sequenzen können. (oder generell so große pakete übertragen.)

man will den mist auch gar nicht lernen müssen. :) lieber sollte man wohl mal im herkömmlichen midi bereich rausholen was geht. da gibt es noch hunderte denkbarer features, die man sich wünschen könnte, die aber auch noch niemand gemacht hat.
theoretisch ganz simple dinge wie bestehende control change aufnahmen im nachhinein zu glätten oder zu quantisieren sucht man ja selbst in den meisten software sequencern vergebens.

wenn man in dem bereich - oder aber auch einfach bei der anordnung der knöpfe - besondere wüsche hat, hat man bereits einen guten grund sich einen eigenen zu bauen.
 
Ich habe noch keine Sequenzer programmiert, jedoch mit an nem UI und UX Design gearbeitet. Ich gehe jetzt implizit davon aus dass Du schon den Anspruch hast ein "Produkt" zu entwickeln weil dedizierte Hardware im Spiel ist. Aus dieser Perspektive würde ich empfehlen ein paar Fragen zu klären bevor es überhaupt um die Auswahl der Plattform geht:
- Was ist meine Zielgruppe? Studio oder Live? Nerdige Bastler oder ergebnisorientierte Musiker?
- Welche Probleme will ich lösen bzw. welchen Mehrwert soll das Produkt bieten?
- Wie erweiterbar soll die Funktionalität sein?
- Welches Bedienkonzept braucht es dafür?

Die Vorgehensweise beim Westlicht Performer finde ich sehr interessant, weil das UI gut von der Logik getrennt wurde. Somit gibt's davon sogar eine Version im Browser. Das Prototyping kann mit so ner Trennung auch viel effizienter erfolgen.
 
Ich werfe hier mal den Teensy in den Raum. Das ist ein arduino-kompatibler ARM-Chip, der eine gute Soundbibliothek mitbringt. Der Teensy ist spezialisiert für solche Projekte. Damit habe ich meinen eigenen Synthesizer entwickelt. Das Ganze wird in C++ programmiert. Auf Grundlage des Teensy wurde der Dirtywave M8-Tracker umgesetzt, der ja recht große Wellen schlägt. Als Standalone-Hardware hat so ein Sequencer durchaus Existenzberechtigung.

Als Plugin wüsste ich allerdings nicht so richtig, ob es Sinn macht. Es gibt ja tonnenweise Stepsequencer o.ä. ... schaue Dir mal Beat Scholar an oder den Hexcel. Die haben durchaus auch andere Konzepte. Für meine Arbeit ist vor allem das Clip-Prinzip aus Ableton und Bitwig unverzichtbar. Alles andere wäre mir zu unflexibel. Für Leute mit anderen DAWs wäre es sicherlich spannend, wenn es sowas als Plugin gäbe. Für Reaper hatte ich damals eine Lösung gefunden, aber das lief alles nicht zufriedenstellend.

Mit dem Umstieg auf Bitwig hat das Produzieren ein neues Level erreicht. Vor allem mit dem Push-Controller im Anhang - diese Verzahnung von DAW und Controller ist schon überragend. Allerdings habe ich auch keine Probleme mit der Pianorolle - im Gegenteil. Die stellt meine Musik visuell da. Beim Tracker sieht man nur Zahlen. Und auch bei vielen Hardware-Sequencern fehlt mir das visuelle Feedback.
 
den Code von alten Hardwaresequenzern anzuschauen, das ist allerdings Assembler (8031 beim MMT8, 64180/Z80 beim Q-80 und beim MC-50). Die ROM Binaries sind ja im Netz zu finden (zur Not hab ich sie hier) und entsprechende Disassembler sind auch verfügbar, wenn man sich da ransetzen will.
Könnte ich machen, wäre allerdings ein erheblicher Zeitaufwand, in dem ich vermutlich statt dessen auch zwei drei Konzepte rudimentär realisieren und ggf. wieder verwerfen könnte. Disassemblierten Code wirklich zu verstehen, ist zumindest für mich ein ganz erheblicher Aufwand (ganz abgesehen davon, überhaupt erstmal das ROM und den passenden Disassembler aufzutreiben und soweit zum Laufen zu bringen, dass das Disassemblat sinnvoll zu lesen ist).

Aber die ganzen vielen Vorschläge sind sehr hilfreich!

Du scheinst viel Fachwissen hinsichtlich diverser Hardware-Synths angehäuft zu haben:
Kawai Q-80(EX), Roland MC-50 oder Alesis MMT-8

Vielleicht könntest Du mir ein paar Zahlen der Geräte für einen anderen Thread geben?
 
Zuletzt bearbeitet:
Was ist meine Zielgruppe? Studio oder Live?
Studio

Nerdige Bastler oder ergebnisorientierte Musiker?
ergebnisorientierte Musiker

Welche Probleme will ich lösen bzw. welchen Mehrwert soll das Produkt bieten?
Unübersichtliche Funktionsvielfalt vieler Sequencer auf das Wesentliche reduzieren, das aber besonders gut (einfach zu bedienen, wenig Zeitafwand) hinbekommen.

Wie erweiterbar soll die Funktionalität sein?
Nicht für Anwender, nur für Programmierer

Welches Bedienkonzept braucht es dafür?
Ja, welches!

Vielen Dank @noir für die fundamentalen Fragen, die sicherlich verhindern können, dass das Ganze völlig aus dem Ruder läuft, denn niemand braucht die Eierlegendewollmilchsau, niemand kann sie programmieren und niemand will sie bedienen. Mehr davon!
 
Bitte keine MIDI2.0-Diskussion hier. Das kommt garantiert nicht!

Der große MIDI-Fehler wurde bereits in den 80er gemacht, als Sequential beim Prophet 2000/2002 für den MIDI Sample Dump 62.5kBaud verwenden konnte bei einigen Geräten mit einem kleinen Schalter hinten von 31.25kBaud auf 125kBaud (?) umschalten konnte (danke @microbug). Wenn da alle Hersteller mitgezogen wären, hätten wir bis heute mit MIDI weniger Probleme.
 
Zuletzt bearbeitet:
auch willst du sich heutzutage unter umständen nicht auf eine fester zeitraster der marke "1920 ppq" begnügen sondern z.b. lieber mit ms in float arbeiten o.ä.
float könnte etwas problematisch werden mit 24 Bits der Matisse bei positiven Zahlen. Ab Songlängen von 56 Minuten würde die Auflösung schlechter als 1/5 ms, so dass man mit einem 32Bit-Festkommaformat sowohl hinsichtlich der Auflösung als auch der Songlänge besser gestellt ist. Aber ob das wirklich relevant ist? Mit float rechnet es sich besser
 
@microbug Ja, danke für die Ausführung ...

Alesis MMT-8 mit seiner Bandmaschinen-Bedienung ist nach wie vor genial, dem fehlt allerdings Massenspeicher, er bräuchte mehr Tracks und mehr MIDI Ports, also mindestens mal 16 oder 32 Spuren, mit 3x MIDI OUT und 2x MIDI IN. Größeres Display und Encoder statt der plusminus-Taster. Ich hatte mal einen Entwurf einer Frontplatte gemacht …

OK, nach dem Ansehen einiger Videos sage ich: stimmt, sehr eingängige Bedienung. Was den RK-8 angeht: ja klar, Miniklinke ist nervig. Trotzdem tun es heutzutage so viele, leider.

Die anderen beiden habe ich noch nicht genauer angesehen.

Aber damit niemand sagen kann, ich könnte nicht ontopic ...

Wenn ich mir ein Konzept für so einen Sequenzer ausdenken würde, würde ich zweigleisig fahren wollen:
1. Supereinfaches Bedienkonzept, mit dem man schnell zum Ziel kommt und bei dem man die meisten Dinge möglichst einfach erreichen kann.
2. Alles Komplexe versteckt, aber trotzdem möglich, wenn man es denn benötigen sollte.

Was jetzt zu 1. oder 2. gehört, da lässt sich sicherlich drüber streiten und das wird vermutlich auch je nach potentiellen Anwender differieren. Warum also nicht eine Feature-Liste machen und die Anwender bis zum gewissen Grad mitentscheiden lassen?

Und ja, das bedeutet 2 Modi, zwischen denen mal notfalls umschalten kann, aber nicht muss für die meisten Dinge.
 
Zuletzt bearbeitet von einem Moderator:
Was jetzt zu 1. oder 2. gehört, da lässt sich sicherlich drüber streiten und das wird vermutlich auch je nach potentiellen Anwender differieren. Warum also nicht eine Feature-Liste machen und die Anwender bis zum gewissen Grad mitentscheiden lassen?
Ja, das ist natürlich eine wirklich gute Idee! Die Frage ist nur, wie viele erfahrene MIDI-Sequencer-Nutzer Lust hätte, da mitzuentscheiden. Und das wäre sicher eine Umfrage wert (z.B. Liste von Features... brauche ich dringend - kann weg). Allerdings traue ich mir nicht zu und würde auch nicht wollen, diese Liste von Features vorzugeben. Das müsste auch schon gemeinsam in einem eigenen Thread passieren:

1. neuer Thread: "Brainstorm: Welche Features sollte mein neuer MIDI-Sequencer haben" (da käme sicher auch schon genügend "könnte" zusammen)

2. danach neuer Thread: "Abstimmung: Ich benötige folgende Features in meinem neuen MIDI-Sequencer"
 
Solche Umfragen sind immer mit Vorsicht zu genießen, denn da will jeder alles haben (und hinterher beschweren sich dann diejenigen, daß es zu kompliziert zu bedienen wäre).

Ich würde mir die derzeit vorhandenen Sequenzer anschauen und das einbauen, was keiner sonst hat (und was es vielleicht früher schonmal gab wie Drummaps und besagter, echter Song Mode).

Was auch bisher noch niemand eingebaut hat ist die Funktion "Tap with instrument". Sowas wünsche ich mir schon sehr lange für Livesessions, wenn man gerade zB ein Riff oder eine Kick spielt und das dann dem Sequenzer übergeben möchte, ohne das Spiel zu unterbrechen. Bei der Kick wäre es halt statt des tonlosen Tap Tempo einfach das gerade gespielte Instrument/Pad als Tap Tempo zu nehmen, bei einem Riff müßte man dann anhand des Timings analysieren, das könnte aber bissl knifflig werden.
 
Bitte keine MIDI2.0-Diskussion hier. Das kommt garantiert nicht!
Herzlichen Dank!

Der große MIDI-Fehler wurde bereits in den 80er gemacht, als Sequential bei einigen Geräten mit einem kleinen Schalter hinten von 31.25kBaud auf 125kBaud (?) umschalten konnte.
Das war beim Prophet 2000/2002 für den MIDI Sample Dump, da konnte man die Baudrate verdoppeln, also auf 62,5Kbaud. Das ging aber auch nur, weil der Prozessor in diesen Samplern (iirc 6809) damit umgehen konnte, bei den anderen Geräten, die alle mit 8031/8048, Z80 (und Deviraten) oder 6803 arbeiteten wäre das unter Umständen eng geworden, gerade wenn da nur ein einzelner Prozessor werkelt.
Wenn ich mir aber dann meine MIDITemps anschaue, die auf einem 6502 basieren, kommen mir an meiner eigenen Theorie gerade wieder Zweifel :)

Daten der genannten Sequenzer kann ich gerne bereitstellen, mit Ausnahme des RK008, den ich nicht besitze, weil er die blöden Miniklinken hat. Ich hab aber MMT8, QY700, MC-50 gehabt, genau wie RM1x, RS7000, MPC2000XL, MPC2500 und aktuell noch einen Q-80EX, und ich habe zu vielen von diesen entsprechende Artikel hier bei mir vorbereitet.

Bei den ROMs und Disassemblern kann ich sicher auch helfen, wenn das eine Option sein sollte, zumal ich von den meisten Geräten auch die Servicemanuals besitze.
 
Zuletzt bearbeitet:
Solche Umfragen sind immer mit Vorsicht zu genießen, denn da will jeder alles haben (und hinterher beschweren sich dann diejenigen, daß es zu kompliziert zu bedienen wäre).
Kann man ja auch gewichtet machen, oder anders ausgedrückt, den Aussagen von Leuten mit nachweislich mehr Ahnung in dem Bereich auch entsprechend höheren Wert beimessen.
 
nachweislich mehr Ahnung in dem Bereich
Schwierig. Vielleicht besser sie selber gewichten lassen "Brauche ich für meine Arbeit, aber nicht ganz soo dringend".

Das war beim Prophet 2000/2002 für den MIDI Sample Dump, da konnte man die Baudrate verdoppeln, also auf 62,5Kbaud
Danke für die Korrektur, ich konnte mich nur noch wage erinnern (damals entsprach das meinem Wunsch und ich habe dem wohl zuviel Gewicht gegeben).

Selbst der C-64 mit seinen 985kHz hatte sogar im Running Mode 625 Takte Zeit, um die Noten für den nächsten Zeitslot vorzubereiten. Keine Ewigkeit, aber bei geschickter Assembler-Programmierung (und die gab es damals zuhauf) für 16 MIDI-Spuren machbar.

Ich mache hier mal Stop, da wir sonst zusehr in Hardware-Nostalgie versinken (ich bin dafür leider auch anfällig). Aber falls ich die Zeit finde, mich in die innersten Abspiel- und Aufnahme-Schleifen einzuarbeiten, dann komme ich natürlich gerne auf Dein Angebot zurück:
Bei den ROMs und Disassemblern kann ich sicher auch helfen, wenn das eine Option sein sollte, zumal ich von den meisten Geräten auch die Servicemanuals besitze.
Du bist da einfach bemerkenswert gut ausgestattet.
 
Zuletzt bearbeitet:
float könnte etwas problematisch werden mit 24 Bits der Matisse bei positiven Zahlen. Ab Songlängen von 56 Minuten würde die Auflösung schlechter als 1/5 ms, so dass man mit einem 32Bit-Festkommaformat sowohl hinsichtlich der Auflösung als auch der Songlänge besser gestellt ist. Aber ob das wirklich relevant ist?

mit der länge hast du natürlich recht, aber das ließe sich ja durch die verwendung von delta time werten lösen. "durchnummeriert" werden ja maximal die beats und bars.

bei audio weiß ich das 32 bit limit für die sampleanzahl @rate auswendig, bei einer "sekundenuhr" hingegen bin ich gerade etwas verwirrt.... wie ist das eigentlich... äh...

nur zu meinem verständnis:
nehmen wir mal 16 bit als vergleichsgröße. mit 16 bit signed werten kannst du songs mit 32700 takten länge (mehrere wochen lange stücke) von jeweils 32700 beats machen (realistisch ist ein maximum von 32). das ist schon mehr als man braucht. mit float kannst du genau das gleiche machen, aber einzelne ereignisse viel exakter auf einem bestimmten zeitpunkt setzen.
die fehlende präzision ab der 6. dezimalstelle kann man für diese anwendung (physical midi out) einfach ignorieren, da wir vorm komma ja nicht mal auf 4 stellen kommen. wo genau tritt da ein problem auf?


Mit float rechnet es sich besser

genau, auch wenns nur gleich gut ist und dabei doppelt so lang, es ist halt irgendwie auch einfacher damit zu rechnen.
 
nur zu meinem verständnis:
Das ist nicht kompliziert: Ich möchte gerne SMF importieren und exportieren können. Also muss ich mindestens 480ppq verlustfrei verarbeiten. Das entspricht bei 120 BPM einem Zeitraster von 1,04ms.

Um nun Laden, Tempoändern und wieder Speichern ohne fehlerbehaftetes Zwangsquantisieren der Originaldaten durchführen zu können, sollte ich intern deutlich genauer als 1ms sein, also z.B. 0,1ms.

Dann brauche ich für eine Sekunde 10.000 Ticks und bei float mit 2^24 bleiben dann "nur" noch 1677 Sekunden, also 28 Minuten. Bei längeren Stücken würde ab der 28. Minute die interne Genauigkeit auf 0,2ms zurückfallen und bei über 56 Minuten auf 0,4ms.

Ich persönlich brauche nie mehr als 10..15 Minuten. Aber falls das Ding auch noch andere verwenden wollen? Anwendung war Studio, braucht irgendjemand im Studio mehr als 56 Minuten?

Wenn höhere Genauigkeit wirklich erforderlich wäre, würde ich statt delta-Zeiten eher 32Bit-Festkomma oder 64Bit double verwenden.
 
Dann brauche ich für eine Sekunde 10.000 Ticks und bei float mit 2^24 bleiben dann "nur" noch 1677 Sekunden, also 28 Minuten. Bei längeren Stücken würde ab der 28. Minute die interne Genauigkeit auf 0,2ms zurückfallen und bei über 56 Minuten auf 0,4ms.

die rechnung kann ich nicht nachvollziehen, aber das hat vermutlich nicht zuletzt etwas mit der plattform und der sprache zu tun, und der tatsache, dass ich mit der "untersten ebene" und dem übersetzen von datentypen zum glück nichts zu tun habe.

der sinn von float ist doch nicht, nur die präzise darstellbaren werte zu benutzen. trennst du nicht gedanklich zwischen dem, was dargestellt wird und wie man etwas eingibt, und dem, was wirklich passiert? (klar sind counter immer int - aber es ist doch schöner werte in millisekunden einzugeben.)

vor meinem inneren auge sind positionen auf zeitleisten immer komplexe zahlen, die aus der position im raster und einem zusätzlichen offset/delay dazu bestehen. dann hast du z.b. eine clock, die o.g. int32 signed durchzählen kann, und eine art microdelay dazu, was im bereich von 0-1 immerhin auch noch mal auf 6 stellen hinterm komma präzise ist.

es wäre wirklich mal ganz nett zu sehen, wie das das ein oder andere industrieprodukt so macht.
 
vor meinem inneren auge sind positionen auf zeitleisten immer komplexe zahlen, die aus der position im raster und einem zusätzlichen offset/delay dazu bestehen.

Ne du, komplexe Zahlen sind was ganz anderes. ;-)

*Das ist ne Antwort für jeden, der auf der Suche nach "komplexen Zahlen" vom Google-Bot in diesen Thread geschickt wird. So kommen AIs übrigens zu so manch seltsamer Antwort.
 
Zuletzt bearbeitet:
Ich habe jetzt auch mal (wie @SynthGate) nach Youtube-Videos zu den Sequencern von @microbug gesucht und u.a. folgendes gefunden:


Aber ich muss sagen, das überzeugt mich nicht. Meine Wunschvorstellung geht tatsächlich eher in die von @Michael Burman:

- großes hochauflösendes Farbdisplay
- überlappende Patterns
- Pianorolle, wo man mehrere Spuren gleichzeitig bearbeiten kann, wie z.B. Bass und Akkorde, oder Bass und Drums, oder Bläser-, Streicher-Sections usw.
- geloopte Patterns auf die Spuren legen und festlegen, über welche Takte welche Patterns spielen
- grafische Kurven für Controller usw.
- Tempo-Spur
- (ev. für Spuren Ordner zum Gruppieren)

Irgendwo zwischen Supertrack und Creator vielleicht.
 
Ich habe jetzt auch mal (wie @SynthGate) nach Youtube-Videos zu den Sequencern von @microbug gesucht und u.a.
Ach Mann, ich kann mir kaum vorstellen, dass Microbug meinte, alles soll 1:1 übernommen werden, würde ich auch nicht. Nur vorkauen möchte ich dir das auch nicht, meine Zeit ist auch kostbar. Wir sind 30-40 Jahre weiter ...

Für 160€ die Stunde kannst du mich mieten, bei Vorkasse.
 
Zuletzt bearbeitet von einem Moderator:
Beim Q-80 meinte ich auch eher die Einfachheit der Bedienung, nicht das damals übliche Winz-Display.

Daß ein großes Display nicht automatisch eine bessere Bedienung ausmacht, sieht man sehr schön am Yamaha QY700. Die Bedienung erfolgt per Cursortasten, mit denen man übers Display navigieren muß, und ist im Gegensatz zu den Schwestergeräten mit gleichem Sequenzeraufbau (RM1x und RS7000) deutlich umständlicher.

Neben einer Tempospur sollte aber auch eine Signaturspur vorhanden sein, das haben die wenigsten Hardwaresequenzer (Geräte wie der Deluge oder Hapax lösen das über die Sequenzlänge), damit man auch entsprechende Wechsel bauen kann.
 
Aber ich muss sagen, das überzeugt mich nicht. Meine Wunschvorstellung geht tatsächlich eher in die von @Michael Burman:

- großes hochauflösendes Farbdisplay
- überlappende Patterns
- Pianorolle, wo man mehrere Spuren gleichzeitig bearbeiten kann, wie z.B. Bass und Akkorde, oder Bass und Drums, oder Bläser-, Streicher-Sections usw.
- geloopte Patterns auf die Spuren legen und festlegen, über welche Takte welche Patterns spielen
- grafische Kurven für Controller usw.
- Tempo-Spur
- (ev. für Spuren Ordner zum Gruppieren)

Irgendwo zwischen Supertrack und Creator vielleicht.

Würde ich so was anpacken wollen, würde ich das vermutlich über zwei verschiedene Geräte in Angriff nehmen:

> Einerseits den Sequenzer selbst, den man per Sysex so füttern kann, wie du es willst; der halt performant ist und ansonsten außer MIDI eigentlich nix kann.
> Und zweitens etwas, auf dem das UI läuft und Sysex-Messages an den Sequencer abschießt. Android mit TouchOSC zum Beispiel. Oder ein kleiner node.js-server auf nem Raspberry, der ein Webinterface zur Verfügung stellt.
 
Wir sind 30-40 Jahre weiter ...
Nicht was MIDI-Sequencer angeht, wie mir scheint.

Nur vorkauen möchte ich dir das auch nicht
Vorkauen finde ich auch nicht so lecker. Es geht hier nur um Brainstorming!

Würde ich so was anpacken wollen, würde ich das vermutlich über zwei verschiedene Geräte in Angriff nehmen:
Tatsächlich grüble ich da schon einige Zeit, denn problematisch ist aus meiner Sicht die Datenübertagung z.B. beim Editieren und gleichzeitigen Abspielen des Editierten sowie dem visuellen Feedback
 


Zurück
Oben