neue Abschnitte in der Ubuntuanleitung und Berichtigungen

[metasymbol]

Geht das mit der von Dir genannten Modularlösung?

Wie gesagt: "lash" wäre die Lösung für dieses Problem.

Tatsächlich ist "lash" eine Client/Server-Applikation mit einem Dämon, dass ohne Konsole nicht benutzbar ist. Das hat gereicht, mich davon abzuhalten, mich mit "lash" näher zu beschäftigen - ich hatte einfach gehofft, dass sich jemand, der sich damit auskennt, ein GUI schreibt, mit dem man als Normalsterblicher zurecht kommt.

Als Torben fst 1.8 mit lash support released hat (u.a. weil er gesehen hat wie ich auf der LAC langwiegerig mein Setup starten musste und ich ihm leid tat), haben wir von jacklab mal das SUSE lash debuggt (weil das gabs schon all die jahre, aber funktionierte nie - wir hatten es nur drin wegen der build-requires einiger Apps). Habe mich dann ganz begeistert auf die Sache gestürzt, ist auch ziemlich einfach. Man startet "lashd" auf der Konsole (das wars), dann die Applikationen und ein gui namens lash-panel gibts auch. Und seq24 wird auch unterstützt. Was brauch ich mehr -seq24 und ein paar vst-synths. (ok, sooperlooper und H2 wäre in dem zusammenhang auch noch gut, aber ich will ja nicht meckern)

Aber Torben die faule Sau bastelt zwar mal eben Traumapplikationen, aber, gleichzeitig gibts irgendeinen Bug/Nachteil. Der Vorteil ist - ja Wahnsinn, in lash-panel gibts n button der heisst "save" und der speichert den Kram als "project-1"auch. [Edit] Der Nachteil: man kann fst jetzt nur noch mit lashd starten.

Und dann am nächsten Tag - freut man sich das man "endlich-endlich-endlich" einfach an seinen Arrangment weiterarbeiten kann. startet "lashd" und weils Torben gesagt hat "wineserver -p" (sonst gibts schwierigkeiten beim aufrufen) und öffnet im lash-panel "project-1" - plopp - aber irgendwas "garantiert" geht immer schief. Es funktioniert nicht richtig - nur halb, aber nur halb - das ist kein session management. Zu Torbens Entschuldigung muss ich sagen das er ziemlich eingespannt ist und wenig Zeit hat zum programmieren.

Ja shice da boot ich doch wieder Windows mit meiner 39Euro Software, die das kann, speichern und wieder aufrufen... Klar ich vermisse dann ein bisschen seq24, allerdings kann ich dann ja meine (bundle) lite Version von ableton live starten, als plugin (subminihost) energyXT und energyXTE und so hab ich eine sehr stabile, preiswerte, benutzerfreundliche Arbeitsumgebung, die meine Arbeit respektiert in dem sie mich die auch wieder aufrufen lässt ohne spirenzchen.

Ich meine da allerdings keine all-in-one Hosts wie RG, Muse, Ardour
(bekommt ja jetzt Midi), sondern nen Simplehost, in den man Audio/Midi/Videoplugins laden kann.
Kleine schlagkräftige Einheiten, weniger Bugs, mehr Auswahl.

energyXT ist finde ich grundlegend der ideale erweiterbare Minihost, fehlt nur noch Videounterstützung. Muss ich mal Jorgen ein FR schreiben

Bin sooooooo gespannt auf die Linuxversion....

[zettberlin]

Man stelle fest: Modulares Arbeiten wäre machbar und statt einer Handvoll unfertiger Komplettlösungen (Rosegarden, MusE, Beast, Protux, Linux Multimedia Studio, Ardour, und was auch immer noch kommen mag) wären ein paar schnelle, kleine und funktionstüchtige Spezialisten am Start

Zumindest die Midifunktionen von Rosegarden und Muse und die HD-Recorder/Arranger/Mixerfunktionen von Ardour gehören zusammen - die aufzuteilen wäre Unsinn - Sinnvoll wäre es vielleicht, statt Ardour mit Midispuren zu überfrachten, die Interaktion zwischen Ardour und richtigen Midiprogs weiter zu verbessern (z.B. indem sie sich gegenseitig von ihren Projektfiles aus aufrufen können etc).

[Drumfix]

Mein Ansatz mit der Audio/Midi/Video Pluginapi wäre eben der, dass man
bspl. in Ardour in einer Spur als erstes ein oder mehrere ein Midiplugins (Midieditor, Drumeditor, Gitarreneeditor, Arpegiator..) einsetzt, gefolgt von einem Synthplugin (oder Midiout), gefolgt von den Inserteffekten etc.

Liesse sich dann mit einem einzigen Sessionsave in Ardour abspeichern.

Und Ardour bräuchte dazu keine Midiedit Funktionen. Eigentlich auch keine
Audioeditfunktionen, da man auch die Audioregions einer Spur in einem Samplerplugin editieren und einem Midiplugin arrangieren könnte.

In der Tat ist EnergyXT einer der wenigen Hosts, die sowas bisher ermöglichen.

Ich warte auch gespannt auf den Linuxport.

[Mitsch]

Was muss ein Programm, das total recall ermöglicht können:

# es muss sich die im Moment des Speicherns laufenden Programme merken können.
# es muss die Dateien, die diese Programme gerade bearbeiten, speichern und auf Wunsch wiederaufrufen können
# es muss die Verbindungen, die diese Programme eingegengen sind wiederherstellen können

In meiner unendlichen Naivität als Nicht-Programmierer frag ich jetzt mal ganz unbedarft: Wäre es nicht sowohl für Entwickler als auch für den Anwender einfacher, wenn - wie ich schon oben beschrieben habe - alle wiederherzustellenden Audio-Programme aus ein und derselben Applikation gestartet werden? Zum einen ist das benutzerfreundlich, zum anderen sind damit die Aufgaben klar verteilt.
Man hat also ein zentrales Tool, was alle kleinen Audio-Programme in Sachen gegenseitige Verkabelung und Setup und Erarbeitetes laden/speichern/wiederherstellen steuert. (Und damit meine ich kein Programm wie MusE, Rosegarden, etc..., sondern ein Programm, das einzig und allein dafür zuständig ist, auf die Session aufzupassen - Also im Grunde KEIN Audio-Programm!) Dieses Tool könnte sich auch die Reihenfolge merken, in der die Programme miteinander verkabelt wurden. Damit das alles funktioniert, müssten die Audio-Programme um die Fähigkeit, mit diesem Tool kommunizieren zu können, erweitert werden. (Genauso müssen Audio-Programme um die Fähigkeit, mit lash und anderen Session-Managern zu kommunizieren, erweitert werden. Von dem her schenkt es sich vom Aufwand her nichts.)

Vom Ablauf her stelle ich mir das weiterhin als unbedarfter Nicht-Hacker und Traumtänzer so vor: Ich lade also mein Tool, das ich im Folgenden lash2 nenne. Lash2 beinhaltet eine Liste von Audio-Progs, die Fähig sind, mit lash2 zu kommunizieren. Der Anwender kann aus dieser Liste nun auswählen, welche Audio-Programme er für seine Session nutzen will. Vieleicht fängt er mit der Schlagzeug-Programmierung an und startet also z.B. H2. Lash2 merkt sich nun also: 1. Applikation: H2. Soll irgendetwas gespeichert werden, so wird das nicht über H2, sondern über lash2 erledigt. Lash2 erstellt dann einen Ordner, z.B. mit Namen "Session1" und speichert dort alle Session-relevanten Daten, wie z.B. das Setup von H2. Kommen später andere Progs hinzu, merkt sich lash2 zusätzlich, in welcher Reihenfolge dieselben dazu kamen und wie die Progs untereinander verbunden waren und speichert diese Informationen bei Bedarf ebenfalls in diesem Ordner. Wird ein Programm nicht mehr in der Session gebraucht, wird über lash2 der Menüpunkt "aus Session entfernen" angewählt und alle seine Einstellungen aus dem Session-Ordner gelöscht. Somit wären also immer alle Einstellungsdaten, die für ein "total recall" nötig wären, an einer Stelle verfügbar: Die benutzten Programme, deren Setups, die Reihenfolge für's starten, die virtuelle Verkabelung untereinander und - das sollte obendrein auch nicht so schwierig sein - die Position auf dem Desktop.

Zusätzliche nützliche Merkmale:
* Lash2 sollte jede Kommunikation anderer Sessionmanager mit den Audio-Progs unterbinden, damit nichts doppelt geladen wird.
* Aus den Menüs der jeweiligen Audio-Programme sollten, sofern sie von lash2 gestartet wurden, die Menüpunkte "Speichern", "Laden", etc... verschwinden, damit der User gezwungen wird, dies über lash2 zu erledigen. Außer natürlich, ein "speichern" von sonstwo löst ein Signal aus, das auch andere lash2-Progs dazu bringt, dasselbe (im richtigen Verzeichnis) zu tun.

Wäre so etwas möglich? Wo liegen die Schwierigkeiten an so einem System bzw. habe ich einen grundsätzlichen Denkfehler?

[linuxchaos]

die bezeichnung lash2 ist nicht ganz falsch, weil was du beschreibst ist mehr oder weniger lash (wenn es irgendwann mal richtig funktioniert).
die unterschiede sind nicht grundlegend und könnten wahrscheinlich auch in den kommenden versionen von lash eingbaut werden.

deine bisherigen vorstellungen entsprechen auch meinen, nur mit 2 unterschieden:
1) ich kann die einzelnen programme auch aus dem startmenü oder in der konsole starten - wichtig ist mir nur, dass ALLES so gespeichert wird, so wie es ist und ich nicht in allen programmen die jeweilige datei einzeln laden muss...
2) ich will explizit NICHT, dass ich gezwungen werde, etwasd so oder so zu verwenden. in der regel will ich eine "session" öffnen. wenn ich jetzt aber nur ein anderes hydrogen-setup verwenden will, will ich nicht gezwungen sein, daraus deshalb zwangsläufig einen andere session zu machen.
es ist ein wichtiger grund, warum ich so gerne linux verwende, dass ich da eben diese freiheiten noch habe...

und jetzt noch was arrogantes zum abschluss :
die leute, die sich nicht mal die mühe machen, sich zu merken, welches programm sie zum speichern verwenden haben es dann einfach nicht verdient, linux zu verwenden ...

aber zurück zu lash, heisst es wie so oft in letzter zeit:
wir user müssen mehr feedback geben (an lash, aber auch an alle apps, die lash haben und erst recht bei denen melden, die lash noch nicht unterstützen) und mithelfen, dass es weitergeht. ich halte es irgendwie für falsch, über lash2 zu reden, bevor lash gestorben ist ...

also ich glaube ich werde mir lash mal genauer angucken, wenn ich das nächste mal musik mache...

grüsse l.chaos

[nowhiskey]

also bei mir funktioniert lash einwandfrei, hab mir letztens "glashctl" kompiliert, das ist für mich der erste intuitive grafische-lash-kontroller, geht eigentlich gut, z.b. muse ist da völlig problemlos.
das problem sehe ich eher da drinne, dass es kaum programme gibt, die lash unterstützen.
bisher zumindest!

gruss,
doc