FC-6 und FC-12: quod erat demonstrandum

axifist

Well-known member
Mitglied seit
Nov 14, 2013
Beiträge
1.921
Hi Leute!

Während ihr in Daxweiler euern Spaß hattet, hab ich das Wochenende (und auch schon einige Tage davor) genutzt, um meinen Arduino-basierten Footcontroller für mein bereits staubiges Ultra zu programmieren. Mein Hauptaugenmerk lag dabei eigentlich nur darauf, dem Teil sowas wie Scenes beizubringen, damit ich es eventuell doch noch sinnvoll nutzen kann, z. B. für ein reines Akustik-Rig. Scenes sind für mich ein elementares Feature und neben den Globals in allen Effekten für mich der Hauptgrund gewesen, das II zu kaufen.

Während dem Coden hatte ich aber immer verrücktere Ideen bzw. habe die noch immer. Noch hab ich nicht alles eingebaut und weiß bei manchem auch noch nicht, wie und ob ich es umgesetzt bekomme. Aber hab einen mords Spaß bei der Sache!

Den Thread hier möchte ich als Beweismittel nutzen ;) Und zwar bin ich tatsächlich mega gespannt, wie die beiden neuen Footcontroller für das III funktionieren, was damit möglich ist usw. Sozusagen mein Konkurrenzprodukt und eventuell auch ein Ideengeber. Was ich hier also vorhabe, ist, euch mal aufzulisten, was mit meinem Footcontroller bereits geht, um später, also nach ersten konkreten Infos über die Konkurrenz, beweisen zu können, dass ich die Ideen selbst hatte (und evtl sagen kann "Meiner ist besser!"):
  • Wenn ich auf dem Axe oder auf dem Footcontroller den Tuner aktiviere, zeigt es auf dem Footcontroller auch den Tuner an. Schalte ich den Tuner aus, verschwindet er wieder (eigentlich nix besonderes, aber war garnet so einfach zu implementieren!)
  • Unbegrenzte Anzahl an Scenes inklusive der Option, ihnen Namen zu geben. Die Anzahl Scenes pro Song sind auch konfiguriert.
  • Funktionszuweisung für die Expressionspedale für jede Scene individuell möglich (z. B. nur beim Gitarrensolo macht das Pedal ein Wahwah, ansonsten ... was anderes)
  • Funktionsart der Switche pro Scene zuweisbar, also Momentary, Toggle, ToggleOnRelease (beim Loslassen wird die Aktion ausgeführt) (damit kann man sich evtl Switche sparen und den Footcontroller entsprechend kleiner gestalten)
Was noch kommen wird ist:
  • Unbegrenzt viele Setlisten speichern.
Eventuell ein ganz spezieller Gig-Modus:
  • Nen Gig durchspielen können, indem man nur eine Taste drückt. Geht also alle Scenes des 1. Songs auf der Setliste durch. Bei der letzten Scene des Songs angekommen, dann schaltet der nächste Tritt darauf auf den nächsten Song und startet bei Scene1. Oder ich schalte dazwischen automatisch das Stimmgerät ein, damit Ruhe ist und man stimmen kann.
Was eventuell extrem schwierig werden wird, aber sicherlich hammer wäre, ist
  • Scene-Controller implementieren. Dürfte aber durchaus möglich sein!
  • Möglichkeit, im Footswitch die Konfiguration der Presets zu speichern. Dann würde er beim Songwechsel alle notwendigen Daten via SysEx an das Ultra raussenden. Dadurch bestünde auch die Möglichkeit, beim Scenewechsel die Einstellungen in den einzelnen Modulen zu ändern. Beispielsweise:
    • Scene1, Higain-Sound (Amp1 aktiv, Amp2 bypassed)
    • Scene2, Clean-Sound (Amp1 bypassed, Amp2 aktiv, Amp1 bekommt Daten für nen Crunch-Sound)
    • Scene3, Crunch-Sound (Amp1 aktiv, Amp2 bypassed, Amp2 bekommt Daten für einen Lead-Sound mit viiiiiiiiel zu viel Gain)
    • Scene4, Lead-Sound (Amp1 bypassed, Amp2 aktiv, Amp1 bekommt... usw)
Evtl. wichtig, gleich zu erwähnen:
  • Ich hab nicht vor, das Auswählen von Presets zu implementieren. Bzw. stückweise habe ich das schon (die Funktionen dafür stehen bereit, werden halt nicht aufgerufen), aber ich persönlich benutze auch beim IIer immer nur den Song- oder Gig-Modus. Einer meiner Songs heißt "Jam", dazu gehört dann ein Preset, welches eben alles enthält, womit ich dann quasi jeden Song spielen kann. Tap-Tempo auf Global usw.
So, das wars bisher. Fuck ey, mein Ultra kann mit dem Teil jetzt schon teilweise mehr als das II :ROFLMAO: Gleich gut klingen tut es natürlich nicht, aber da kommt schon die Idee auf, für das II den Code anzupassen, nen zweiten Footcontroller zu bauen und das MFC-101 verhökern.

Aber mal Ball flach halten, noch ist das nicht fertig und ich hab z. B. noch nicht reingehört, wie so ein Scene-Wechsel eigentlich klingt. Hoffentlich nicht 1000 Plopps... Aber ihr könnt drauf wetten, da kommen, sobald die Zeit reif ist, Infos!

So, mal gespannt, wieviel davon mir der Cliff klaut :devilish:


p. s.: Das ist nicht als kommerzielles Produkt geplant! Ist für mich einfach eine gute Gelegenheit, mal etwas tiefer ins Programmieren einzusteigen. Hab da glaub ich einigermaßen Talent für, es aber eigentlich nie gemacht... Wie so vieles halt...
Muss mir das noch überlegen, aber werde euch bestimmt, sobald der Code dafür reif ist, alles zur Verfügung stellen! Bisher ist die Konfiguration der Songs noch etwas aufwändig, v. a. für Leute, die nicht gern in Quellcode herumschreiben wollen. Ein eigener Editor wäre da sehr fein, aber das wäre dann wieder eine ganz andere Baustelle :unsure: Alternativ eben "schöner" Quellcode, gut kommentiert, damit da jeder klar kommt.

p. p. s.: Wer geile, verrückte Ideen hat, die man da einbauen könnte, immer her damit!
 
Zuletzt bearbeitet:

axifist

Well-known member
Mitglied seit
Nov 14, 2013
Beiträge
1.921
Hm, gute Frage :biggrin: Also ich sag mal so, hauptsächlich beschränke ich mich auf C, aber an manchen Stellen nutze ich auch C++-Funktionalität. Hab vor ca. 10 Jahren an der Uni mal ne Vorlesung über Maschinensprache gehört, aber nicht allzu aktiv betrieben. Darauf stützen sich meine C-Kenntnisse...

Also ganz ehrlich, ich hab keine genaue Ahnung! Letztlich nutze ich halt das Standard-Zeug:
  • for-Schleifen
  • if-Bedingungen
  • eine while-Schleife (fürs Menü :thumpsup:)
  • switch-Cases
  • Strings (das ist glaub C++)
  • und ganz viele Arrays und Funktionen
  • Alles schön in eigene Header-Dateien verteilt, z. B. in menu.h ist das Menü drin, intro.h hat alles für das Intro usw.
Der Rest ist eben Logik und hoffentlich nicht allzu grausamer Code!

Ach ja, vergessen:
  • Switche sind entprellt (aber nicht mit delay, wie das viele machen!), die "Entprellungszeit" ist konfigurierbar, Potis geglättet und senden nur Daten, wenn sich was ändert. Die beiden Sachen hab ich ganz am Anfang erledigt, daher wohl vergessen.
  • Möchte, wegen der mega Konfigurierbarkeit, jedem Switch ein Display spendieren. Hab da aber das richtige noch nicht gefunden. Ich weiß noch nichtmal, wieviele Switche ich nehmen will. Arg viele braucht es ja nicht.
Übrigens, großer Denkfehler: Den Bypass-Status jedes Effekts muss ich überhaupt nicht aus dem Axe auslesen. Das ist ja im Footcontroller gespeichert. Kann ich einfach da auslesen. Fiel mir ein, nachdem ich gestern Abend ins Bett gefallen bin :doh: Solche Momente hab ich die ganze Zeit :biggrin:
 

OSon

Administrator
Teammitglied
Axe-Fest 2023 Teilnehmer
Axe-Fest 2022 Teilnehmer
Axe-Fest 2020 Online Teilnehmer
Axe-Fest 2019 Teilnehmer
Axe-Fest 2018 Teilnehmer
Axe-Fest 2017 Teilnehmer
Mitglied seit
Sep 29, 2012
Beiträge
2.558
Ich hatte ja auch schonmal die Ideen einen Footcontroller zu bauen. Die Basis Funktionen sind alle kein Problem. Ich wollte es damals so machen, dass ich auch wie die MFC alles aus dem Axe auslesen und anzeigen kann. Ich habe das dann aber nie umgesetzt. Mir ging rein rechnerisch irgendwann der speicherplatz aus für das was ich vor hatte.

Und mich hat es gewurmt, dass es halt Programmcode war. Ich hatte damals für die Konfiguration des teils auch einen SD Card Reader vorgesehen. Auf dem sollten die Konfigurationen für verschiedene MFC Setups gespeichert sein.

Das war auf jeden Fall noch einer meiner Ideen. Ich habe es dann alles nicht umgesetzt...
 

axifist

Well-known member
Mitglied seit
Nov 14, 2013
Beiträge
1.921
Da der Footcontroller bzw. der Code in erster Linie für mich gedacht ist und ich kein Problem damit habe, alles im Code zu konfigurieren (bis auf ein paar Dinge, die ich evtl. vor Ort einstellen möchte, die löse ich über ein Menü, das die Optionsparameter in den EEPROM schreiben), hab ich mich darum momentan (noch) nicht gekümmert. Hat auch keine allzu hohe Priorität. Der EEPROM des Mega ist 4096 Byte groß, da kriegt man durchaus ordentlich was rein. Aktuell nutze ich glaub ich 9 Byte :thumpsup: Für komplexere Elemente wie z.B. die Song-Konfigurationen, da wäre sehr schnell Ende!
 

OSon

Administrator
Teammitglied
Axe-Fest 2023 Teilnehmer
Axe-Fest 2022 Teilnehmer
Axe-Fest 2020 Online Teilnehmer
Axe-Fest 2019 Teilnehmer
Axe-Fest 2018 Teilnehmer
Axe-Fest 2017 Teilnehmer
Mitglied seit
Sep 29, 2012
Beiträge
2.558
Ja, weitermachen! Ich wollte auch nicht die Motivation daran zerstören.

Ich habe damals nur großes vorgehabt. Viele Features sollten rein und das war
Für den Start einfach zu viel.
 

axifist

Well-known member
Mitglied seit
Nov 14, 2013
Beiträge
1.921
Keine Sorge, das Ding ziehe ich durch!

Ich hätte übrigens liebend gern deinen Code als Basis genommen, aber da war mir der Einstieg viel zu steil, ich verstehe den Code überhaupt nicht!

Wenn ich die letzten Bugs mal raus und die noch wichtigen Features drin hab, lade ich hier mal den bis-dato-Code hoch, evtl auch mit Video.
 

axifist

Well-known member
Mitglied seit
Nov 14, 2013
Beiträge
1.921
Ok, das Ende des Speicherplatzes hat sich nun mehr als bemerkbar gemacht! Man sieht, @OSon hat das alles schon vor mir durchdacht! Also nächste Baustelle: Externer Speicher. Wieder ne Gelegenheit etwas zu lernen :thumpsup:
 
M

mrgodin

Guest
Hm, gute Frage :biggrin: Also ich sag mal so, hauptsächlich beschränke ich mich auf C, aber an manchen Stellen nutze ich auch C++-Funktionalität. Hab vor ca. 10 Jahren an der Uni mal ne Vorlesung über Maschinensprache gehört, aber nicht allzu aktiv betrieben. Darauf stützen sich meine C-Kenntnisse...

Also ganz ehrlich, ich hab keine genaue Ahnung! Letztlich nutze ich halt das Standard-Zeug:
  • for-Schleifen
  • if-Bedingungen
  • eine while-Schleife (fürs Menü :thumpsup:)
  • switch-Cases
  • Strings (das ist glaub C++)
  • und ganz viele Arrays und Funktionen
  • Alles schön in eigene Header-Dateien verteilt, z. B. in menu.h ist das Menü drin, intro.h hat alles für das Intro usw.
Der Rest ist eben Logik und hoffentlich nicht allzu grausamer Code!
:biggrin:
Danke ;-)
C oder C++ war eigentlich eher nebensächlich;
Mich interessierte nur mal die generelle Sprache.

Hört sich ja alles schon schön strukturiert an ;-)
Das hilft jetzt und vor allem später mal den Überblick zu behalten.
Merkt man, wenn man ein halbes Jahr später in seinen eigenen Code sieht;
dann zeigt sich idR., ob man nachhaltig verständlich programmiert hat ;-)))))

Reizt mich auch, wenn ich die Möglichkeiten so lese.
Aber Zeit ist leider endlich ... und nicht unendlich
Naja; vielleicht irgendwann mal.
Viel Spasss noch!
 

OSon

Administrator
Teammitglied
Axe-Fest 2023 Teilnehmer
Axe-Fest 2022 Teilnehmer
Axe-Fest 2020 Online Teilnehmer
Axe-Fest 2019 Teilnehmer
Axe-Fest 2018 Teilnehmer
Axe-Fest 2017 Teilnehmer
Mitglied seit
Sep 29, 2012
Beiträge
2.558
Ok, das Ende des Speicherplatzes hat sich nun mehr als bemerkbar gemacht! Man sieht, @OSon hat das alles schon vor mir durchdacht! Also nächste Baustelle: Externer Speicher. Wieder ne Gelegenheit etwas zu lernen :thumpsup:
Ach schade. Ich dachte, das dauert noch etwas.... Bei mir lag es eher daran, dass ich von Anfang an zu viel wollte. Bei Dir klang es eher so, dass es Schritt für Schritt voran ging... Na ich bin gespannt, was Du noch so zaubern kannst.
 

Friedlieb

Well-known member
Axe-Fest 2023 Teilnehmer
Axe-Fest 2020 Online Teilnehmer
Axe-Fest 2019 Teilnehmer
Axe-Fest 2018 Teilnehmer
Axe-Fest 2017 Teilnehmer
Mitglied seit
Sep 29, 2012
Beiträge
1.396
Übrigens, großer Denkfehler: Den Bypass-Status jedes Effekts muss ich überhaupt nicht aus dem Axe auslesen. Das ist ja im Footcontroller gespeichert. Kann ich einfach da auslesen.
Theoretisch ja. Dann bekommst Du aber nicht mit, wenn der Bypass-Status von anderer Seite geändert wird. ZB durch ein parallel mitlaufendes AxeEdit, oder durch manuelles Rumtippen am Front Panel des Geräts, oder durch ein Auto Engage. Robuster wäre es in der Tat, den Bypass-Status gelegentlich zu pollen.
 

axifist

Well-known member
Mitglied seit
Nov 14, 2013
Beiträge
1.921
@Friedlieb, das stimmt natürlich! Und vielleicht ist es doch gut, die Daten auszulesen, weil dann absolute Gewissheit herrscht, dass die Midi-Befehle auch richtig angekommen sind.

@OSon, die bisherige Konfiguration der Songs frisst Speicher ohne Ende! 62 Blöcke (Amp1, Amp2, Cab1, Cab2, ...) kann man im Ultra bypassen, ich hab mal 16 Scenes angesetzt, bisher 3 Songs zu Testzwecken. Macht schon einmal 62*16*3 = 2976 byte. Dann die Infos zu den Songs (welches Preset, Name, Anzahl Scenes)... macht den Bock nicht fett. Aber aktuell 16 Switche, jeweils die Art des Switches (Momentary, Toggle, ...) und welchen Effekt sie schalten, je 16 Scenes, macht weitere 16*3 + 16*16*3 = 816 byte. Dann noch 8 Potis, machen 8*16*3 = 384 byte. Hoffe ich rechne jetzt nicht falsch :biggrin: Was da anwächst ist das "dynamic memory". Das war bei 80%. Der "program storage space" schlummert dagegen auf erfreulich niedrigen Werten. Welcher Speicher genau was speichert hab ich jetzt noch nicht auf dem Schirm, war bisher nicht nötig :doh: Habs jetzt mal reduziert, um weiter an dem Projekt arbeiten zu können.

Also, ich stelle euch hier jetzt mal meinen aktuellen Code rein. Ganz ausdrücklich: Das ist kein Versuch durch die "Hintertür", Coding-Hilfe zu erschleichen. Wer Lust hat, sich das mal anzutun, sehr gerne! Wer mir Tipps geben möchte, auch sehr gerne. Wer alles über den Haufen werfen würde, großes Verständnis. Auf jeden Fall bedenken, dass ich hier zum ersten Mal wirklich Code für etwas Konkretes schreibe! Bisher beschränkte sich alles auf Shell-Skripte zur Vereinfachung von alltäglichen Arbeitsaufträgen für mich zur Erleichterung.

Hab für die Lese- und Testwilligen noch einige Kommentare eingefügt, allerdings nicht, um konkrete Code-Zeilen zu erklären. Will ich aber auch noch machen, man ist ja vergesslich...

Ok, genug Disclaimer: >>Midi-Controller<<

edit: Ah, vergessen. Also ich hab den Code für ein 16x2-Display geschrieben. Das Menü läuft über die Buttons des Displays, welches ein Keypad Shield gleich integriert hat. Es handelt sich um so ein Teil.
 
Zuletzt bearbeitet:

axifist

Well-known member
Mitglied seit
Nov 14, 2013
Beiträge
1.921
Ok, das Ende des Speicherplatzes hat sich nun mehr als bemerkbar gemacht! Man sieht, @OSon hat das alles schon vor mir durchdacht! Also nächste Baustelle: Externer Speicher. Wieder ne Gelegenheit etwas zu lernen :thumpsup:
Lösung gefunden und eventuell schon gelöst (bin gerade am Testen).

Stichwort PROGMEM :applause:

Hauptsächlich fressen ja die Arrays der Konfigurationen für die Songs Speicherplatz. Und zwar im RAM, wenn man da nichts Spezielles macht. Diese Daten sind aber fest, die müssen nicht veränderbar sein. Und wenn man 100 Songs hat, aber eigentlich ja immer nur einen geladen hat, dann müssen die anderen ja nicht im RAM herumliegen.
PROGMEM sagt dem Compiler nun, dass die so gekennzeichneten Arrays im Programmspeicher bleiben sollen (wenn ich das richtig verstehe). Was ich dann nur machen muss ist, beim Laden eines Songs die Daten aus dem Programmspeicher auslesen. Es ist also immer nur ein Song geladen, was RAM-mäßig absolut kein Problem ist! Ist bei 33% mit 4 Scenes pro Song. Wenn ich die Anzahl Scenes auf (eher unrealistische!) 40 hochschraube, ist die Auslastung bei 78%. Top!!! Der Hauptspeicher ist groß genug, geht in dem Extrembeispiel nur von 13% auf 18% hoch. Da dürften also einige Songs mit einigen Scenes reinpassen :thumpsup:
 

OSon

Administrator
Teammitglied
Axe-Fest 2023 Teilnehmer
Axe-Fest 2022 Teilnehmer
Axe-Fest 2020 Online Teilnehmer
Axe-Fest 2019 Teilnehmer
Axe-Fest 2018 Teilnehmer
Axe-Fest 2017 Teilnehmer
Mitglied seit
Sep 29, 2012
Beiträge
2.558
Progmem... genau... wenn sich wenig an den Daten ändert, ist das perfekt! Nur oft schreiben ist glaube ich langsam... oder so... na ich bin gespannt... da kriege ich ja auch gleich Lust wieder was zu machen... Projekt ist schon in Planung.... :)
 

axifist

Well-known member
Mitglied seit
Nov 14, 2013
Beiträge
1.921
Schreiben kannste da nicht, das ist read-only! Aber ich hab ja nicht vor, dem Footswitch die Möglichkeit zu geben, via Menü irgendwie Songs zu editieren. Das ist definitiv was für am Rechner erledigen :geek:

Na das freut mich aber, bin gespannt was du so machst. midi_board_THREE? ;)
 

axifist

Well-known member
Mitglied seit
Nov 14, 2013
Beiträge
1.921
So, großes Update!
  • Hab den Menü-Punkt OFFSET hinzugefügt. Wichtig ist, dass man, wenn man nen Offset möchte, auch den Programmcode entsprechend schreibt, also ne 1 für den ersten Song statt ner 0. Muss dahingehend den Code nochmal genau durchsuchen, ob das an allen Stellen korrekt gesetzt ist.
  • Jetzt kann man Scenes auch direkt anwählen und nicht nur durchschalten. Das Durchschalten ist für mich bei Gigs bzw. wenn ich eben fertige Songs spiele, die Herangehensweise, aber beim Jammen möchte ich auf die Scenes verschiedene Sounds legen, die dann direkt auswählbar sein müssen.
  • Der LED-Status von Switchen, welche Effekte bypassen, wird jetzt korrekt angezeigt. Dazu lese ich die Konfiguration der Scenes aus. Wie bereits erwähnt wäre es aber besser, diesen Status aus dem Axe abzufragen. Das mache ich dann mal wann anders :thumpsup:
  • Habe das Speicherplatzproblem mittels PROGMEM gelöst. Bei 24 Scenes pro Song und 4 konfigurierten Beispielsongs liegt der Programmspeicher bei 17%, der Arbeitsspeicher bei 64% (der wird nicht größer werden bei mehr Songs, weil ja immer nur einer im RAM geladen ist). Also absolut problemfrei, da sollten einige Songs konfigurierbar sein!
  • Der Status der Potis (bzw. eben deren Position) wird jetzt am Anfang des Songs eingelesen.
  • Im Songmodus wird jetzt der jeweils letzte aufgerufene Song gespeichert. Wenn man also den Controller neu startet, landet man bei dem Song, den man als letztes gespielt hat. Im Gig-Modus möchte ich aber zurück auf den ersten Song, daher wird hier der Song nicht gespeichert.
  • Habe, weil ich einen möglichst kleinen Footswitch, also mit möglichst wenigen Switches, haben möchte, einen Funktionsumschalter eingebaut. Man kann also alle Switches doppelt belegen. Prinzipiell könnte man damit auch noch viel mehr Funktionsebenen durchschalten, aber das halte ich ehrlich gesagt dann doch für unpraktikabel. Aber Praxistests stehen ja eh noch aus...


Hardwaremäßig stelle ich mir das Teil aktuell ungefähr so vor:
Midi-Controller.png
Die beiden oberen Switche werden evtl. fest zugewiesen (Funktionsumschaltung bzw. Tuner / Taptempo). Ist alles noch offen!

Aktuell sieht das Teil noch so aus :thumpsup:
IMG_20180602_191108.jpg
 
Zuletzt bearbeitet:

OSon

Administrator
Teammitglied
Axe-Fest 2023 Teilnehmer
Axe-Fest 2022 Teilnehmer
Axe-Fest 2020 Online Teilnehmer
Axe-Fest 2019 Teilnehmer
Axe-Fest 2018 Teilnehmer
Axe-Fest 2017 Teilnehmer
Mitglied seit
Sep 29, 2012
Beiträge
2.558
Wow!!! Nicht schlecht! :)
 

axifist

Well-known member
Mitglied seit
Nov 14, 2013
Beiträge
1.921
Kurzes Update, ich bin noch dran an dem Projekt! :thumpsup:

Hab eben in FreeCAD einen Teil des Gehäuses gezeichnet. In das große Rechteck kommt das Display, in die 10 größeren Löcher die Taster, darüber in die kleineren Löcher kommen die zum jeweiligen Taster gehörigen LEDs. Über dem Display kommen 4 Potis hin. Zwischen den beiden mittleren Potis eine LED, die ausschließlich mit dem Tempo blinkt. Unter das Display kommen Buttons, die fürs Menü gedacht sind, der rechteste davon für Reset.

2018-08-15-230418_1920x1080_scrot.png

Das Ziel ist, fertig zu sein, bevor die FCs herauskommen :triumphant:

Ach ja, Breite 30 cm, Länge 24 cm, 1,5 mm starkes Stahlblech. Wird insgesamt sehr flach, vorne 1 cm, hinten 5 cm. Kann das alles begründen (muss ich auch, wird ein Prüfungswerkstück) :applause:

Bin SOOO gespannt ob ich das so hinbekomme wie ich mir das vorstelle :applause:
 

papasoeren

Well-known member
Axe-Fest 2023 Teilnehmer
Axe-Fest 2022 Teilnehmer
Axe-Fest 2018 Teilnehmer
Mitglied seit
Feb 6, 2015
Beiträge
1.528
Sieht überzeugend aus. :applause: Sind 1,5 mm nicht doch ein wenig dick? Oder muss das Teil auch schussfest sein?
 
Oben
mainframe-fourhanded
mainframe-fourhanded