Midi Kanäle zusammenfassen

nordcore schrieb:
Magst du mal näher ausführen, was da genau gemacht werden soll?

Kann ich machen, im Detail aber erst in zwei Wochen, da ich beruflich unterwegs bin.
Im Prinzip geht's darum, eine Art threshold zum min- und max-Wert zu schaffen. Ich melde mich dann.

Bernd

PS. nettes kleines Gerätchen :)
 
nordcore schrieb:
Magst du mal näher ausführen, was da genau gemacht werden soll?

Ok, back again.
Das Problem beim GEM ist folgendes: Das Sustainpedal ist ein Continous Controller, also ein Poti statt einem Schalter. Leider erreicht das Poti beim Treten des Pedals nicht immer den (korrekten) Wert 127, sondern ein paar darunter. Genauso beim Loslassen des Pedals: Es wird nicht immer #64=0 ausgegeben. Das GEM selber hat damit keine Probleme, das Nordstage hat dagegen eine sehr eigenwillige Interpretation von Sustain Werten, da Nord selber ein Pedal hat, welches kontinuierliche Werte liefert, aber halt mit seinem eigenen Wertebereich. Die Folge ist, daß einfach manchmal der Status nicht korrekt erkannt wird, Sustain hängen bleibt oder nicht ausgeführt wird. Sehr sehr lästig beim Pianospielen.

Im Logic habe ich eine kleine Korrektur gebastelt, die gewisse Werte wie folgt umwandelt:
(Alles ctlr #64)
0 bis 5 => 0
6 => 4
7 => 6
8 => 7
ab 9
bis 116 wird linear weitergeleitet
117 => 119
118 => 122
119 => 125
ab 120 => 127

also eine kleine Komprimierung der Werte am unteren und oberen Ende.
Damit kommt das Nordstage gut zurecht.
Ich habe aber nicht immer den Computer laufen, so daß ein kleines Hardware-Kästchen ideal wäre.

Lieben Gruß,
Bernd
 
serenadi schrieb:
Das Problem beim GEM ist folgendes: Das Sustainpedal ist ein Continous Controller, also ein Poti statt einem Schalter. Leider erreicht das Poti beim Treten des Pedals nicht immer den (korrekten) Wert 127, sondern ein paar darunter. Genauso beim Loslassen des Pedals: Es wird nicht immer #64=0 ausgegeben.

Das GEM selber hat damit keine Probleme, das Nordstage hat dagegen eine sehr eigenwillige Interpretation von Sustain Werten, da Nord selber ein Pedal hat, welches kontinuierliche Werte liefert, aber halt mit seinem eigenen Wertebereich. Die Folge ist, daß einfach manchmal der Status nicht korrekt erkannt wird, Sustain hängen bleibt oder nicht ausgeführt wird. Sehr sehr lästig beim Pianospielen.

... also eine kleine Komprimierung der Werte am unteren und oberen Ende.
Damit kommt das Nordstage gut zurecht.
Genauere Defintion des Nord-Stage Problems hast Du also nicht? Auch ob man nicht im Nord-Stage selbst irgendwelche Einstellungen anpassen kann? Falls nicht, war das evtl. sogar Absicht dies so schrecklich ungemütlich zu designen. Wäre eine Gaunermethode sozusagen. Oder im GEM selbst, kann man da auch nichts einstellen? Es gibt also drei Orte für potentielle Einstellungen: Start (GEM), Ziel (Nordstage), dazwischen (Thema).

Falls wirklich nur dazwischen eingestellt werden kann und soll, wäre vermutlich eine 'Userkurve' für CC64 ideal, so ähnlich wie auch im Bitstream 3X möglich: Einfach eine Tabelle mit 128 Zeilen, 0..127, mit entsprechenden Outputwerten. Usertabelle anpassen, update, fertig. Sollte dann so reagieren wie gewollt. Deine Logic-Lösung könntest Du direkt übertragen.
 
nordcore schrieb:
Der Quelltext wird mit dem Atmel-(GCC-)Compiler übersetzt, den gibt es als fertiges Paket bei Atmel zum kostenlosen Download. Ist relativ einfach zu installieren.
Die ("S"-Record-) Datei, die aus dem Compiler/Linker rauskommt, wird von einem kleinen Tool [1] in eine Sys-EX umgewandelt. Und die kann man dann einfach an den Controller schicken (MidiOx u.ä.), der brennt das dann in sein Flash: Update fertig.

[1] open source/GPL, Windows.exe gibt es von mir fertig, sollte sich aber auf jedem System übersetzten lassen, da nur "Datei rein => Datei raus"
Kann man das Tool irgendwo runterladen? Nein?
 
Ich weiß nicht, ob es schon irgendwo steht - ist aber pure Schlamperei, war bisher eher nicht nachgefragt.
Zip mit Eagle vom Board, Quelltexte für die 3 Projekte (YAMA selber, der Bootlader, und das Windows-Tool (ist das gleiche wie fürs MIDI-CV, der Bootlader ist auch relativ gleich, das *müsste* auch kompatibel sein, da YAMA ATMEGA328 hat MIDI-CV aber ATMEGA168 läuft der MIDI-CV-CODE orginal nicht auf YAMA (da muss ich noch minimal was ändern), der YAMA-CODE *sollte* auf beiden gehen, ist aber ungetestet. ).
 

Anhänge

  • YAMA.zip
    126,3 KB · Aufrufe: 6
Kein Problem.
Wie das ganze "im Prinzip" zusammenspielt, steht im Wiki zum MCV876 Controller-Update[1]. (Das ist aber ein MEGA88, dessen RESET-Pin nervigerweise als Signal gebraucht wird - ein paar Details sind also schon anders...)
Wenn etwas unklar ist, einfach fragen...

[1] https://www.sequencer.de/synth/index.php ... e#Software , Links im letzten Absatz abklappern!
 
Ich frage mich, wieso z.B. Spectralis nicht genauso seine Firmware updaten will/kann/sollte? C Programm schreiben, .hex generieren, in .syx umwandeln, senden, fertig. Geht nicht? Ging nicht? Sollte nicht gehen?
 
Das kann ich dir nicht sagen, allerdings ist der Specki natürlich 'n ganz anderes Brett, als die paar kByte Programm in einem Primitiv-Controller hier.
Das "ach so einfache" Midi-Syx senden zickt schon beim Jx3p (AFAIR um 30kByte) rum, ab ein paar hundert kByte dauert das unpraktikabel lange...
 
Wie lange? Bis zu 10 Minuten warten, wären doch akzeptabel, Kaffee trinken, und die Bytes wandern. Oder würde es noch länger als 10 Minuten dauern? Nur grob. Man muss ja nicht jeden Tag updaten.
 
TonE schrieb:
Ich frage mich, wieso z.B. Spectralis nicht genauso seine Firmware updaten will/kann/sollte? C Programm schreiben, .hex generieren, in .syx umwandeln, senden, fertig. Geht nicht? Ging nicht? Sollte nicht gehen?

Das ist nicht so einfach wie Du Dir das vorstellst. Bei MIDI darfst Du immer nur 7 der 8 Bits für normale Daten benutzen, alle MIDI-Bytes mit gesetztem MSB (Bit 7, also >128) sind Befehls-oder Statusbytes. Somit mußt Du die Firmware beim Umwandeln von Bin/Hex nach syx auch so wandeln, daß jedes Datenbyte nur 7 Bits hat. Dazu gibt's verschiedene Methoden, und jeder Hersteller hat da eine Andere genommen. Siehe entsprechender Abschnitt im Sounddiver Programming Manual auf deepsonic.ch.

Eine der Methoden ist zB daß immer von 7 Bytes das MSB oder LSB rausrotiert und in einem weiteren Byte gespeichert wird, sodaß 8 MIDI-Bytes den Inhalt von 7 Speicherbytes übertragen. Eine Andere überträgt die Bytes als Nibbles, also Hälften, auch da kann man HL oder LH senden.

Diese Bitschiebereien müssen auf der Gegenseite, also vom Firmwarelader in der Firmware bzw dem Bootblock des Flashroms, wieder rückgängig gemacht werden. Außerdem braucht's ja auch einen Zusatzaufwand, denn ein Firmwaeupdate ist ja, wenn über MIDI ladbar, eine Sysex-Datei also mit Header und auch Prüfsumme, wenn nicht sogar Handshake. Auch das muß alles in der Firmware codiert werden bzw gar im normal minimalistischen Bootblock, dessen Speicher oft sehr begrenzt ist.

Wenn man diesen Weg umgehen kann, zB bei vorhandenen Massenspeicher oder USB, dann tut man das auch, es spart einem nämlich dieses Verpacken der Bytes zum Versand über MIDI und auch damit einhergehende Timingprobleme, weil solche Dateien ja von den Meisten via Sequenzer in den Synth geladen werden und nicht mit einem Dump-Tool, welches keine Abspielgeschwindigkeit kennt.
 


News

Zurück
Oben