GO mit Rosegarden verbinden.

  • :-help: Hallo Freunde,

    ich bin mal wieder doof. Problem: Ich will den Sequencer Rosegarden (RG) mit GO verbinden zur Wiedergabe von Midi files (unter Ubuntu Studio). GO läuft allein brav mit virtuellem oder externem Keyboard. Aber sobald RG geladen wird ist der Ton weg. Ich schaffe es auch, RG soweit zu verbinden, dass die Tasten "klappern" (rot markiert werden), aber kein Ton. Versuche ich RG über Jack mit GO zu patchen, ist der Ton schon weg, wenn ich Jack starte.
    Stoppe ich den Jak Server, ist der Ton wieder da. Irgendwo stimmt meine Einstellung wohl nicht. Vermutlich klauen Jack und RG den Soundkanal. Ein Versuch, den Soundkanal per Jack ins System zu speisen, scheitert daran, das GO sich bei Jack nicht als Soundquelle zu erkennen gibt.

    Eine Alternative wäre ja der eingbaute Sequencer von GO. Der hat aber große Schwierigkeiten mit den MIDI Files und wehrt sich bei den meisten. Kann er einen File lesen, stimmt die Zuordnung zu den Manualen nicht. Die Pedalspur spielt auf dem Obermanual und die Obermanualspur auf dem Pedal (Burea Church). Die Kanalnummern der Spuren werden anscheinend ignoriert.

    hanko

    PS Habe grade festgestellt, das die selbe Datei im internen Sequencer bei der Demo Orgel richtig wiedergegeben wird, aber bei Burea Church die Manualzuordnung nicht stimmt. Sieht doch sehr nach falscher Einstellung aus. Ich werde jetzt einmal die Einstellungen für beide sichern und dann versuchen, die Burea so einzustellen wie die Demo Orgel. hanko.

  • Hallo Martin,

    dank für den Tip. der war die Lösung. Und so konnte ich gestern GO an einem Paar Backustik round 700 in der Kirche testen. Gewaltig! Merklich besser als Aeolus, selbst für meine Ohren. Getestet mit BWV 651 (war verfügbar) von Rosegarden auf Burea Church und Pitea MHS.
    Jetzt muss ich in die Registersteuerung einsteigen und dann das Organola anpassen. Dann kann GO im Gottesdienst erklingen.
    Habe aber Aeolus noch nicht ganz abgeschrieben. Will als nächstes ein Register aus einem Sampleset analysieren und dann in Aeolus modellieren und das Ergebnis mit dem Original vergleichen. Ich bin gespannt. Für eine geignete Modellierung von Mixturen hoffe ich auf die nächste Version, die vielleicht im Juli herauskommen soll.

    hanko

  • Hallo Freunde,

    so ganz komme ich mit GO noch nicht klar. Zunächst eimal, was ich erreichen will:
    Ich möchte GO im Gottesdienst an einem "automatischen Organisten" (Organola) betreiben (Näheres hier zu finden )
    Außerdem möchte ich Orgelliteratur mit Rosegarden abspielen.

    Der mir bekannte Weg, Verbindungen mit GO herzustellen, ist der Rechtsklick auf ein Element in GO, "Listen for Events" und den Event auslösen, z.B. auf einem Spieltisch durch Betätigen des Registerschalters. Für die Anpassung an vorhandene Spieltische die optimale Lösung, aber nicht für Sequencer. Dort müsste der gewünschte Event erst von Hand mit einem Midi Editor erzeugt werden und dann die Wiedergabe gestartet werden. Ein sehr mühsames Geschäft.
    Gibt es eine andere Möglichkeit, in einer Datei zu den Steuerelementen die zugehörigen Events von Hand einzutragen, und wenn ja, in welcher Form (numerisch, hexadezimal mnemonisch)?
    Welche Midi events werden von GO überhaupt erkannt? Werden SysEx erkannt und wie werden sie ausgewertet? Wird Running Mode unterstützt? Aeolus verwendet 2 aufeinander folgende Control Change NRPN LSB (98) zur Steuerung eines Registers.
    Grundsätzlich kann ich Organola beliebig konfigurieren. Wenn möglich, möchte ich aber die Kompatibilität zu Aeolus erhalten.
    Vielleicht kann mir jemand auf die Sprünge helfen.

    Hanko

  • Man kann die Events auch von Hand in den MIDI Dialog eintragen - die "Listen for Events" Funktion füllt den Dialog nur richtig aus (und liefert daher auch ein Muster, wie so ein Event in GO konfiguriert wird).

    SysEx ist in GO nur eingeschränkt möglich (dh nur einige von diversen DOs verwendete Nachrichten).
    Ctrl Change, Pgm Change, Note on/off, RPN und NRPN (+ einige merkwürdige Interpretationen davon, die man für diverse DOs braucht) sind in GO nutzbar.

  • Hallo Martin,

    danke für deine Antwort. Kannst du mir vielleicht einen Link auf eine Zusammenstellung der z.B.von Ahlborn verwendeten Nachrichten geben? Oder hast du eine Zusammenstellung aller von GO erkannten Formate?
    Die "merkwürdigen Interpretationen " lassen mich aufhorchen. Auch Aeolus fällt unter diese Kategorie. Für Registerschaltungen verwendet es NRPN, aber in einer ulkigen Form: es werden zwei aufeinander folgende NRPN 98 für ein Register verwendet, wobei das erste Byte auch noch 2 gepackte Informationen enthält: Siehe hier .
    Running mode ist dabei erlaubt.
    Meine Frage ist nur, ob bei den "merkwürdigen Interpretationen" etwas ist, was dieses Format auswertet. Dann ist wäre mein Kompatibilitätsproblem schon gelöst.

    Hanko

  • MIDI Running Status sollte kein Problem sein.

    Das Aeolus Format ist nicht mit GO nutzbar.
    Aeolus verwendet kein NRPN - es missbraucht die Kontroller-Nummer 98 (=NRPN LSB).
    Ein NRPN besteht aus NRPN MSB+NRPN LSB+ DATA ENTRY (eventuell auch LSB+MSB) - nur so wird es auch von GO verstanden.

    Meine Empfehlung für MIDI-Events:
    * Trigger (dh. Umschalten bzw Divisionals): PGM Ctrl (eventuell auch mit Bank Select LSB/MSB)
    * Senden von On/Off:
    * Note on/off
    * NRPN mit 0/127 als Wert

  • Danke Martin. Bezüglich des Missbrauchs stimme ich dir zu. Der Vorteil dabei ist, dass man ein Byte spart, der Nachteil, dass man außerhalb der Norm liegt.
    Noch ein paar Verständnisfragen:
    1. Ich nehme an, dass Windchest = Werk ist.
    2. Sind Divisionals und Generals Presets, wobei Divisionals nur auf das zugehörige Werk wirken (andere Werke bleiben unverändert), während Generals die Registrierung für alle Werke gleichzeitig ändern?

    Da unter den gegebenen Umständen eine Kompatibilität zwischen Aeolus und GO nicht zu erreichen ist, muss ich die Firmware meines Spieltisches ändern, was kein allzu großer Aufwand ist. Ein Wechsel ist dann innerhalb von Minuten durch Wechsel des Conrtrollers machbar. Für mich ist jetzt nur die Frage, welche Midi Nachrichten sehe ich wofür vor. Note on/off für Manuale/Pedal ist klar. Für die Presets dürfte es auch unproblematisch sein mit PgmCtrl, da jeweils immer nur eins aus vielen aktiv ist. Die Problematik liegt bei den Stops, da sie einzeln ein- oder ausgeschaltet werden müssen. Denkbar wäre CC NRPN MSB für ein und LSB für aus. Die Zuordnung zu den Werken dann über die Kanalnummer des zugehörigen Manuals. "Knöpfe", die nicht direkt in dieses Schema passen, ließen sich über eine eigene Kanalnummer zuordnen. Will man außerdem eine "toggle" Möglichkeit haben, ist man damit aufgeschmissen, weil eine dritte Schaltmöglichkeit fehlt. Ich käme mit diesem Schema hin, möchte mich aber nicht allzu weit vom Üblichen entfernen. Kannst du mir etwas empfehlen?

    Eine Variante, die aber wohl auch außerhalb der Norm liegen dürfte, wäre der Einsatz von Note/on Note/off mit den nicht genutzten Noten Nummern <36 und größer >96 für die Stops, vielleicht auch für die Divisionals, die ja beide über die Kanalnummer mit dem Werk verbunden sind. Damit wären immerhin z.B. 54 Stops und 10 Divisionals pro Werk möglich, was mir ausreichend erscheint.

    Ein noch etwas ratloser

    Hanko

  • 1) Windchest = Windlade
    2) Divisionals + Generals könnte man auch als frei Kombinationen bezeichnen.
    Divisionals sind auf ein Manual beschränkt. Alle Kombinationen in GO können aber auch scoped genutzt werden (vgl. Webcast von Lars Palo dazu).

    Pgm Change könnte man auch für "Toogle" verwenden. Wenn du mit Bank Select LSB/MSB sendest, hast du 2^21 Knöpfe pro MIDI Kanal.

    NRPN versteht du falsch. Es besteht aus 3 Ctrl Changes (NRPN LSB, NRPN MSB und DATA ENTRY).
    On + Off unterscheiden sich nur im Wert von DATA ENTRY.
    Mittels NRPN solltest du auf einen MIDI Kanal 2^14 On/Off Schalter bedienen können.

    Die Systematik ist von der GO Seite her egal.

    Persönlich würde ich ich kein Note on/off von den Manual/Pedal Kanälen für andere Zwecke missbrauchen, sondern einen freien MIDI Kanal extra dafür verwenden. So spart man sich Probleme, falls doch einmal eine Orgel mit größeren Tonumfang herauskommen sollte.

  • Nachtrag: Schau in das GO Devel Mailinglist-Archiv (@sf.net) Dort findet man neue Teil der Hilfe, die noch in Entstehung sind (was im Moment auch den MIDI Dialog betrifft).

  • Hallo Martin,

    danke für deine Geduld mit mir, aber ich brauche noch etwas mehr Unterstützung. Zum Verständnis hier meine Ziele:
    1. Ich will den Spieltisch in der Kirche von 1960 (noch kein MIDI!) mit GO ausstatten (Z.Zt. Aeolus.) Dazu habe ich eine Elektronik gebaut, die über USB Midi Nachrichten abgibt. Welche, kann ich per Firmware festlegen. Das läuft mit Aeolus seit einem Jahr gut. Als die Entscheidung für Aeolus vor 5 Jahren fiel, kannte ich GO noch nicht und HW war mir zu kommerziell). Der Spieltisch hat 2 Manuale + Pedal und 41 Registerwippen (+3 Fußschweller). Eine Änderung der Firmware für GO ist unproblematisch. Zur Zeit steht die Auswahl der GO Nachrichten zur Entscheidung. Dabei hast du mir schon viel geholfen, aber es bleiben noch weitere Fragen. Dazu weiter unten.
    2. Da unser Organist durch Krankheit häufig ausfällt und kein Ersatz verfügbar ist, hat die Gemeinde ein Organola von Ing. Holzapfel angeschafft, was gut mit Aeolus zusammen arbeitet. Eine Umkonfiguration auf GO ist machbar und unproblematisch.
    3. Meine Utopie ist, nach der Messe jeweils ein Stück Orgelliteratur vom MIDI File zu spielen. Als Sequencer habe ich z.Zt. Rosegarden im Visier. Natürlich erfordert das einiges an Anpassugsaufwand (den ja auch ein Organist an einer fremden Orgel leisten muss). Da mir auch noch vorschwebt, von Zeit zu Zeit die Orgel zu wechseln (wozu GO ja ideal ist) möchte ich den Aufwand so gering wie möglich halten. Dazu mein Thread "Midifiles für virtuelle Orgeln". Das folgende gehört eigentlich auch dahin: Ich tendiere z.Zt. dahin, die Zeitpunkte für Registerwechsel durch die Auswahl freier Kombinationen festzuhalten und die Anpassung an die Orgel in die Belegung dieser Generals zu verlegen und somit dem anpassenden Organisten zu überlassen. Als Hilfe für Nicht-Organisten schweben mir für verschiedene Orgeln eigene Spuren vor, aus denen Die Vorbelegung der Generals relativ einfach erfolgen kann. Für Aeolus hatte ich es so gemacht, dass ich in dieser Spur jeweils zu Beginn eines Taktes alle Register für das gewünschte Preset gesetzt habe und dann von Hand "Speichern" und "Next" gedrückt habe, wofür im Rest des Taktes genügend Zeit war.
    All diese Voreinstellungen befanden sich am Anfang der Spur. Waren die Presets eingestellt, wurde die Spur stumm geschaltet und die Spur mit den Programm Changes für die Auswahl des jeweiligen Presets aktiviert und alle Registerwechsel liefen automatisch. Und relativ leicht anpassbar.
    Und noch ne Information: Ich habe GO inzwischen auf 3 Rechnern fest installiert: 1. Auf der Orgel in der Kirche (2 Kerne, 1Ghz, 4GB Arbeitsspeicher, Ubuntu-Studio), 2. Auf einem baugleichen Rechner zu Hause für die Entwicklung, 3. Auf meinem 6-kernigen Hauptrechner (16 GB, neben 2 TB Festplatten 250 GB SSD für die Orgel), unter Ubuntu-Studio und WinXP. Ich nutze Burea Church in allen 3 Varianten und Pitea MHS. Auf allen gibt es keine Probleme.

    Nun zu meinen offenen Fragen: Habe ich das richtig verstanden:
    Ein NRPN besteht aus 3 Bytes:
    1. Status hier immer 0xBn (ControlChange), wobei n die Kanalnummer ist.
    2. Controller Nr soll hier 98 also 0X62 sein (NRPN Low Byte).
    3. Daten Byte 0 bis 127
    Bei prinzipiell gleichem Aufbau aber mit der Controller Nr 99 (0x63) würde ein NRPN High Byte angesprochen. Damit sind maximal 2^14 Wahlmöglichkeiten vorhanden. Will ich eine davon auswählen, muss ich natürlich beide NRPN abschicken, also 6 (oder im running mode 5) Byte.
    Nun die Fragen:
    1.Müssen beide NRPN dazu unmittelbar nacheinander folgen? Oder wird das High Byte gespeichert und es reicht verschiedene Low Bytes danach zu senden, sofern sich das High Byte nicht ändert?
    2.Wie funktioniert das Verbinden von Stops mit Midi Nachrichten? Durch Rechtsklick auf ein Stop öffnet sich das entsprechende Fenster. Hier kann ich jetzt "NRPN Range wählen", Channel ist klar. Ist "Off NRPN" number das Low Byte fürs Ausschalten? Dann könnte Value das High Byte sein? Eine andere Zuordnung erkenne ich momentan nicht. Nur funktioniert diese Interpretation in der Realität nicht. Ich habe mit Rosegarden in eine neue Spur die Nachrichten " B5 63 0 B5 62 1 " und einen Takt später " B5 62 0 " eingegeben. Damit sollte bei der Wiedergabe das entsprechend programmierte Register für die Dauer eines Taktes eingeschaltet und dann ausgeschaltet werden. Klappt aber nicht. Kann natürlich auch sonst eine falsche Einstellung sein. Ich bin einfach noch zu unsicher.

    Zu deinem Nachtrag: daran bin ich sehr interessiert, habe aber mit den etwas sparsamen Angaben nix gefunden. Kannst du mir bitte noch einen vollständigen Link schicken?
    Kennst du einen Midi Editor mit hrxadezimaler Eingabe?

    Danke für deinen Einsatz

    hanko

  • Den Inhalt der Kombinationen [wovon GO ziemlich viele Varianten im Angebot hat], würde ich in ein CMB File exportieren. Davon kann man auf einmal alle Kombinationen importieren.

    NRPN schaut so aus:
    Bn 0x63 parameter# MSB; [Bn 0x62 parameter# LSB;] Bn 0x06 data value

    Der passende Matching-Typ in GO wäre "NRPN".

    [vgl. https://sourceforge.net/p/ourorgan/mailman/message/32524773/ - den Inhalt des angehängten Patch solltest du lesen]

    PS: GO merkt sich die NRPN MSB/LSB für eine gewisse Zeit - bei längeren Abständen sollte man wiederholen.

  • Hallo Martin,

    Ich glaube, jetzt habe ich den Aufbau der NRPNs verstanden, jetzt muss ich das mal testen. Danke!
    Der erwähnte Patch scheint genau die Information zu enthalten, die mir bisher fehlte. Kannst du mir auch noch ein Programm nennen, das die Patches in lesbarer Form anzeigt? Im Editor ist es sehr mühsam die Information heraus zu fischen.

    Und wieder Danke für deine unendliche Geduld!

    Hanko

    • Offizieller Beitrag

    An dieser Stelle auch mal einen Dank an Euch beide, für immer wieder interessante Diskussionen :-thanks:

    Auch wenn ich und sicher auch andere Leser hier im Moment nicht allzu viel dazu beitragen können, weil es nicht aktuell meine bzw. unsere Problematik darstellt, so ist es doch gut zu wissen, dass man dies bei Bedarf hier im Forum alles nachlesen kann.

    Gruß Michael

  • Zitat

    Kannst du mir auch noch ein Programm nennen, das die Patches in lesbarer Form anzeigt? Im Editor ist es sehr mühsam die Information heraus zu fischen.

    Auf eine enduser-freundliche Version musst du noch warten, bis er fertig und integriert ist.

    Unter Linux hole dir die aktuellen GO Sourcen aus den SVN, dann kannst du mit

    Code
    git apply <patchfile>


    den Patch integrieren.

    Die gesamte Hilfe kannst du dann mit

    Code
    cd help
    dblatex grandorgue.xml


    in ein PDF umwandeln. git/subvesion/dblatex gibt es als Packete in allen großen Distributionen.

    PS:
    Wenn dir etwas an der bestehenden Hilfe oder den geplanten Änderungen auffällt, kannst du dich gerne auf der Mailingliste zu Wort melden. Ein anderer Blickwinkel kann nicht schaden.

  • @ Martin

    Es ist mir klar, dass du mich da tief in die Entwicklung riechen lässt. Deine Tipps probiere ich gleich aus (wenn nicht wieder das Telefon ständig geht).

    Zum PS: Ja, ich beteilige mich gern daran, aber vorrangig möchte ich GO vollständig am Laufen haben. Zum Blickwinkel: Alle Hilfen leiden daran, dass sie vorrangig alle Parameter auflisten und was da einzugeben ist. Ein Anfänger sucht aber meist ein Tutorial das ihm die wichtigsten (und ersten) Schritte vorkaut sodass er schnellstens ein Erfolgserlebnis hat. Und er sollte einen Überblick bekommen, was mit dem Programm machbar ist. Ich will mich gerne beteiligen, sobald ich etwas Boden unter den Füßen habe. Vorerst bin ich nur Nehmender.

    Gruß von

    Hanko

  • Hallo Freunde,

    nach längerer Pause endlich wieder dabei und mit alten Problemen konfrontiert..
    Da sich eine Konpatibilität mit Aeolus für die Registersteuerung doch nicht erreichen lässt, versuche ich jetzt bei GO die Register über CC 80 bis CC 83 zu zu setzen, was den Vorteil hat, dass ich nur 3 Byte für ein Register benötige.
    Aufbau der Message:
    1. CC 4 // Kanal 4
    2. 80 // CC 80
    3. Nummer // 0-63 für AUS, um 64 erhöht für EIN.
    Angeblich soll es sich bei den CC 80-83 um "General Purpose MIDI CC Controller / Generic On/Off switch 0 to 63 = Off, 64 to 127 = On" handeln (jetzt kann ich den verflixten Link wieder nicht einfügen. Alles wieder vergessen!. Aber daher habe ich die Info: http://nickfever.com/music/midi-cc-list
    Klappt auch mit der CC80 gut. Aber mit CC 81-83 klappt die Übernahme mit Rechtsklick, und event= Bx Ctrl Change fixed value -> Detect complex MIDI setup leider nicht. Der Event springt immer auf Bx Ctrl Change Bitfield und es werden die On und Off values nicht übernommen. (GO 1882, Ubuntu-Studio 14-04 LTS, Burea Church)
    Vorerst reichen mir die so verfügbaren 64 Registereinstellungen, aber die mit 80-83 verfügbaren 256 bieten mehr Reserve.
    Gibt es eine Erklärung dafür?

    Hanko

  • Detect Complex MIDI Event soll die MIDI Events von gängigen Geräten richtig erkennen. Da gibt es eine Reihe von Merkwürdigkeiten (wie man an den diversen Event-Typen erkennen kann). Die Erkennungslogik ist ein Kompromiss, der diverse Annahmen enthält.

    Wenn es Erkennungsprobleme bei "releventen" Geräten gibt, schaue ich mir die Sache an, ob/wie man etwas verbesseren kann.
    Wenn man bei Eigenentwicklungen unbedingt ein bestimmtes Nachrichtenformat will und die Logik es nicht richtig erkennt, kann man entweder die erkannten Einstellungen nachbessern oder auf ein anderes Nachrichtenformat wechseln.

    PS: Genug Platz bieten RPNs/NRPNs [für On/Off] bzw. PGM Change (mit Bank Select LSB/MSB) [für Push-Buttons].

  • Ich will meine Angaben noch etwas präzisieren.
    Das Format der MIDI Messages ist:
    1. Byte: 0xB4 // CC auf Kanal 4
    2. Byte: 0x30 // CC Nummer 80 bzw 0x31 bis 0x33 für CC Nummern 81 bis 83
    3. Byte: Schalter Nummer // Wert von 0 bis 63 schltet aus, um 64 erhöht schaltet ein.

    Mit kMidiMon wurde verifiziert, dass der Spieltisch exakt diese Folge abgibt. Zur Erinnerung:
    DerSpieltisch stammt von einer alten elektronischen Orgel mit 2 Manualen und Pedal von 1960. Die Elektronik wurde entfernt und nur die Tastenkontakte und Registerschalter weiter verwendet. Diese werden über lange Schieberegister in einen Atmel AT90USB162 Controller eingelesen, dessen Firmware daraus MIDI Messages macht, die über die USB-Schnittstelle des Controllers an den PC gesendet werden. Für Aeolus war das Format dazu vorgegeben. Dieses Format kann GO aber nicht verarbeiten, da es nicht normgerecht ist. Nun bin ich auf der Suche nach MIDI-Messages für das Setzen der Register. NRPN ist mir mit 9 Byte pro Register zu aufwändig. Mehr als 3 Byte sollten es nicht sein. So bin ich auf CC 80 bis 83 gestoßen, was angebich für Schalter vorgesehen ist. Damit sind 256 Schalter möglich, die mir völlig ausreichen. Nur klappt es mit den CC 81-83 nicht, während CC 80 funktioniert. Andererseits muss es nicht CC80-83 sein. Ich bin flexibel, wenn jemand einen anderen (bewährten) Vorschlag hat, hänge ich mich da gerne an. Aber den Leuten mit bestehenden Spieltischen sind solche Probleme natürlich fremd. So werde ich wohl wieder Martins Hilfe brauchen. Vielleicht kann er auch die unterschiedliche Behandlung erklären.
    Außerdem fällt mir grade auf, dass mich vom ursprünglichen Thema Rodengarten weit entfernt habe. Vielleicht sollten wir den Thead teilen und den Teil, der sich mit der auswahl der MIDI Messages befasst, zum Thema MIDI-Messages auslagern.

    Hanko

  • Ich habe mir die Ergebnisse eben nochmal genauer angschaut. Da ich beim Testaufbau zu Hause nur 7 Registerschalter zur Verfügung habe, sind die Möglichkeiten begrenzt, wenn ich nicht ständig den Mikrocontroller umprogrammieren will. Ergebnis:
    CC 80, 1/65; CC 81, 63/127; CC 82, 63/127 und CC 83, 63/127 werden von "Detect complex MIDI setup" richtig erkannt.
    CC 81, 0/64; CC 82, 0/64; CC 83, 0/64 werden als "CtrlChange Bitfield" eingestuft. Hier kann ich aber manuell den Event auf "Bx CtrlChange Fixed Value" einstellen und die Werte für "Off value" und "On value" eingeben. Nach Klick auf OK werden diese Registerschaltungen auch richtig ausgeführt. Mehr brauche ich nicht.
    Damit lassen sich also CC 80 bis 83 für insgesamt 256 Schalter nutzen mit nur 3 Byte MidiMessage, sehr viel effizienter als die umständlichen RPN/NRPN mit bis zu 9 Byte.
    Danke, Martin, Du brauchst in dieses exotische Problem nicht weiter einzusteigen. Ich bin mit den Möglichkeiten von GO sehr zufrieden!

    Hanko