Hallo zusammen,
auf der Danke-Seite steht ein paar mal “Übersetzung”. Gibt es denn Ultraschall auf Englisch? Ich habe den Eindruck, dass in der englischsprachigen Szene langsam Interesse an Reaper für’s Podcasting aufkommt. Ich empfehle dann immer Ultraschall, aber das ist ohne Deutsch-Kenntnisse natürlich schwierig… Könnte man die Lokalisierung dann auch über GitHub organisieren?
oder was genau meinst du mit Ultraschall auf Englisch?
Danke. Manchmal ist man ja richtig froh, wenn man falsch liegt 
Hm, na die Lage ist schon etwas - komplizierter. Status Quo ist:
Für die Webseite bieten wir eine Google-Translate an, das ist natürlich nur so semi-gut.
Das liest sich jetzt erst mal ermutigend, aber: mit Ultraschall arbeiten kann man damit (noch) nicht - es fehlen die Tutorial-Videos. Das sind mittlerweile über 30 Stunden, von denen man mindestens 3 Stunden gesehen haben muss um die Arbeitsweise wirklich zu verstehen. Davon ist nichts Englisch: https://ultraschall.fm/tutorials/
Das hat nur bedingt mit Aufwand zu tun: Zeit und Ressourcen zumindest ein basales Englisch-Tutorial aufzunehmen hätte es gegeben. Aber: bisher habe ich mich dagegen sehr bewusst entschieden.
Grund: der amerikanische Podcasting-MArkt tickt sehr anders als der Deutsche. Dort ist vieles extrem durchkommerzialisiert, und entsprechend hoch sind die Anforderungen. Ich wäre optimistisch, dass man den Markt dort mit unseren Features komplett aufrollen könnte, die jetzigen Workflows dort sind verstörend umständlich. Selbst Hindenburg ist dort wenig bekannt.
Das würde ich aber nur angehen, wenn man auch eine entsprechende Support-Struktur anbieten kann. Als reines pro-bono Hobby-Projekt ist das nicht seriös zu gewährleisten, das Team macht dann die nächsten Jahre nichts als Support.
Der Ausweg wäre eine Kommerzialisierung und die Einführung von kostenpflichtigem Support oder das Anheuern englischer Supporter.
Darauf habe ich nicht die geringste Lust: all meine bisherigen Open Source Projekte fuhren gegen die Wand oder wurden doof, sobald Geld ins Spiel kam. Ich hasse das. Möglich, dass das verhindert dass ich endlich mal Multi-Millionär werde, dafür bin ich aber ein erstaunlich glücklicher Mensch.
Kann sein, dass wir den Level “US-Markt erobern” irgendwann mal durchspielen wollen, aber wenn dann richtig.
Danke für die ausführliche Rückmeldung, Ralf. An die Videos und den Support insgesamt musste ich auch denken. Und da kann ich deine Argumentation total nachvollziehen. Würdest du generell davon abraten, anglophonen Nutzern Ultraschall zu empfehlen, selbst mit dem Hinweis “auf eigene Gefahr”?
P.S.: Als zunehmend begeisterter Ultraschall-Nutzer bin ich für deine Video-Tutorials extrem dankbar!
Leider ist Ultraschall ohne die 3 Videos von Ralf kaum benutzbar. Also benutzbar schon, aber da krabbelt man halt total auf der Oberfläche rum
Da ist schon was dran, aber man kann mit Rumprobieren (trial&error) schon die Basics gut abdecken.
Ich sage nur Routingmatrix 
An der gehen glaub ich viele zu Grunde ohne das Video von Ralf
Ich habe neulich einem Amerikaner dieses Forum empfohlen. Es steht ja nirgends, daß Deutsch hier Pflicht ist.
Ich denke, das ist der Punkt. Man muss sehen: gerade in den USA haben die ja alle schon was - erstaunlich viele setzen dort auf Adobe Audition, da sie das „umsonst“ in ihrem Adobe-Paket drin haben. Und es ist für Podcasting auch nicht das schlechteste, siehe dieser Vergleich.
Wenn man ihnen dazu eine Alternative geben will, muss die ersichtlich und unmittelbar besser sein. Sonst lohnt es sich nicht, ins Muskelgedächtnis eingegangene Workflows zu ändern. Und dieses „ersichtlich und unmittelbar besser“ kann Ultraschall nicht einlösen, ohne einen gewissen Grad an Dokumentation.
Das berührt auch das Problem „lass doch die Community den Support machen“. Das klingt jetzt arrogant, ist es auch, aber: es hat schon einen Grund, dass ich hier versuche im Bord häufig der erste zu sein, der zu Ultraschall-Fragen Antworten gibt. Es gibt schon viele NutzerInnen da draußen (ca. 2.000) die so okayisch klar kommen, aber dann im Zweifel gefährliches Halbwissen weitergeben anstatt „wie es eigentlich gemeint ist“.
Beispiel: Ripple-Cut über alle Spuren, um eine Pinkelpause komplett zu schneiden: da kann man schon empfehlen zwei Schnitte zu setzen, den Zwischenblock löschen, dann den Ripple-Mode zu aktivieren und die hinteren Spuren ranschieben. Gedacht ist es aber halt so:
Das ist ein schönes Beispiel. Ein sehr häufig benutztes Feature wird hier mit vermutlich mathematisch minimaler Anzahl an Klicks gelöst, wenn man das einmal kapiert hat will man es nie wieder anders machen. Aber: die Anleitung dazu ist durchaus umfangreich, und das ist eines von mittlerweilen hunderten Features. Das auch noch adäquat auf Englisch umzusetzen: puh.
Ich habe mich immerhin bemüht, die Release-Notes gerade der 3.1 so zu schreiben, dass sie schon als gute Anleitungen funktionieren. Das ist aber eben nur für die letzten zwei Releases so erfolgt, alle Features der acht vorherigen sind nicht ähnlich gut dokumentiert.
Und gerade die „Killer-Features“ brauchen Erklärung: das automatische Ducking von Einspielern durch Sprachspuren etwa ist pure Magie in der Praxis, aber dazu muss man erklären:
Ich kann das jetzt ewig fortsetzen. Wir versuchen immer mehr, so viel wie möglich zu abstrahieren und im Hintergrund passieren zu lassen, aber das wird immer Grenzen haben.
Zuletzt zur Frage „soll man das dennoch Amis empfehlen“? Da würde ich sagen: ja, wenn man denn bereit ist als Ansprechpartner und EvangelistIn für genau solche Premium-Features bereit zu stehen. Sonst ist Ultraschall nur irgendein Schnitt-Programm, das etwas hübscher aussieht als das Standard-REAPER. Die Magie für PodcasterInnen ist da, aber sie will - wie in Hogwarts - erlernt werden.
Ich verstehe trotzdem nicht, warum das jemand hindern sollte englische Fragen zu beantworten.
Vorweg erstmal sorry, aber ich darf das:
Das entscheidest Du nicht.
Spekulation
Komm mal runter.
Ich liebe Dich trotzdem…
Hindern sollte das niemand. Ich weise nur darauf hin, dass die beiden ergiebigsten Support-Speicher, nämlich Screencasts und diese FAQ https://sendegate.de/c/ultraschall/Ultraschall-frequently-asked-questions dabei nicht helfen können da nur auf Deutsch. Das alles nochmal erklären kann man machen, ist dann aber eben Aufwand.
Aber nicht unbedingt Dein Aufwand. Obwohl sich da die Frage stellt, ob das SG ein Support-Forum für Ultraschall ist. Ich denke nicht…
Öhm - doch, genauso wie für StudioLink, Podigee, Auphonic, Podlove etc?
Da vielleicht auch für andere nicht so unmittelbar ersichtlich: auf der Kategorien-Seite hier im Sendegate
https://sendegate.de/categories
gibt es unten die ganzen Projekte, die hier ihre Support-Foren aufgebaut haben. Das läuft neben den anderen Community-Bereichen her.
@rstockm Danke erst mal für die ausführlichen Erklärungen.
Das Durchkommerzialisierte im amerikanischen Markt kann ich als Argument so nicht nachvollziehen. Es gibt ja genügend community-getragene Projekte, die international erfolgreich sind.
Textübersetzung sehe ich auch nicht als Problem. Dokumentation und FAQ könnte man in bestehenden Dokumentationssystemen ablegen (z.B. so was ähnliches wie readthedocs oder docusaurus). Beide bieten Anbindungen an Übersetzungssysteme. Ich bin mir sicher, dass viele Leute einem Aufruf zu Übersetzungen folgen würden. Dokumentation und Übersetzungen würden dann in einem Git-Repo liegen und es müssten dort nur noch ein oder mehrere Wächter die Community-Übersetzungen (z.B. von CrowdIn) annehmen.
Da die Screencasts aber eben auch Kern der Dokumentation sind sehe ich hier das Hauptproblem. Ganz konkret sehe ich es in der Frage wie man einen solchen überhaupt so aufzeichnen kann, dass man den Sprecher durchgehend hören kann. Screencasts für alles mögliche nehme ich ständig auf. Ich hätte allerdings keine Ahnung, wie ich das für Ultraschall bewerkstelligen sollte. Toll wäre also eine Art Howto für DAW-Screencasting.
Oh, das bringt auch mich regelmäßig an die Grenzen der Routing-Hirn-Verknotung 
Es wird dadurch nicht einfacher, dass man ja in der Routing Matrix das „echte“ Setup für den Podcast zeigen will und nicht einen, der noch für die Screencast-Aufnahme getuned wurde.
Und: das Setup wechselt je nach zu zeigendem Inhalt, das erschwert ein HowTo.
Was ich erstaunlich oft mache/brauche: ganz klassisches Analoges Verkablen mit Mischpult und Analog-Eingang am Computer.
Das muss natürlich nicht zwangsläufig so bleiben, es gibt ja durchaus auch Kritik an den Screencasts (zu lang, zu viel Gelaber, zu wenig komprimiert). Ich habe ja hier mal versucht, den Inhalt von Screencasts in m.E. gleichwertige Doku zu gießen, so dass die Leute vergleichbar viel lernen:
Problem: an jeder dieser Manuals habe ich etwa zwei bis drei Stunden gesessen. Für die letzte Release wäre das ein Doku-Aufwand von ca. 40 Stunden gewesen - vs. 5 Stunden für den Screencast.
Das Argument „musst ja nicht alles du machen“ kommt dann schnell, und klar würde ich mich über Hilfe freuen: sie sollte dann aber eben auch auf dem Niveau landen. Man kann das ja im Kopf mal durchspielen, wie die Doku zu einem beliebigen Feature aufgebaut sein müsste - etwa der Color-Picker. Scheinbar so simpel, aber im Detail dann doch ganz schön komplex.
Ich bin ganz deiner Meinung, dass gute Dokumentation keinesfalls simpel zu machen ist und sehr zeitaufwendig. Ich glaube aber auch, dass der FAQ-Bereich hier im Sendegate kein guter Platz für Mitarbeit an Dokumentation ist. So was wie Docusaurus, wo die Doku in Markdown in einem Github-Repo liegt (optionmal mit Edit/Translate Buttons direkt in der Doku) senkt die Beteiligungshürde immens. So ein System, macht es auch einfach die Doku für unterschiedliche Versionen der Software zu verwalten (wobei das bei Ultraschall vermutlich eher kein Thema ist). Ein schönes Beispiel für eine gute Doku mit hoher User-Beteiligung ist m.E. die Laravel Doku. Wenn es da Interesse gibt so was aufzubauen (erst mal unabhängig von Übersetzungen) biete ich mich hiermit an. Als erstes könnte man ja schon mal die Changelogs und deine bestehenden FAQ-Beiträge einpflegen.
Offen bleibt die Frage, wie du das mit den Screencasts machst bzw was es da zu beachten gilt. Ah… die andere Antword übersehen.