Beiträge von Sjoerd

    Ich habe einen Vorschlag für GrandOrgue (falls das nicht sowieso schon so gemacht wird): Beim Laden in 16 Bit die Daten jedes Frames einer WAV-Datei soweit nach links shiften (sagen wir k-mal), daß beim Frame mit maximalem Wert das oberste Bit gesetzt ist, und zum Ausgleich beim Addieren des Samples zum Gesamtklang mit dem passenden Faktor 2^(-k) multiplizieren. Das Ergebnis wäre dann über den gesamten Dynamikbereich der Register so gut, daß man auf den 24-Bit-Modus eigentlich ganz verzichten und damit den speicherknappen Anwender von der Last der Entscheidung, welche Register er mit 16 und welche mit 24 Bit laden soll, befreien könnte. So werden zwar immer noch unnötig große Datenmengen vom Hersteller zum Anwender transportiert und auf der Platte gelagert, aber Leuten mit wenig RAM ist geholfen.

    Man würde hoffen das die Sampleset-hersteller das schon so machen. Es gibt in GO Parameter für individuelle Verstärkungsfaktoren für jede Pfeife.

    Ich glaube aber dass das Grösste Problem nicht mit Leisen oder Lauten Registern zu tun hat, sonder mit Hall. Hat man soeben eine Vielzahl von laute Noten gespielt werden nach zB 10 Sekunden viele Leise "Release" Samples zusammenaddiert.

    Vpo-organist schrieb "Direct ist trocken und verbraucht weniger Speicher". Ja, so sollte es sein, aber in der Praxis is dies stark abhängig vom Sampleset-hersteller. Bei Sonus Paradisi Billerbeck ist es jedenfalls NICHT so. Direct, Diffuse, Rear braucht in GrandOrgue genau so viel speicher.

    Ich werde mal selbst experimentieren, mit Kopfhörer...

    Wenn das Problem nur im Release ist, könnte man doch "einfach" eine Lösung machen in dem man Signalhüllkurve ("Envelope" - heisst das Signalhüllkurve auf Deutsch?) und Signal separat Speichert. Also, z.B. speichern das man für Sample 0-100 eine Verstärkung von 1 benutzt, von 101-500 16, von 501-2000 64, von 2001-Ende 256. Ein Par extra Parameter (hier zB [0 100 500 2000] und [1 16 64 256]) und schon kann man von 24 auf 16 Bit gehen.

    Also, nach links schieben wie emsig schon schrieb, aber nicht mit konstanten k.

    Wie immer, wenn man weiß wie ein Signal aussieht, kan man eine bessere Kompression machen als wenn man nichts weiß.

    Ich nehme an, in algorithmen wie mp3 gibt es auch solche Lösungen - vielleicht könnte man doch etwas benutzen ohne etwas neues zu erfinden. Und in GrandOrgue (glaube ich) ist das Problem nicht Prozessorkraft sondern Speicherplatz. Mein 12-Jahr-alten Rechner mit 64 GB ist schnell genug...

    emsig - es würde mich sehr freuen wenn du anfängst GrandOrgue zu verbessern! Es geschieht viel zu wenig...

    Selbst bin ich kein Softwareentwickler von Beruf, mit C++ habe ich nie gearbeitet - aber Signalbearbeitung (z.B. mit Matlab oder Signalprozessoren) gehört schon zu meiner Arbeit. Jetzt wo Billerback ODF (ein grosses PHP Projekt) so ungefär fertig ist werde ich mit GrandOrgue anfangen - zuerst im Bereich der Benutzeroberfläche, aber später vielleicht auch mehr.

    Wenn man etwas verbessern kann im Speicherbedarf wäre es wirklich gut... wenn 64 GB nicht mehr reichen, und es auch Minuten dauert bis ein Orgel geladen ist, wäre es schon nützlich.

    Ich finde die Spektralanalysen hier ganz überzeugend...

    http://www.sonusparadisi.cz/en/blog/do-not-load-in-16-bit/

    Aber, was meine Augen sagen spielt eigentlich keine Rolle...

    Und was ich selbst machen muss, weiß ich noch immer nicht. Billerbeck in 24 Bit geht nicht in 64 GB. Sonus Paradisi sagt 20 Bit, aber leider hilft das fast nichts. Weiß nicht warum... Problem mit GrandOrgue?

    Also, ein Teil muss in 16 Bit geladen werden. Zuerst die Tremulanten - benutze ich bis jetzt nie. Aber dann? Alle "Direct" oder alle "Diffuse" Samples?

    Schön, was ihr da für GO bastelt. Ich habe mir heute auch ein MidiPanel für die Billerbeck konfiguriert 8)

    Ich würde die Farben anders wählen - besonders grün und braun hat sehr wenig Kontrast. Ich finde, Jiři hat eine gute Wahl gemacht.

    Man kann sich fragen, ob jede Orgel eine ähnliche Interface braucht, oder ob Verschiedenheit doch noch etwas bringt.

    Wäre schön wenn man deine Panele mit GO integrierte... die im GO eingebaute Knappen sind oft schlecht lesbar.

    Toll, hast du die Taster selbst erschaffen? Ist ein tolles Format

    Nein, leider, ich bin hier nicht kreativ...

    Ist alles von Sonus Paradisi:

    http://www.sonusparadisi.cz/media/Foto/Bil…k_Screen_9_.jpg

    oder eigentlich Fleiter:

    http://www.sonusparadisi.cz/media/Foto/Bil…/billerb_5_.JPG

    Mal sehen ob ich alle Tasten auf einem Schirm bekommen kann und ob es dann auch noch gut aussieht. Erst mal ein Stück Holz fotografieren als neuer Hintergrund... aber wenn ich das mache, habe ich noch das Problem das jede Taste einen Schatten hat. Dann sollte ich also 200 (!) Bilder neu machen. Das wird mir doch zu viel. Also vielleicht eine neue Hintergrund zusammenbasteln von der heutige.

    Maybe there is an issue with your audio settings. In Midi & Audio Settings, under Audio Output, check the configured latency for your audio output device. Mine is at 50 ms, lower will cause problems.

    Also check in Midi & Audio Settings, under Options, the chosen Samples per buffer. Also here a too low value will cause audio issues, but more likely interruptions than what you are experiencing. 1024 is a safe value, but lower should work as well.

    Let me know how it goes!

    Diese 1 MB ist in der Tat sehr eng.

    Dies könnte vielleicht hilfreich sein:

    Sie können die Größe der Grafikdateien erheblich reduzieren, indem Sie nicht die maximale Farbtiefe (Echtfarben) auswählen, sondern für die Konsole auf 236 Farben zurückgreifen, was für die Bildschirmanzeige noch immer hervorragend ist und für den einfachen Jamb auf z. B. auf 16 Farben.

    Ich würde sicherlich kein (JPEG )Komprimierung anwenden, aber lieber PNG wählen. Ich habe es schon versucht: für die Konsole erhalten Sie auf diese Weise 1,89 MB unter Beibehaltung der Abmessungen und Auflösung .

    Gruß Bas

    Danke, habe es gerade versucht (mit GIMP), 256 indexierte Farben, aber bei mir sieht es schrecklich aus. Wie machst du es? Und 1.89 MB (oder 1.7 bei mir) hilft nichts. Mit JPG habe ich es jedenfalls unter 1 MB gekriegt OHNE dass ich bei 100% Vergrößerung eine Unterschied sehen kann. Für den einfachen Jamb benutze ich jetzt schon 256 Grauwerte.

    Links original, rechts bearbeitet.

    pasted-from-clipboard.png

    Wie kann ich meine Version(en) hochladen????? Es sind weit mehr als 1 MB...

    Ich habe folgende Dateien:

    BillerbeckDemo.organ (6.7 MB, mit zip werden das 475 kB)

    images (12.6 MB, zip oder nicht...):

    - keyboard_console.png (10.5 MB)

    - simple.png (2 MB)

    - transparent.png

    - tremulant_switch_artificial.png

    - tremulant_switch_original.png

    BillerbeckDemoNoSemiDry.Organ (5 MB)

    BillerbeckDemoSemiDry.Organ (1,9 MB)

    und so noch einige Varianten.

    keyboard_console.png ist das Große Problem... im Original ist eine Maske im Datei dabei, das HW ignoriert aber GO nicht. Ich brauche also unbedingt eine neue Version. Komprimieren würde gehen, aber es sollte doch in GO wenigstens genau so gut aussehen wie in HW.

    simple.png ist eine neue (meist schwarze) Hintergrund. 2 MB ist nicht viel für 2542x1838 Pixel (Sonus Paradisi Wahl, nicht meine Idee das so Groß zu machen...). Könnte ich vielleicht komprimieren ohne viel zu verlieren.

    Vorschläge? Ich hätte es gerne hier auf diesem Forum...

    Vielleicht interessant ein zu sehen das das HW ODF des Demo 19,7 MB sind, komprimiert 2 MB. Dass man hier nur 1 MB hochladen darf bedeutet dass man eigentlich hier nicht viel machen kann. 5 MB oder lieber 10 MB wäre schon besser.

    Edit: habe gerade jpg versucht. Beide Hintergrunde kann ich dann je genau unter 1 MB machen, ohne dass es zu sehr sichtbar ist. Würde aber dennoch gerne alles auf einmal hochladen, und nicht Datei 1: Hintergrund 1, Datei 2: Hintergrund 2 und andere Bilder, Datei 3: ODFvariant1.zip, Datei 4: ODFvariant2.zip usw.

    Meiner Meinung nach sind geringfügige Unterschiede in den Tastendruckzeiten nicht so wichtig. Diese dienen dazu, auszuwählen, welche Hall-Samples mit einer Auswahl von zwei oder drei Samples (mit einer diskreten Länge) ausgewählt werden sollen. Wo genau ziehen Sie die Grenze? In Wirklichkeit haben Sie nicht zwei oder drei Halllängen, aber der Hall ist für jede Tastendruckzeit unterschiedlich. Die Akustiksimulation macht dies besser als die (meiner Meinung nach) improvisierte (auf Holländisch: “Houtje-touwtje”) Lösung von HW und GO.

    Ich sehe nicht, ob Sie noch an einer vollständigen SemiDry-Version arbeiten, aber wenn dies Ihr Plan ist, können Sie falls Sie es wollen natürlich meine Demoversion oder Teile davon verwenden.

    Ich selbst überlege, ob ich die Enclosure-simulation verbessern kann. Hauptwerk verwendet für jede Pfeiffe einen Frequenzfilter. Um ein Enclosure besser zu simulieren, würde ein Frequenzfilter pro Windschublade ausreichen. Leider hat GO aber überhaupt keinen Frequenzfilter. Gute simulation wird daher nicht allein über den Odf möglich sein. Ich denke an eine Lösung, bei der ich die relevanten Samples extern mit einem Filter bearbeite. Diese gefilterten Samples können dann (analog zum Mischen von Front- und Rearsamples) mit dem Original gemischt werden.

    Das erfordert aber auch wieder zusätzlichen RAM.

    Ja, ich weiß auch nicht ob 230 ms oder 150 ms Grenzwert eine hörbare Unterschied macht. Wahrscheinlich nicht... und besonders bei Billerbeck wo bestimmte Releases lauter sind als der Ton und das laut Jiři normal ist.

    Aber einige dB Verstärkung plus oder minus nehme ich an ist hörbar... und auch im Semi-Dry gibt est Noten in mit sehr unterschiedliche Verstärkungen. (z.B Rohrföte 8 geht von -3.7 bis +2.8 dB im Semi-Dry).

    Danke für den Angebot deine Version zu benutzen - aber weil ich mit PHP-Dateien anstatt Roh-ODF-Tekstdateien arbeite nützt es mir nicht.

    Ich hab (weil ich wartete auf meinem Download der neuen Version) ziemlich schnell das Semi-Dry Demo in meiner Version hinzugefügt - habe also jetzt das 8-Kanal-Demo fertig. Andere Varianten (Nur Semi, nur Direkt-Diffus, irgendeine Kombination ohne Tremulanten) mache ich automatisch daraus - mal sehen was Leute interessant finden! 8-Kanals Demo braucht mehr als 64 GB im 24 bit :(

    Frequenzfilter für Schweller - ich finde wir müssen das unbedingt machen. Geht aber nur gut wenn man GO erweitert - und solange die bisherige Programmierer nicht einmal sich mühe geben einfache Fehler zu korrigieren geschieht da nichts. Ich habe schon angefangen zu untersuchen wie ich selbst daran arbeiten kann. Schade das es notwendig ist.