Studio One 7, Scripting und OSC Support nicht vorhanden: Schade, Presonus.

[ksoa]

Ich hatte schon vor einiger Zeit reingeschnuppert in Studio One und den Workflow im Arranger sehr gemocht, aber Live-Kapazitäten vermisst, weshalb ich vor 2 Jahren bei Bitwig landete.
Dass Studio One 7 bald einen Cliplauncher bekommt hatte mein Interesse wieder enorm angekurbelt - bis jetzt...

Denn jetzt bin ich auf zwei Dealbreaker gestoßen, die zwar "Nischen/Experten-Features" sind, aber dennoch für mich absolut unentbehrlich... Studio One bietet weder OSC Support, noch Zugriff auf die API. Schade! Mein selbstgebautes großes DAW Interface für Touch Monitore lässt sich somit niemals mit Studio One benutzen. Hatte ich nicht erwartet, aber gut, jede DAW FIrma hat so ihre eigene Philosophie. Die API für sich zu behalten und offenbar nur ein paar 'Auserwählten' zur Verfügung zu stellen empfinde ich als Community-Unfreundlichen-Kreativitätskiller. Sorry, das kann ich aufgrund von 2 Jahren Bitwig-Erfahrung nicht anders ausdrücken, da sich dort die Community eigene Skripte bauen "darf".

Gerne lasse ich mich eines Besseren belehren, falls es OSC support gibt und eine allgemein zugängliche API !?
(Eine API, mit der man z.b. auch ein eigenes OSC Script schreiben könnte - so ist das bei Bitwig z.b. passiert. Bitwig hat auch keinen nativen OSC support, aber ein fleißiger Nutzer hat ein Script dafür geschrieben, dank zugänglicher API)

Meine Quellen:
OSC Steuerung nicht möglich: https://answers.presonus.com/29204/osc-support
https://answers.presonus.com/4112/is-there-open-sound-control-support-in-studio-one
https://answers.presonus.com/42708/when-is-presonus-going-to-configure-studioone-for-osc

Scripting in Studio One: hinter Schloss und Riegel!
https://vi-control.net/community/th...pting-capabilities-under-lock-and-key.122050/
https://www.kvraudio.com/forum/viewtopic.php?t=506195&sid=91990d114becd6bfef2290b04509098f&start=30
https://answers.presonus.com/13519/there-api-that-studio-one-remote-uses-which-can-used-other-apps

 

[R-Kelly]

Die API für sich zu behalten und offenbar nur ein paar 'Auserwählten' zur Verfügung zu stellen empfinde ich als Community-Unfreundlichen-Kreativitätskiller.

Ich glaub das machen die anderen großen Hersteller wie Cubase, Logic und Pro Tools ja auch nicht anders.. leider..

Da hätte man so viel mit machen können wie z.B. einen DAW Projekt Manager siehe hier:

https://recording.de/threads/daw-project-manager-mit-pugin-datenbank.262600/#post-3345864

 

[Realist]

Bzgl. Cubase. Dort gibt es seit Version 12 die Midi Remote.
Die ist sehr umfangreich und flexibel und man hat auch Zugriff auf die API.
Scripte kann man dort auch programmieren.
Hier mal eine Einleitung.

Introduction | MIDI REMOTE API

Welcome to the Steinberg MIDI Remote API.

steinbergmedia.github.io

 

[jet2]

Ich hatte schon vor einiger Zeit reingeschnuppert in Studio One und den Workflow im Arranger sehr gemocht, aber Live-Kapazitäten vermisst, weshalb ich vor 2 Jahren bei Bitwig landete.
Dass Studio One 7 bald einen Cliplauncher bekommt hatte mein Interesse wieder enorm angekurbelt - bis jetzt...

Denn jetzt bin ich auf zwei Dealbreaker gestoßen, die zwar "Nischen/Experten-Features" sind, aber dennoch für mich absolut unentbehrlich... Studio One bietet weder OSC Support, noch Zugriff auf die API. Schade! Mein selbstgebautes großes DAW Interface für Touch Monitore lässt sich somit niemals mit Studio One benutzen. Hatte ich nicht erwartet, aber gut, jede DAW FIrma hat so ihre eigene Philosophie. Die API für sich zu behalten und offenbar nur ein paar 'Auserwählten' zur Verfügung zu stellen empfinde ich als Community-Unfreundlichen-Kreativitätskiller. Sorry, das kann ich aufgrund von 2 Jahren Bitwig-Erfahrung nicht anders ausdrücken, da sich dort die Community eigene Skripte bauen "darf".

Gerne lasse ich mich eines Besseren belehren, falls es OSC support gibt und eine allgemein zugängliche API !?
(Eine API, mit der man z.b. auch ein eigenes OSC Script schreiben könnte - so ist das bei Bitwig z.b. passiert. Bitwig hat auch keinen nativen OSC support, aber ein fleißiger Nutzer hat ein Script dafür geschrieben, dank zugänglicher API)

Meine Quellen:
OSC Steuerung nicht möglich: https://answers.presonus.com/29204/osc-support
https://answers.presonus.com/4112/is-there-open-sound-control-support-in-studio-one
https://answers.presonus.com/42708/when-is-presonus-going-to-configure-studioone-for-osc

Scripting in Studio One: hinter Schloss und Riegel!
https://vi-control.net/community/th...pting-capabilities-under-lock-and-key.122050/
https://www.kvraudio.com/forum/viewtopic.php?t=506195&sid=91990d114becd6bfef2290b04509098f&start=30
https://answers.presonus.com/13519/there-api-that-studio-one-remote-uses-which-can-used-other-apps

bei reaper kannst du alles bis ins letzte detail von extern (auch über osc) steuern.

 

[adrachin]

Ich kenne auch noch ein paar dutzend Programme mit der Möglichkeit über Scripting drauf zuzugreifen. Soll ich?

.... (;

 

[ksoa]

Also Cubase hat leider auch keine OSC Protokoll Unterstützung, was echt schade ist, aber wie Realist sagt, immerhin diese remote API seit Version 12.
Und damit auch manche Möglichkeiten, um z.b. an Tracknamen/Farben etc. zu kommen, um diese dann in Touch OSC anzuzeigen: https://forums.steinberg.net/t/osc-...passing-track-names-to-a-controller/819131/16
Ist zwar absolut kein Vergleich zu einem richtigen OSC protokoll und dessen Möglichkeiten (wo man fast die DAW auf einen Touchmonitor mit selbstgebauten Widgets 'spiegeln' kann sozusagen), aber erstaunlicherweise weit mehr, als Studio One zu bieten hat. Bei Ableton, Bitwig, Reaper und Co. sieht es natürlich ganz anders aus: Da hat man sehr gute Scripting Möglichkeiten.

Naja, bleibt mir nur zu sagen: Schade!

Noch vor ein paar Jahren hätte ich auf diesen Thread hier geschaut und mir gedacht "na, gut, dass mich so etwas überhaupt nicht juckt, wer braucht schon API Zugriff und wer braucht eine Touch OSC Remote Steuerung seiner DAW?", haha. Doch seit ich all das durch unglaublich spaßige, da maßgeschneiderte Workflows zu schätzen lernte (u.a. habe ich für Bitwig einen Audio-Overdub Looper gebaut!), gibt es für mich kein Zurück mehr und ich kann mich mit keiner DAW anfreunden, die das alles hinter Schloss und Riegel setzt. In diesem Sinne wird es wohl nichts mit mir und Studio One. Es sei denn, Mr. Ruschitzka baut mit mir zusammen für S1 7 eine Loopstation Extension samt OSC Script (um den Looper wie gewohnt per Tablet kontrollieren zu können).

 

[adrachin]

Wie wäre es damit:
fred-dev/OSC_MIDI_OSC

A straightforward cross-platform converter for OSC to MIDI and MIDI to OSC.

 

[Navar]

Naja, bleibt mir nur zu sagen: Schade!

Es gibt zum OSC schon einige Feature Requests, die auch teilweise ganz gute Votes bekommen haben, ich schätze mal, dass das Thema zumindest bekannt ist und evtl. wird es auch irgendwann umgesetzt. Hier würde ich immer empfehlen, die entsprechenden Feature Requests hoch zu voten und denen vielleicht dadurch mehr Aufmerksamkeit zu geben. Leider hat das FR System einen kleinen Haken, die Leute recherchieren oft vorher nicht, ob es dazu schon etwas gibt und erstellen dann erstmal einen eigenen Post.

Und ich finde es auch sehr schade, dass die bestehenden Scripting Möglichkeiten nicht der Öffentlichkeit zur Verfügung stehen, einiges was ich gerne hätte, könnte ich mir wahrscheinlich sogar einfach selber bauen. Und letztlich liegt es nur an der Dokumentation, der Rest ist ja schon da.
Ein klein wenig Verständnis habe ich dabei, sich den Support Aufwand vielleicht momentan nicht ans Bein binden zu wollen, wenn auf einmal überall Scripts auftauchen. Die Leute laden sich das Zeug dann irgendwo runter und beschweren sich hinterher bei der Host Software, dass irgendwas nicht richtig funktioniert. Das erlebt man ja teilweise auch bei Plugins, manche sind veraltet, manche einfach schlecht gecoded und wenn was schief geht und crasht, dann ist erstmal immer die Host Software schuld.

 

[ksoa]

Wie wäre es damit:
fred-dev/OSC_MIDI_OSC

A straightforward cross-platform converter for OSC to MIDI and MIDI to OSC.

Danke, sowas ist ganz nett, doch wenn man als Ausgangsmaterial und Hauptkommunikationsmittel nur Midi hat, ist das Endergebnis einer Übersetzung so beschränkt, wie Midi eben ist, im Vergleich zu dem, was OSC könnte! Hier eine grobe Darstellung:

 

[ksoa]

Es gibt zum OSC schon einige Feature Requests, die auch teilweise ganz gute Votes bekommen haben, ich schätze mal, dass das Thema zumindest bekannt ist und evtl. wird es auch irgendwann umgesetzt. Hier würde ich immer empfehlen, die entsprechenden Feature Requests hoch zu voten und denen vielleicht dadurch mehr Aufmerksamkeit zu geben. Leider hat das FR System einen kleinen Haken, die Leute recherchieren oft vorher nicht, ob es dazu schon etwas gibt und erstellen dann erstmal einen eigenen Post.

Und ich finde es auch sehr schade, dass die bestehenden Scripting Möglichkeiten nicht der Öffentlichkeit zur Verfügung stehen, einiges was ich gerne hätte, könnte ich mir wahrscheinlich sogar einfach selber bauen. Und letztlich liegt es nur an der Dokumentation, der Rest ist ja schon da.
Ein klein wenig Verständnis habe ich dabei, sich den Support Aufwand vielleicht momentan nicht ans Bein binden zu wollen, wenn auf einmal überall Scripts auftauchen. Die Leute laden sich das Zeug dann irgendwo runter und beschweren sich hinterher bei der Host Software, dass irgendwas nicht richtig funktioniert. Das erlebt man ja teilweise auch bei Plugins, manche sind veraltet, manche einfach schlecht gecoded und wenn was schief geht und crasht, dann ist erstmal immer die Host Software schuld.

Das hochvoten mache ich noch. Nach dem ersten Recherchieren hatte ich leider den Eindruck, dass das Feature Request schon seit Jahren im Raum steht und ungewiss ist, ob sich da jemals etwas tut. Zumal das viel grundlegendere Problem der mangelnde Api scripting zugriff ist. Denn wer weiss, was ein von S1 kommendes natives OSC script überhaupt leisten würde, wenn es jemals kommt? Vielleicht gibt es gerade mal die Transport Funktionen wie Playback, Record und vielleicht noch die Spurnamen und Fader aus? Dann hieße es das nächste Feature request zu eröffnen, für mehr Kontrolle über S1 per OSC, und wieder warten und hoffen - weil Presonus nicht den Nutzern erlaubt, diese OSC Schnittstelle selbst per API zugriff und scripting in die Hand zu nehmen...

Übrigens: ich halte absolut nichts von dem Argument, dass man sich support Anfragen ersparen will, falls scripting möglich ist.
Bitwig hat da zb eine simple Antwort auf Lager "we do not offer developer support". Ende aus. Wer sich auf scripting einlässt, muss wissen was er/sie tut, und vor allem, dass da kein Support zu erwarten ist. Mit der Ausnahme, wenn die API selbst buggy ist! Das wiederum fixt Bitwig bereitwillig, logischerweise.
Aber wir wissen ja leider eh nicht, was die Hintergründe für Presonus' Einstellung sind - ich glaube eher nicht, dass es SupportAnfragen-Angst ist, da diese wirklich easy handlebar wäre

 

[Can]

Ein klein wenig Verständnis habe ich dabei, sich den Support Aufwand vielleicht momentan nicht ans Bein binden zu wollen, wenn auf einmal überall Scripts auftauchen. Die Leute laden sich das Zeug dann irgendwo runter und beschweren sich hinterher bei der Host Software, dass irgendwas nicht richtig funktioniert. Das erlebt man ja teilweise auch bei Plugins, manche sind veraltet, manche einfach schlecht gecoded und wenn was schief geht und crasht, dann ist erstmal immer die Host Software schuld.

Danke, dann musste ich das schon nicht schreiben.

Übrigens: ich halte absolut nichts von dem Argument, dass man sich support Anfragen ersparen will, falls scripting möglich ist.
Bitwig hat da zb eine simple Antwort auf Lager "we do not offer developer support". Ende aus. Wer sich auf scripting einlässt, muss wissen was er/sie tut, und vor allem, dass da kein Support zu erwarten ist.

Das ist leider realitätsfern. Die User, die sich solchen Kram runterladen, haben natürlich zu 99,5% nicht die geringste Ahnung, worauf sie sich einlassen. Ich rede hier nicht von Developern, die Support brauchen (das wäre sowieso nur ein vergleichsweise extrem kleiner Anteil, da Developer tendenziell in der Lage sind zu lesen und die Geduld haben, einen Fehler auch selbst zu suchen), sondern von den Endusern der Scripts. Das Problem besteht ja schon mit (VST-)Plug-ins. Ein hoher Anteil der Studio One-Supportanfragen beziehen sich auf 3rd-party-Plug-ins, die crashen oder anderweitig nicht funktionieren. Die meisten User kapieren den Unterschied zwischen Plug-in und Host aber gar nicht erst.

Ich kann das aus allererster Hand untermauern, denn bei meinem Studio One-Add-on Harmony Wizard schreibe ich überall sehr deutlich, dass es sich nicht um ein PreSonus-Produkt handelt und PreSonus daher keinen Support dafür leisten kann.
In den Tagen nach dem Release von Harmony Wizard kam PreSonus aber nicht hinterher, da ein großer Anteil der User, die Harmony Wizard gekauft haben, das nicht verstanden haben und bei PreSonus Support-Tickets erstellt haben.

Also sich darauf zu verlassen, dass die User einer DAW (die sehr an Verbreitung gewonnen hat und jetzt aktuell auch noch wirklich günstig geworden ist) wissen, was sie tun, ist leider völlig verwegen.

Ich halte es also für ein berechtigtes Argument. Ich kann aber sagen, dass die Hauptgründe, warum es noch keine offizielle Unterstützung für User-Scripting + API + Dokumentation gibt, andere sind, und zwar Zeit- und Prioritätsgründe. Das Studio One-Team ist vergleichsweise sehr klein, so dass Prioritäten gesetzt werden müssen. Und die allermeisten Nachfragen sind halt jetzt nicht gerade User-Scripting.

 

[Navar]

Das hochvoten mache ich noch. Nach dem ersten Recherchieren hatte ich leider den Eindruck, dass das Feature Request schon seit Jahren im Raum steht und ungewiss ist, ob sich da jemals etwas tut.

Ja, das heißt aber nicht, dass das nie kommen wird. Wäre nicht das erst Mal, dass ein FR nach seeehr langer Zeit dann doch umgesetzt wird. (ich sag nur Custom Colors. ) Aber ich kann auch verstehen, dass man das frustrierend findet, weil das für einen selbst wichtig wäre. Die Vergangenheit hat aber auch gezeigt, dass da schon rein geschaut wird und das Entwicklerteam da nicht blind für ist, was sich die Community wünscht.

 

[Can]

Das hochvoten mache ich noch. Nach dem ersten Recherchieren hatte ich leider den Eindruck, dass das Feature Request schon seit Jahren im Raum steht und ungewiss ist, ob sich da jemals etwas tut.

Das trifft auf extrem viele Feature Requests zu, die mittlerweile "completed" sind. Ungewiss ist das vorher selbstverständlich immer, da keiner in die Zukunft sehen kann.

Highest voted questions in Completed Feature Requests - Questions & Answers | PreSonus

 

[ksoa]

Danke, dann musste ich das schon nicht schreiben.


Das ist leider realitätsfern. Die User, die sich solchen Kram runterladen, haben natürlich zu 99,5% nicht die geringste Ahnung, worauf sie sich einlassen. Ich rede hier nicht von Developern, die Support brauchen (das wäre sowieso nur ein vergleichsweise extrem kleiner Anteil, da Developer tendenziell in der Lage sind zu lesen und die Geduld haben, einen Fehler auch selbst zu suchen), sondern von den Endusern der Scripts. Das Problem besteht ja schon mit (VST-)Plug-ins. Ein hoher Anteil der Studio One-Supportanfragen beziehen sich auf 3rd-party-Plug-ins, die crashen oder anderweitig nicht funktionieren. Die meisten User kapieren den Unterschied zwischen Plug-in und Host aber gar nicht erst.

Ich kann das aus allererster Hand untermauern, denn bei meinem Studio One-Add-on Harmony Wizard schreibe ich überall sehr deutlich, dass es sich nicht um ein PreSonus-Produkt handelt und PreSonus daher keinen Support dafür leisten kann.
In den Tagen nach dem Release von Harmony Wizard kam PreSonus aber nicht hinterher, da ein großer Anteil der User, die Harmony Wizard gekauft haben, das nicht verstanden haben und bei PreSonus Support-Tickets erstellt haben.

Also sich darauf zu verlassen, dass die User einer DAW (die sehr an Verbreitung gewonnen hat und jetzt aktuell auch noch wirklich günstig geworden ist) wissen, was sie tun, ist leider völlig verwegen.

Ich halte es also für ein berechtigtes Argument. Ich kann aber sagen, dass der Hauptgrund, warum es keinen offiziellen Support für User-Scripting + API mit Dokumentation gibt, einfach Zeit- und Prioritätsgründe hat. Das Studio One-Team ist vergleichsweise sehr klein, so dass das Produktmanagement Prioritäten setzen muss. Und die allermeisten Nachfragen sind halt jetzt nicht gerade User-Scripting.

Gut, lassen wir es zählen als Argument, ich sehe auch wirklich ein, dass die Verunmöglichung von Skripting das Leben des Supports noch einen Tick leichter macht. Kein Scripting -> Garantiert keine Scripting Problem-Anfragen. Doch zu welchem Preis?

Ich bin ein viel zu großer Fan davon, wenn eine Community aktiv in ihrer Kreativität unterstützt wird, und eigene Lösungen finden und bauen darf. Das liebe ich einfach SO sehr, dass mir dieses "Da sollen ja keine supportanfragen kommen" Angst Argument etwas widerstrebt, auch gerade deshalb, weil es ja (siehe Bitwig, noch kleineres Team als S1!) absolut möglich ist, damit umzugehen.

Der Umgang ist dort simpel geregelt: Man lässt sich auf Supportanfragen dieser Art nicht ein. Eine Ablehnungsmail mit copy/paste zurückzuschreiben ist jetzt nicht Soooo schlimm und aufwendig. Viel schlimmer finde ich eben, wenn Kreativität einer ganzen community beschränkt wird. Für mich steht die prinzipielle Skripting-Verunmöglichung einfach in keinem Verhältnis zu einigen Copy/Paste Mails.

Ich hätte als Firma meine Freude daran, zu sehen, welche verrückten/genialen/sinnvollen Verbesserungen Ideen oder auch Verschlimmbesserungen ein Community-Hive-Mind zustandebringt. Zudem man in den TOS regeln könnte, dass jegliche Modifikations-Ideen am Ende 'übernommen' werden können, ohne Kompensation. Das wiederum ist dann finanziell Interessant, wenn die DAW in ihrem Funktionsumfang und Workflows genial wächst, wegen kostenlos beigesteuerten Skripten

Ein Beispiel aus der Gaming Welt: Ist es nicht unfassbar cool, was eine Community basteln und erschaffen kann, wenn Modding unterstützt wird? Was sind nicht für grandiose Spiele (Dota1) und Upgrades für das Hauptspiel (Skyrim) entstanden, alleine durchs Modding? Manchmal sind durch Modding sogar Spiele erst richtig 'gefixt' und mit Spaß spielbar geworden (Gothic 3 Community patch z.b.)
Die "Modding Szene" von DAWs, z.b. in Ableton und Co. feiere ich einfach ebenso sehr.

 

[Can]

Deswegen habe ich dir ja gesagt, dass das (soweit ich weiß) nicht der Hauptgrund ist. PreSonus lehnt User-Scripting überhaupt nicht per se ab. Bisher ist es eben noch nicht drangekommen, wie eben so viele andere Feature-Wünsche auch.

PreSonus ist eher ein Fan von offenen Schnittstellen, und es gibt ja schon einige offizielle und dokumentierte APIs für Entwickler:

Developer | PreSonus Software

PreSonus Software is working on software solutions for music production on PC, Mac, and mobile platforms integrating perfectly with PreSonus audio hardware.

presonussoftware.com

Aber eben bisher hauptsächlich für Plug-in-Erweiterungen und nicht. Und wer einen langen Atem hat, kann sich die bisherige Scripts (z.B. von Controllern wie Nektar) auch anschauen und theoretisch auch eigene Scripts mit den gleichen Möglichkeiten bauen. Aber es ist eben nicht öffentlich dokumentiert und vom UI her so aufbereitet, so dass jeder User da einfach rankommt.

 

[ksoa]

Deswegen habe ich dir ja gesagt, dass das (soweit ich weiß) nicht der Hauptgrund ist. PreSonus lehnt User-Scripting überhaupt nicht per se ab. Bisher ist es eben noch nicht drangekommen, wie eben so viele andere Feature-Wünsche auch.

PreSonus ist eher ein Fan von offenen Schnittstellen, und es gibt ja schon einige offizielle und dokumentierte APIs für Entwickler:

Developer | PreSonus Software

PreSonus Software is working on software solutions for music production on PC, Mac, and mobile platforms integrating perfectly with PreSonus audio hardware.

presonussoftware.com

Aber eben bisher hauptsächlich für Plug-in-Erweiterungen und nicht. Und wer einen langen Atem hat, kann sich die bisherige Scripts (z.B. von Controllern wie Nektar) auch anschauen und theoretisch auch eigene Scripts mit den gleichen Möglichkeiten bauen. Aber es ist eben nicht öffentlich dokumentiert und vom UI her so aufbereitet, so dass jeder User da einfach rankommt.

S1 kommt mit seinen Features immer mehr an ein exzellentes Rundum-Paket heran.

Wenn sich da eines Tages also eine grundlegende API Schnittstelle auftut, werde ich ziemlich begeistert sein, dann geht es für mich erst richtig los mit S1

 

[BodoH]

Einerseits verstehe ich den Wunsch nach individuell gestalteten GUI`s in DAWs und auch den Mehrwert, den Scripte bringen könnten.
Andererseits verstehe ich auch jene, welche nicht wollen, dass S1 zu einem großen Bastellladen wie z.B. Reaper verkommt.
Daher gibt es Hersteller die den klassischen Weg beschreiten wie S1, Cubase, Logic und eben auch welche die da offener sind wie eben bei Reaper. Wird man die API Schnittstelle freigeben, so wird S1 definitiv nicht mehr so sein, wie heute. Kann man also gut finden, aber auch kritischer sehen. Ich verstehe, dass manche Hersteller die Kontrolle behalten wollen.

 

[ksoa]

Ich verstehe, dass manche Hersteller die Kontrolle behalten wollen.

Die Frage ist halt: Kontrolle über was?
Wir sprachen bisher über den einzigen mir nachvollziehbaren Nachteil: Support Anfragen. Das kann nerven, ja. Lässt sich aber schnell abhaken mit Copy und Paste von "es gibt keinen scripting support, sorry".
Dann gäbe es noch die einmalige Mühe, die API in eine Liste zu schreiben mit ein paar Comments. Okay. Nicht die Welt.
Und worüber möchte man dann noch die Kontrolle haben? Dass Community Mitglieder irgendwelche Skripte bauen, die bei ihnen Lokal auf dem Rechner sind - kann doch allen vollkommen egal sein. Es ist ja selbst bei Reaper nicht so, dass alle an einer "Cloud DAW" angeschlossen sind, und sich alle customizations aller user gleichzeitig ansehen müssen
"Basteln" zu können ist nicht gerade etwas negatives, vor allem im Kontext von Musikmachen - und kreative Musik-mach-Lösungen zu erstellen?

 

[BodoH]

Dass Community Mitglieder irgendwelche Skripte bauen, die bei ihnen Lokal auf dem Rechner sind - kann doch allen vollkommen egal sein.

Wenn ich könnte, würde ich dir die Möglichkeit geben, deine Wünsche rein privat zu realisieren, damit du S1 in deinem Sinne nutzen kannst. Vielleicht kann dir da Can helfen, oder wendest dich mal direkt an Presonus, falls nicht geschehen? Wie schon jemand sagte, hat Presonus es wohl tatsächlich einigen "Auserwählten" ermöglicht. Musst mal schauen, vielleicht kannst du sogar mit einem Programmierer dort persönlich kommunizieren, einfach mal versuchen und gut begründen. Möglicherweise auch mit Gregor Beyerle? Offiziell wirds vermutlich länger dauern.

 

[Can]

Ich kann hier nicht weiterhelfen. Ich bin zwar vermutlich der Programmierer, der hier am meisten involviert ist, aber ich treffe keine Entscheidungen über Features wie User-Scripting. Gregor ist im Marketing von PreSonus und hat mit der Entwicklung gar nichts zu tun (davon abgesehen, dass wir abundzu gemeinsame Brainstorming-Sessions machen). Hier bleibt leider nichts anderes übrig als abzuwarten, bis es im Rahmen eines größeren Feature-Pakets mal dran kommt. Einzelne Features losgelöst von einem Programmbereich-Update finden bei Studio One eher selten statt.