Sounddiver Reloaded -- aus: Vintage, analog - und günstig

[mc4]

Re: Sounddiver Reloaded -- aus: Vintage, analog - und günsti

juce ist absolut geeignet dafür und hat ein sehr klares und konsistentes Konzept.
Habe ich früher oft benutzt.

 

[3456778674]

Re: Sounddiver Reloaded -- aus: Vintage, analog - und günsti

Eine Standalone-Software schraubt zudem nicht noch den Resourcenverbrauch der VSTs in der DAW in die Höhe - das sollte man auch bedenken.

Da man die DAW zum Aufnehmen nutzt, läuft die sowieso. Ein externes Programm erfordert daher immer rumfummeln mit virtuellen Midi-Kabeln, oder geplantes (teils umständliches) Aufteilen der Midi-Ports. Das VST bindet man mit einem Klick in ein neues Projekt passend ein. Insofern werde sicher viele den Plugin Ansatz wählen wollen.

Die Patchverwaltung braucht ein weiteres Feature: eine Scriptsprache. D.h. in den Anpassungen für einen Synth können (zur Laufzeit interpretierte) Scripte stecken. Denn die Workarounds gegen die Masse an schrottigen Patch-Verwaltungs-Funktionen diverser Synthesizer hat im Programmcode nichts zu suchen, das muss in den Adaptierungen stecken.
Die Adaptierungen müssen von nicht/wenig-Programmierern erstellt werden können! (Insbesondere auch ohne die komplette Entwicklungsumgebung, die ist nämlich nicht-trivial aufzusetzen. )

Wobei ich die Adaptierungen durchaus (nur) als Textdatei sinnvoll finde, nicht so wie im Sounddiver über 1000 Dialogfenster verstreut. Für XML-Dateien gibt es (Text-)Editor-Plugins, die muss man dann "nur" noch an die verwendeten Schlüsselworte anpassen.

 

[fab]

Re: Sounddiver Reloaded -- aus: Vintage, analog - und günsti

ja, menschenlesbare XML-dateien für anpassungen und presets sind extrem nützlich.
brainspawn forte macht das so, für "racks" und für control surfaces sowie für eigenarten von plugins. funktioniert sehr gut, so kommt mit der zeit eine bibliothek von anpassungen zusammen, copy/paste und suchfunktionen funktionieren.

 

[tomcat]

Re: Sounddiver Reloaded -- aus: Vintage, analog - und günsti

Ein VST / AU das nur mit MidiDaten "rumspielt" wird kaum Resourcen brauchen....

XML verwendet z.B. Mackie für die C4 Anpassungen

 

[Jockel]

Re: Sounddiver Reloaded -- aus: Vintage, analog - und günsti

Das was hier gewünscht wird, ist ja schon extrem technisch - das wäre eigentlich was für Leute wie Fetz. Da muss man quasi in Bytestreams träumen ...

LG
Jörg

 

[microbug]

Re: Sounddiver Reloaded -- aus: Vintage, analog - und günsti

@microbug
Richtig, da liegt die Schwerarbeit.
Sounddiver-Programmierhandbuch -> hast du ein PDF ?

Habe ich, anhängen geht nicht, ich packs mal auf meinen Webspace und schiks Dir als PN - außer es will hier noch jemand, dan bitte melden, PNs kann man ja an mehrere zugleich verschicken.

Wenn Umsetzung Standalone-VST kein Problem ist, machts das eingfacher. VST alleine erschlägt aber doch nicht alle Plattformen, da seit MacOSX ja AU angesagt ist, demnach geht doch ein VST nicht in Logic - sorry wenn ich dumm frage, ich hab lange pausiert (seit etwa 2004) und die meisten Sachen noch unter 9.x gemacht und fange mit MIDI jetzt erst wieder unter OSX an (mit etlichen Bauchlandungen).

Eine einzige Datei für die Sysex-Strings fände ich auch von Vorteil, bei Sounddiver war das ja auf 2 Teile aufgespalten: Bankdriver und Editoren, XML ist sinnvoll, und für die die nicht Text coden wollen kann man immer noch einen Editor bauen, aber die Sysex-Strings sind eh Hexcode (wobei die Eingabe mir bei Sounddiver auch oft auf den Zeiger geht, es hat etliche Anläufe gebraucht bis Michael endlich eine Copyfunktion für die Bankdriver einbaute).

Wenn VST sein soll, dann ist RealBasic eh draußen. Objective C hab ich mir mal bissl angeschaut, aber ich kapier diese C-Syntax einfach nicht, sorry, uCs programmier ich in Assembler (65xx/68xx-Kisten oder AVR), das versteh ich wenigstens Kann daher selbst wenig mitprogrammieren.

Was unterstützen eigentlich die Linux-DAWs?

Die Datenformate müssen halt mehr oder weniger frei einstellbar sein. Sounddiver konnte da schon recht viel, mußte aber bei Geräten wie Kawai K4 und XD-5, wo MSB und LSB der Oszillatorwellenform ewig weit auseinanderlagen (IIRC mehr als 6 Bytes) passen. Ich kann bei Bedarf gerne die Liste meiner nicht umgesetzten Ideen für Sounddiver hier posten, die ergaben sich einfach aus der Praxis mit den Geräten, wo ich an die Grenzen stieß.

Was gut wäre: Ein Konverter, der Sounddiver-Adaptionen liest und ins neue Format umsetzt, ebenso die Libs. Ich hab das Format mal irgendwann analysiert bzw Michael mir da auch mal was dazu gesagt, wie das gestaltet ist, da könnte ich dann was beisteuern, das wäre dann ja ein Zusatzprogramm und unabhängig vom Rest. Über die XML-Beschreibungsdatei könnte ich mir auch Gedanken machen, zumal ich eh gerade wieder mit Sounddiver zugange bin.

 

[mc4]

Re: Sounddiver Reloaded -- aus: Vintage, analog - und günsti

Also Google gibt mir SoundDiver User Manual. Version 3.0,
das reicht ja erstmal.
Möchte mich gerne mit dem Thema beschäftigen, aber ich kann wie gesagt nur kleinere Hilfen zusagen.
Mit juce habe ich AU, VST und RTAS Plugins geschrieben, für Linux aber noch nichts.

Wenn du das SoundDiver Format schon mal analysiert hast, hat man doch schon eine gute Grundlage für die nötige Datenstruktur.

Fehlt ein Lead- C++ Developer,
Wenn juce eingesetzt wird, könnte ich ein paar kleine Sachen beisteuern.

 

[microbug]

Re: Sounddiver Reloaded -- aus: Vintage, analog - und günsti

Also Google gibt mir SoundDiver User Manual. Version 3.0,
das reicht ja erstmal.

Da stehen die Details mit den Datenformaten nicht drin, ich PN Dir mal das Programming manual.

Mit juce habe ich AU, VST und RTAS Plugins geschrieben, für Linux aber noch nichts.

juce kenn ich nicht, das muß ich mir mal anschauen.

Wenn du das SoundDiver Format schon mal analysiert hast, hat man doch schon eine gute Grundlage für die nötige Datenstruktur.

ist schon was her, könnte auch noch Polyframe gewesen sein weil am Tel mit Michael verhackstückt, muß schauen wo ichs habe, ansonsten mach ich das halt nochmal, sozusagen als Abfallprodukt meiner Adaptionsbastelei gerade.

Die Idee mit Kurt Revis hatte ich auch schon, mit dem stand ich neulich wegen dem Unitor 8 Kontrollfeld in Kontakt. Mir fällt ansonsten noch Ingo Debus ein, der auf der Sounddiver-Liste aktiv ist und mit dem ich zuletzt die ASR-X-Anpassung zusammen gemacht habe, den kann ich mal ansprechen.

 

[3456778674]

Re: Sounddiver Reloaded -- aus: Vintage, analog - und günsti

@microbug: als Anpassungsspezialist solltest du deine Kompetenz nicht an der Bitpfriemelei des Datenhandlings verschwenden - das kann jeder Programmierer (... zumindest kann ich das... ).

Auswahl von ein paar "typischen" Synthesizern wäre sehr nützlich. Keine Exoten, und einigermaßen dokumentiert sollten sie sein.

Das Datenhandling kann man soweit abspalten, das man ein (Test-)Programm macht, dass die Midi-Daten anfordert, aufdröselt, und eine XML-Datei erzeugt, die die Parameter des Patches aufgedröselt enthält. Den Rückweg dazu natürlich auch, also die XML-Patch-Datei wieder einen, dem Synth verständlichen Midi-Datenstrom verwandeln und in den Synth schieben. (Dann kann man mit einem Texteditor den Patch schon bearbeiten. )
Datei und Midi-Schnittstellen-Handling nur rudimentär als Testumgebung, keine Bedien-Oberfläche.

Der wesentliche Punkt ist hier die Definition des XMLs für das Midi-Datenformat. Was man da falsch macht, holt einen bei jeder neuen Anpassung wieder ein, denn die muss man ja per Hand erstellen.

 

[haesslich]

Re: Sounddiver Reloaded -- aus: Vintage, analog - und günsti

Fehlt ein Lead- C++ Developer,
Wenn juce eingesetzt wird, könnte ich ein paar kleine Sachen beisteuern.

jop, ich auch. mit juce komme ich gut klar. allerdings bin ich kein ausgesprochener C++ programmierer. dennoch die einzige compilierte sprache, die ich beherrsche.

 

[3456778674]

Re: Sounddiver Reloaded -- aus: Vintage, analog - und günsti

C++ ist bei mir auch nicht so dolle... aber C (das kann ich) ist für diese Aufgabe bekloppt. (Bzw. wird man dabei bekloppt. )

 

[microbug]

Re: Sounddiver Reloaded -- aus: Vintage, analog - und günsti

@microbug: als Anpassungsspezialist solltest du deine Kompetenz nicht an der Bitpfriemelei des Datenhandlings verschwenden - das kann jeder Programmierer (... zumindest kann ich das... ).

Meine Spezialität waren zumindest zu 8bit-Zeiten reverse Engineerings, insofern ist mir die Bitpfriemelei nicht fremd. Aber Du hast schon recht, Adaptionen hab ich etliche erstellt (und da auch so meinen Kampf mit gehabt).

Auswahl von ein paar "typischen" Synthesizern wäre sehr nützlich. Keine Exoten, und einigermaßen dokumentiert sollten sie sein.

Hier hab ich als typischen nur den TX802 und noch einen SY99, der Novation KS, der in Arbeit ist, will nicht alle Befehle befolgen, das ist mir in den ganzen Jahren seit Polyframe noch nicht untergekommen. Das meiste geht aber, vor allem die Parameter Changes. Könnte leihweise noch andere Geräte bekommen, wie zB FS-1R. E5000 ist auch da, der GEM S3 is ein Exot mit fiesem Handshake, dann wäre da noch mein QY700 mit XG-Tönspuck drin. Die Dinger sind alle gut dokumentiert, mein Archiv hat auch noch die Dokus zu den Geräten, die ich zu Sounddiver beisteuerte (hab auch noch alle Adaptionen mit Helps im Quelltext da).

Bankmanagement sollte halt so sein wie bei Sounddiver, plus freiem Handshakeformat und weiteren Funktionen, zB NOP-Bytes, die überlesen werden. Sowas braucht man zB für die Novation KS-Serie, die im Request/Dump die Firmware-Revision mit zurückgeben. Muß mal meine alten Aufzeichnungen rauskramen gehen ...

Edit: alte Notizen zumindest in Papierform gefunden, incl. etlichen Sysex-Dokus. Meine Herren, die strotzden nur so vor Fehlern. Übelste Vertreter: Ensoniq SQ-R und Yamaha TX-81Z. Ich erinner mich jedenfalls noch gut an diverse Kämpfe beim Erstellen der Adaptionen mit diesen Dingern. Einige Sachen waren üble Tipparbeit, weil Werte als 0-99 angezeigt, aber 0-127 abgespeichert wurden. Mußte man über Textobjekte gehen und die komplette Konversionstabelle einhacken - wenn eine abgedruckt war (bei Ensoniq schon, beim Yamaha TX-81Z nicht, beim ähnlichen bzw kompatiblen TQ5 dann aber doch).

 

[3456778674]

Re: Sounddiver Reloaded -- aus: Vintage, analog - und günsti

Der von mir gemeinte Datenmanager ist noch kein Bankmanager, der stellt wirklich nur die Datenschicht bereit.
Ein Bankmanager setzt darauf auf. Anforderung und Speicherung von Patches handhabt jeder Synth etwas anders. Ich würde da einen Ansatz wählen, in dem jeder Synth seine Fähigkeiten bekommt. Keine (hakeligen) Workarounds um alles in ein einheitliches Konzept zu pressen.

Ich kenne Sounddiver nur von der FS1r Version, den Bankmanager habe ich dort nur als semifunktionalem und nervigen Anhang erlebt, der sehr langwierig an Dingen gescheitert ist, die ich gar nicht haben wollte.

Was meinst du mit "freiem Handshakeformat"? Wirklich frei setzt einen Turing-vollständigen Automaten voraus. Vulgo: eine Scriptsprache muss her. Die löst an vielen Stellen Probleme - u.a. auch die genannte 99<->127 Umsetzung. Hat aber auch ein paar Nachteile: mit einer nur per XML-Beschreibungsdatei gesteuerten Anpassung kann man außerhalb der geplanten Anwendung mehr anfangen. (Portierungen und ganz andere Anwendungen, z.B. automatisches Erstellen von Controller-Maps. )

 

[marv42dp]

Re: Sounddiver Reloaded -- aus: Vintage, analog - und günsti

Juce dürfte tatsächlich das beste Mittel dafür sein.
http://ctrlr.org/ ist damit sehr erfolgreich, eventuell kann man darauf aufbauen - quasi den Librarian so drumrumbauen, dass er die crtlr als Plugins lädt.

 

[microbug]

Re: Sounddiver Reloaded -- aus: Vintage, analog - und günsti

Was meinst du mit "freiem Handshakeformat"? Wirklich frei setzt einen Turing-vollständigen Automaten voraus. Vulgo: eine Scriptsprache muss her. Die löst an vielen Stellen Probleme - u.a. auch die genannte 99<->127 Umsetzung. Hat aber auch ein paar Nachteile: mit einer nur per XML-Beschreibungsdatei gesteuerten Anpassung kann man außerhalb der geplanten Anwendung mehr anfangen. (Portierungen und ganz andere Anwendungen, z.B. automatisches Erstellen von Controller-Maps. )

Frei im Sinne von selbstdefinierbaren Nachrichten für Request und die zu erwartende Antwort. Handshake war in SD bislang nur im Roland-Format mit eingebaut, Geräte wie Roland JX-10 oder GEM S2/S3, die wirklich mit Handshake arbeiten, ließen sich damit nicht ansprechen. Das Format des JX-10 ist im Netz (zB bei Colin Fraser) dokumentiert. Bei Geräten wie denen von GEM kommt noch hinzu, daß sie im ersten Datenblock angeben, wieviel Daten (Bytes) im nächsten Paket gesendet werden, auch das blieb bisher unberücksichtigt. Was eine weitere Tipperei ersparen würde, wäre, besonders für Parameter Changes, daß man EINEN Sysex-String als Muster vorgeben kann, der für den kompletten Editor gilt, und nur Adresse+Daten des Parameters sich ändern. Bei SD mußte man für jedes Objekt auch den vollen String angeben, außer bei Roland-Sysex, welches mit Speicherdumps und Adressen arbeitet (wie Yamaha inzwischen auch).

Ich kann da bei Bedarf entsprechende Beispiele posten.