The perfect Synthesizer Editor

Dieses Thema im Forum "PC" wurde erstellt von Anonymous, 28. November 2005.

  1. Anonymous

    Anonymous Guest

    Wie w

    Wie würde der aussehen?

    Also in "Konkurrenz" quasi zu SoundDiver, MIDIQuest und JSynthLib.

    Bin grad am rumspinnen, da mir JSynthLib nicht mehr wirklich gefällt
    und da auch nix mehr zu passieren scheint und Java dafür
    auch nicht so wirklich das wahre ist, auch wenn es von der Programmierung
    her simpler ist als C++.

    Es gibt für C++ nämlich ein hübsches Framework namens JUCE,
    das auch von Tracktion benutzt wird:
    http://www.rawmaterialsoftware.com/juce/

    Blöd ist nur, dass ich von C++ nicht so wirklich die Ahnung habe.

    Also: Ist bis jetzt alles nur Rumspinnerei, ist unwahrscheinlich, dass da wirklich was draus wird.
     
  2. Anonymous

    Anonymous Guest

    Hier mal meine Punkte auf die Schnelle:

    Aus Programmiersi


    Hier mal meine Punkte auf die Schnelle:

    Aus Programmiersicht:

    Framework:
    - Juce (damit die Plattformen Mac, Win und Linux unterstützbar)
    Sprache:
    - C++ (damit ist kein JRE nötig und die Anwendung sollte nicht so träge sein, falls man nicht totalen Koi programmiert)

    Grundlegendes:
    - Geräte-Unterstützungen per Text-Datei (ggf. XML-Format),
    damit nicht-Programmierer diese erstellen können (im Gegensatz zu JSynthLib und IMHO dessen grösstes Problem)
    - Librarian & Editor Unterstützung trennen (?),
    beim Editor kommen z.B. Positionsangaben für die einzelnen Widgets dazu
    - Unterstützung von bidirektionaler Kommunikation (Handshakes z.B.)
    - Kein Scannen (wie bei SoundDiver), Geräte-Unterstützungen sollen
    manuell hinzugefügt (einfach Textdatei in entsprechendes Verzeichnis kopieren) werden und dann ggf. auf Integrität testen (?)
    - Trennung eigentliches Programm und Geräte-Unterstützungen,
    Vorteil: Kleinerei Updates, kleinere Downloads
    - Verschiedene Geräte-Kategorien (Synthesizer/Sampler, Effektgeräte, ...), bei nem Effektgerät macht ein "Play"-Knopf ja z.B. wenig Sinn

    Nice2have:
    - Kleiner Sequencer, der das programmieren erleichtert
    - Eigene Widgets erstellbar (Aussehen, usw.)
    - Ein "Geräte Assistent", mit dem sich Textdateien für Librarian und Editor-Support erstellen lassen, Königweg wäre natürlich noch ein GUI-Builder dafür, aber das wird dann heftig.
     
  3. rsmus7

    rsmus7 -

    h

    hört sich ja ganz nett an

    schön wäre noch wenn es eine import funktion gäbe für schon bestehende
    presets von den andern proggis, aber das ist wohl nur ein traum.

    ansonsten find ich die idee super.

    hoffentlich wird´s was.
     
  4. Anonymous

    Anonymous Guest

    Exportieren in reines SysEx, importieren daraus.

    D


    Exportieren in reines SysEx, importieren daraus.

    Dürfte doch kein Problem sein?

    Also ans reverse engineering von irgendwelchen File-Formaten werde ich mich selber jedenfalls nicht begeben. ;-)
     
  5. tomcat

    tomcat -

    OSX & Windows ist definitiv Voraussetzung f

    OSX & Windows ist definitiv Voraussetzung für eine breite Unterstützung (durch Leute die Gerätetreiber erstellen).

    Die Treiberdateien sollten Cross Plattform portabel sein (sind sie durch XML eh).

    Etwas schwieriger wird sicher die Abhängigkeiten bei z.B. Soundsets aufzulösen (z.B. Wavestation Patch + zugehörige Wavetables).

    Eine gute Pre-Listen Funktion für die Sounds (über den Edit Buffer des Synths, falls vorhanden), die evtl. mehrere umschaltbare Noten/Sequenzen zum Vorhören bietet.

    Ein guter Check auf Doubles (Doppelte Patches in der DB), evtl. mit Aliases

    Treiber sollten flexibel sein (d.h. der selbe Treiber für z.B. Waldorf XT & XTk). D.h. gewisse Teile sollten umschaltbar sein (f. Features die nur das eine Modell bietet, Keyboard, Icon), der Coretreiber sollte aus Gründen der einfachen Wartung der selbe sein.
    Gleiches gilt für verschiedene OS Versionen des Synths. 1 Treiber für alle Versionen.
     
  6. Anonymous

    Anonymous Guest

    [quote:7186a9b86c=*tomcat*]
    Treiber sollten flexibel sein (


    Ja, sowas ähnliches hatte ich mir auch überlegt.

    Bei XML könnte man das vielleicht mit nem Attribut "Exception" für "gilt nicht für dieses oder jenes Modell" und nem umgekehrten "gilt nur für dieses oder jenes Modell" machen oder reicht vielleicht ein Attribut "Exception"?
    Ob das in der Praxis auch ordentlich funzt, weiss ich allerdings auch nich.

    Edit: Ich glaub, ich fang auch erstmal mit Ideen für das Format zu den "Geräte-Treibern" an.
    Wenn ich das nich auf die Reihe kriege, kann ich das Ganze eh vergessen. ;-)
     
  7. tomcat

    tomcat -

    Und vor allem die M

    Und vor allem die Möglichkeit zwischen autom. Erkennung des Synths/Version und manueller umschalten zu können.
    Damit meine ich nicht die Erkennung "welcher Synthesizer" sondern nach man. Selektion des Synths ("Waldorf uWave II/XT/XTk) die Auswahl "welches Modell" ala "uWaveII/XT/XTk" bzw. OS 2.00 oder OS 2.11.

    Besser mehr manuell als zuviel automatisch(e Troubles).
     
  8. Anonymous

    Anonymous Guest

    [quote:7eb5c211ef=*tomcat*]
    Besser mehr manuell als zuviel


    Ja, das meinte ich hiermit:

    Hatte da schon so meine Probleme mit der OEM-Version von SoundDiver für meinen FS1R. :roll:
     
  9. tomcat

    tomcat -

    Besser als die DateiInVerzeichnisKopierVariante w

    Besser als die DateiInVerzeichnisKopierVariante währe evtl. eine zentrl. Configdatei wo du die Treiber in der gewünschten Reihenfolge eintragen kannst, mit Midi Ports usw.

    Hat a. den Vorteil das diese auch leicht über ein Frontend konfigurierbar wäre und b. könntest du auch so mehrere identische Synths in deinem Setup haben

    Die kann man auch im Nachhinein einfach um weitere Parameter ergänzen (ala Autoconfig, nur Bankmanager, Editor,....)
     
  10. Ein Universal-Editor ausserhalb von Sound-Diver ist w

    Ein Universal-Editor ausserhalb von Sound-Diver ist wünschenswert, es gibt da ja noch so'n PC-Unieditor (Name? UK?)


    Bis das jedoch alles in saubere Bahnen kommt werde ich mich doch durchringen und mir mal für dies und das ein Device-Map in SX3 basteln.
     
  11. tomcat

    tomcat -

    Dachte SK3 hat eh sowas

    Dachte SK3 hat eh sowas ähnliches wie SD integriert?

    Btw. was ist eigentlich aus dem Open Letter an Apple bwzgl. Sounddiver Weiterführung / Integration in Logic geworden?
     
  12. Anonymous

    Anonymous Guest

    [quote:554a5e6869=*micromoog*]Ein Universal-Editor ausserhal

    Ansonsten kenn ich nur MIDIQuest.

    Stimmt auch wieder. Gute Idee! :)
     
  13. Moogulator

    Moogulator Admin

    huhu, der ansatz ist richtig.. es sollte allerdings noch sch

    huhu, der ansatz ist richtig.. es sollte allerdings noch schnell genug sein..

    das graphische gepatchworke von SD wäre aber zu vermeiden.. lieber systemschieberegler ,die man auch auf monitorgrösse optimieren kann.. einige adas waren in SD ja in der hinsicht sehr ungünstig ausgeführt..

    es spricht nix gegen grafische ENVS und auswahlisten, die können aber gern systemkonform sein, ohne viel "3d look" und schnickschnack.. lieber übersichtlich angeordnet .. das wäre super.. plattformübergreifend ist das ja dann auch, wäre natürlich OBERHAMMER ,wenn nicht nur win und OSX ,sondern auch linux dabei wäre (bei deinen vorgaben, ging das ja)..

    die sysex string eingabe und ausgabe per xml ist nicht doof, das sollte auch ex/importiertechnisch einfach sein, ähnliche strukturen zu übernehmen, zB ein TG77 modul aus einem DX7 modul zu basteln.. weil: multisegment und OPs etc.. gibts ja auch..

    ich sag das bewusst aus user-ecke, obwohl ich auch ITler bin.. aber ich muss ja nicht proggen,..

    setze mal bei SD an, weniger sollte es nicht sein, er sollte jedoch bei der integration einige spinnersachen weglassen.. das automatische erkennen braucht man auch nicht wirklich.. man hat idR nicht so viel,das man das nicht mal eben selber zusammenklicken könnte..

    library mit verschiebbaren sounds/management wäre wichtig und eine autonennfunktion für waves und wavetables oder sowas bei denen ,die nur nummern haben,damit man sie intern sortieren kann..

    teilwürfel: anwenden von zufall nur auf bestimmte bereich (nicht modmatrix zB ).. und limitierung auf "etwas ändern beim OSC, mehr ändern beim filter.."

    die umstandskekse und programmerersatzsachen: sollte man schon auch drin haben.. sprich: pg300 lookalike wettbewerb musses nicht sein, aber brauchbar, auch für teile, die wirklich nicht so gute sysexler sind ,wie die frühen werke der firmen a-z ;-)
    (meint: die umständliche casio struktur so gut es geht umschiffen ... oder die "ich kann nur einen sound" manie der alten rolands.. wenns geht..)
     
  14. Anonymous

    Anonymous Guest

    Das bl

    Das blöde an SoundDiver ist, dass ich da nur die FS1R-Oem-Version habe und die bei mir nich läuft. :evil:

    Obwohl: Zwischenzeitlich hab ich ein neues MIDI-Interface dazu bekommen (MOTU), vielleicht sollte ich es ja nochmal probieren. :?
     
  15. tomcat

    tomcat -

    Skins w

    Skins wären nett, dann ist jedem geholfen :)

    Aber mal back to the roots
     
  16. Moogulator

    Moogulator Admin

    hmm, f

    hmm, für SD braucht man nen logic key.. kannste notfalls hier mal ansehen..
    das ansich nen guter ansatz bei SD, zzt noch der beste...

    midiquest ist superlahm und jsynthlib, naja.. brauchmerganettdrübberrädde(tm)
     
  17. Anonymous

    Anonymous Guest

    [quote:15896cef2f=*Moogulator*]hmm, f

    Aber für die OEM-Version doch ned,
    die war ja beim FS1R dabei auf CD.
     
  18. prolet

    prolet -

    nochmal zum Topic:
     
  19. [quote:fdf5de7507=*prolet*]nochmal zum Topic:
    [quote:fdf5de


    Da der Admin grad nich da ist...
    :hallo:

    zum Thema zurück...
    Abschreck: :shock: habe mich mit den Mixermaps alias Devicemaps noch nicht wirklich beschäftigt, ist das wirklich so'ne Krücke?
     
  20. Moogulator

    Moogulator Admin

    [quote:5749466aa1=*sonicwarrior*][quote:5749466aa1=*Moogulat

    das ist vermutlich noch SD1 oder sowas.. möglicherweise.. auf OSX läuft das SD2 beta 2 jedenfalls nur mitm key, die alten waren noch sone üble diskettenaktion,wenn mal die platte stirbt , ist man ein SD los..
     
  21. Anonymous

    Anonymous Guest

    Nee Version 2, hab aber auch ein Update auf 3 von Emagic
    be


    Nee Version 2, hab aber auch ein Update auf 3 von Emagic
    bekommen.

    Wie gesagt, ist halt ne OEM-Version, also blos für den FS1R, für sonst gar nix.

    @Thread:

    Werd mal über Weihnachten schauen, eigentlich hab ich ja keine Zeit und noch genug andere Sachen vor.
    Nicht das ich mich übernehme. ;-)

    Ohne Mit-Entwickler wird das eh nix, bräuchte zumindest je einen für Mac und Linux.

    Aber ohne ein konkreteres Konzept frage ich lieber gar nicht nach, ob jemand mitmachen will/kann. ;-)

    Edit: Ganz vergessen: Wenn, wird das Ganze ein Open-Source Projekt.
    Ne überbordende GUI wird das Ding wohl kaum kriegen, da seh ich auch
    nicht ganz den Sinn hinter, man soll das Ding ja nicht die Ganze anstarren
    und staunen, sonden benutzen.
    Und Skins finde ich auch ziemlich unwichtig, glaube kaum, dass sowas reinkommt.
     
  22. prolet

    prolet -

    ok, vielleicht kann ich ja mal versuchen zusammenzufassen, w

    ok, vielleicht kann ich ja mal versuchen zusammenzufassen, wie der "perfect syntheditor" so ungefähr aussehen soll:
    1.) Geräte-Setups für vorhandene Synths werden erstellt bzw., falls schon vorhanden, einfach geladen.
    1a)sonicwarriors Idee war, das ganze auf Textdatei-Basis zu erstellen (ausserhalb des Programms).Finde ich auch gut, in dem Falle würde man diese (xml) Datei einfach laden und der SysExDump könnte auf Buttondruck losgehen.
    1aa)Diese xml Datei müsste auch für nicht-Programmierer leicht zu erstellen sein, etwa mit Vorangaben ala
    #trage in die nächste Zeile den MidiIn-Port ein
    .....
    (weiss nicht, ob das mit der xml - Programmierung konform ist)
    1b)welche Angaben müssen auf jeden Fall gemacht werden?
    >MidiIn/Out port
    >MidiCh bzw Basic Channel bei multimbralen Synths
    >DeviceNr, falls mehrere gleiche Geräte (aber wer hat das schon)
    >falls neues Device: natürlich der ganze SysEx-Kram (Sysex Preset data request string usw.)
    1c)vorhandene MidiIns und -Outs müssen erkannt werden
    1d)Spezialfälle (RolandChecksum) müssen gemeistert werden
    1e)expansion boards sollten wenn möglich erkannt werden

    2)wenn der Synth gedumpt ist, werden die Sounds übersichtlich angezeigt . Der Dump kann jetzt gespeichert werden (auch, damit man nicht jedes mal minutenlang auf die Beendigung des Dumps warten muß sondern stattdessen einfach von der Festplatte laden kann).
    Durch Klick wird ein Sound in den Editbuffer geholt und kurz angetriggert.(kleine Sequenz?)

    3)auf einer Edit-Seite kann der gewählte Sound ummh... editiert werden.
    3a)Falls es noch keine Anpassung gibt, können Bedienfelder generiert werden. Diesen werden Parameter zugeordnet, die bei Bedienung gesendet werden.
    3b1)Diese Parameter können flexibel MidiCC oder SysEx Daten sein.Der Midi-Kanal (von CC) ist ebenfalls flexibel einstellbar.
    3b2)auf jeden Fall Midi-learn Funktion - wenn irgend möglich, auch für SysEx (Synth: Tx Edit data=On+ Faderbewegung=>das Programm erkennt, welche Bytes verändert werden)
    3c)durch copy/paste auch mehrerer Objekte kann man Zeit sparen
    Zu 3 sehe ich allerdings folgendes Problem, wenn die Geräteunterstützung zusammen mit den "Widgets" (Fader/knobs/data entry/textFelder,... in einer einzigen (großen)xml-Datei gespeichert wird.Von den Cubase Devices (wo ja auch alles in einer xml Datei gespeichert ist) weiss ich jedenfalls, daß dieser Grafikteil ein ziemlich unentwirrbarer, großer Block ist, teilweise mehrere Mb groß. Darin sind Position, Type, Bezeichnung ("Cutoff" u.ä.) und eventuell importierte Bitmaps hexadezimal (?) gespeichert. So ein Chaos wäre absolut nicht wünschenswert.( Kann gerne mal eine CubaseSx3 xml-Datei uploaden) Stattdessen wäre eine übersichtliche Ordnung besser, wie etwa
    <parameterNr=...
    <parameterVariable=...(Sysex/CC#)
    <parameterRange=...
    <parameterObject=...(knob/fader/switch...)
    <parameterObjectPositionX=...usw.
    ps Gui muß ja nicht "überbordend" sein, aaaber: wenn das Editieren Spaß machen soll, sollte die Grafik schon stimmen. (Beispiel)
    pps über die Integrierung in vorhandene Sequencer-Software wurde noch gar nicht gesprochen (Aufnahme von CC daten in Logic/Cubase).Ist aber wahrscheinlich zu kompliziert fürs erste (?)
    ppps autom. Erkennung wäre IMHO übertrieben
    pppps openSource ist sowieso besser, geht aber in diesem Falle eigentlich gar nicht anders, weil 1. niemand sämtliche grade oder jemals angesagten Synths zu Hause rumstehen hat und 2. niemand wirklich Lust hat bis zum Lebensende SysEx-Strings einzugeben
    Naja, langes posting, hatte mir allerdings auch schon öfters Gedanken zu diesem Thema gemacht, grade eben weil Steinberg mit SX3 gezeigt hat, wie man's halt nicht machen sollte
     
  23. Anonymous

    Anonymous Guest

    Nee, also Librarian und Editor-Unterst

    Nee, also Librarian und Editor-Unterstützung wollte ich in separate Dateien
    packen.

    Grafische Oberfläche: Da muss man halt auch erstmal nen Grafiker finden.

    Bevor man sich über ne tolle Oberfläche (ich meine jetzt von Farben, Grafiken, usw. her, nicht von der prinzipiellen Bedienung) Gedanken macht, sollte das Programm schon stehen und funzen.
    Was bringt ne schöne Oberfläche ohne Funktion?

    3 halte ich für überflüssig, so wie ich das verstehe,
    das Ding soll ja ein Editor und kein Software-MIDI-Controller werden,
    diese Funktionalität bieten ausserdem auch so ziemlich alle aktuellen Sequencer, soweit ich weiss.

    Zum Thema: OpenSource: Geht schon ohne:
    Die Geräte-Unterstützungen sollen ja ohne Programmier-Kenntnis machbar sein, also reine Textdatei.
    Da brauch das Programm nich OpenSource zu sein.

    Allerdings wird sonst keiner mit machen und das Programm wird tot geboren und im Linux-Bereich wird es auch nur ein Gähnen abkriegen,
    weil man für alle möglichen Distris Packages liefern muss.

    Geld kann man mit sowas sowieso nicht (mehr) verdienen.
     
  24. Schade, dass du das in C machen willst.
    Ich bin eher der J


    Schade, dass du das in C machen willst.
    Ich bin eher der Java Programmierer und wäre auch bereit da mit zu machen, aber ich bin mir nicht sicher ob meine C++ Kenntnisse dafür noch gut genug sind.

    Die Adaptionen mittels XML zu machen sehe ich auch als gute Idee an.

    Interessant wäre noch eine Remote Edit Möglichkeit. Einfach 8 frei definierbare MidiController nehmen und in das XML Format optionale Tags einbauen im Stile vom <parameter name=.... ><remote page=1 controller=1/></parameter>
    Dann könnte jeder 8 beliebige Controller von einem x beliebigen Synthesizer nehmen und hätte somit eine einfache aber wirksame Remote Edit implementierung. Wenn es mehr als 8 Controller gibt werden dann mehrer Pages gleichzeitig dargestellt.
    Die Gui sollte dann eine kleine Zahl neben dem Paramter anzeigen, so wie es glaube ich der V-Synth Rack macht.
     
  25. Anonymous

    Anonymous Guest

    Wie gesagt: In C++ bin ich auch nicht gerade besonders fit.


    Wie gesagt: In C++ bin ich auch nicht gerade besonders fit.

    Für Java gibt's ja schon JSynthLib und Java ist eben schon recht träge und so.
     
  26. cereal

    cereal -

    [quote:cb07d6ca77=*sonicwarrior*]Bin grad am rumspinnen, da

    Was ist denn das Problem mit Java?
    Okay... ich habe jetzt noch nie ernsthaft in der Sprache programmiert, aber es ist portabel und mittlerweile auch nicht mehr so mordslangsam, wie auch schon.
    Ich muss das jetzt einfach gesagt haben, so als GNU/Linux-Benutzer, der einigermassen glücklich darüber ist, dass es mit JSynthLib immerhin einen netten grafischen SysEx-Editor gibt, der darauf läuft... auch wenn keines meiner Hardware-Geräte davon unterstützt wird...
     
  27. tomcat

    tomcat -

    Leider sind die Java Sachen immer ein bischen lahm....

    Leider sind die Java Sachen immer ein bischen lahm....
     
  28. tomcat

    tomcat -

    [quote:9f08aa36d6=*prolet*]ok, vielleicht kann ich ja mal ve

    Nachdem ich zu blöd bin das quote einfach mit Kommentaren zu versehen, nachfolgend oldschool mit -- am Anfang. So meine Gedanken dazu.

    1.) Geräte-Setups für vorhandene Synths werden erstellt bzw., falls schon vorhanden, einfach geladen.

    -- in erster Linie erstellen, schon vorhandene zu importieren wäre zwar nett aber ziemlich kompliziert

    1a)sonicwarriors Idee war, das ganze auf Textdatei-Basis zu erstellen (ausserhalb des Programms).Finde ich auch gut, in dem Falle würde man diese (xml) Datei einfach laden und der SysExDump könnte auf Buttondruck losgehen.

    -- so im guten alten Unix Style. Ist so gut zu programmieren. In einem Subverzeichnis die Treiberdateien und in einem anderen die Configdateien. Dort steht dann drinnen welche Treiber geladen werden sollen usw.

    1aa)Diese xml Datei müsste auch für nicht-Programmierer leicht zu erstellen sein, etwa mit Vorangaben ala
    #trage in die nächste Zeile den MidiIn-Port ein

    -- Ich denke 1 Dokument mit Beispielen würde reichen. Da kann dann jeder draus die Treiberdateien ableiten.

    (weiss nicht, ob das mit der xml - Programmierung konform ist)
    1b)welche Angaben müssen auf jeden Fall gemacht werden?
    >MidiIn/Out port
    >MidiCh bzw Basic Channel bei multimbralen Synths
    >DeviceNr, falls mehrere gleiche Geräte (aber wer hat das schon)
    >falls neues Device: natürlich der ganze SysEx-Kram (Sysex Preset data request string usw.)

    -- das sollte zusammen mit dem zu ladenden Treiber in die zentrale Configdatei, nicht in den Treiber selbst

    1c)vorhandene MidiIns und -Outs müssen erkannt werden

    -- geht auch ohne, wäre natürlich nett

    1d)Spezialfälle (RolandChecksum) müssen gemeistert werden
    1e)expansion boards sollten wenn möglich erkannt werden

    -- da hatten wir oben mal die Idee das über Bedingungen zu lösen. Diese könnten autom. oder auch manuell als Zusatzparameter zum Treiber in der Configdatei angegeben werden

    2)wenn der Synth gedumpt ist, werden die Sounds übersichtlich angezeigt . Der Dump kann jetzt gespeichert werden (auch, damit man nicht jedes mal minutenlang auf die Beendigung des Dumps warten muß sondern stattdessen einfach von der Festplatte laden kann).

    -- einmal Anzeige des aktuellen Synth Inhaltes und einmal Anzeige der Library.

    -- Drag & Drop dazwischen. Multiple Selections vorsehen! Abhängigkeiten auflösen (Patch/Wavetables z.B.). Auf Duplikate checken.

    -- Extremfall ist z.B. die Wavestation, da gibts über 10.000 Presets. Da sollte also auch in der Library eine Gruppierung oder Kategorisierung möglich sein. Und die kann leider auch nur Bank Up&Downloads, soweit ich mich erinnern kann.

    Durch Klick wird ein Sound in den Editbuffer geholt und kurz angetriggert.(kleine Sequenz?)

    -- yep. Nett wäre hier die Möglichkeit verschiedene Noten oder Sequenzen anspielen zu können. Dann können Flächen bzw. Leads oder Drums besser vorgehört werden

    3)auf einer Edit-Seite kann der gewählte Sound ummh... editiert werden.

    -- yep

    3a)Falls es noch keine Anpassung gibt, können Bedienfelder generiert werden. Diesen werden Parameter zugeordnet, die bei Bedienung gesendet werden.

    -- Die Treiber sollten mehrstufig programmiert werden können. Von "Nur Dump Tool" über Library Tool bis hin zu Remote Edit Tool.

    Die ganze Remote Edit Geschichte ist natürlich wünschenswert und sollte im Hinterkopf behalten werden, verschrecken wir aber besser nicht den Threadstarter mit zuvielen Wünschen ;-)
     
  29. Moogulator

    Moogulator Admin

    [quote:8b9dd8881a=*sonicwarrior*]Nee Version 2, hab aber auc


    das find ich eher gut und gesund..

    ja., mit SD ist das dann in etwa der stand.. zumindest bei mir lief das ding immer.. (mac , auffm pc hatte ich das nie..)

    ich finds aber super,das du das auf allen plattformen inkl <a href=http://www.sequencer.de/software_synthesizer/linux.html>Linux</a> machen willst.. du hast meinen support.. schon deshalb ..

    genereller workflow:
    der von SD ist nicht sooo falsch..
    kein autoscan oder sowas..

    eine sound oberfläche für listen in bänken.. das ist sehr sinnvoll.. man könnte dann aber noch eins mitbedenken:

    abspeichern bei unklarheit ,ob man was löscht im rechner oder sogar in einem freien speicher (init oder leer als erkennung..?)

    auch das verschieben und umnennen sollte einfach gehen in diesem mode..

    das editing geht dann durch anwählen.. man sollte es aber deutlich merken: ab jetzt wird ein sound editiert..
    und danach abspeicherbar und man sieht eine übersicht des speicherinhalts mit namen, so kann man besser entscheiden wo was frei ist.. vielleicht sogar mit vorhören.. das wäre dann perfekt..
     
  30. Anonymous

    Anonymous Guest

    Bin grad auf nen IBMDevWorks Artikel zum Thema *Garbage Coll

    Bin grad auf nen IBMDevWorks Artikel zum Thema "Garbage Collection" gestossen:

    http://www-128.ibm.com/developerworks/j ... 09275.html


    Frag mich, ob ein Garbage Collector hier Sinn macht.
    Würde auf jeden Fall einiges erleichtern, da der Speicherkram in C++ ja doch eher ein Krampf ist.

    In dem Artikel wird folgender erwähnt, der aber nicht das Optimum ist, weil "conservative":
    http://www.hpl.hp.com/personal/Hans_Boehm/gc/

    Vielleicht sollte ich es ja doch in Java machen. :oops:
    Nur will das halt kaum jemand drauf machen, man ist auf Sun angewiesen,
    es gibt Kompatibilitätsprobleme zwischen verschiedenen JREs und und und.
     

Diese Seite empfehlen