Was limitiert den Speicher?

hairmetal

hairmetal

(vermisst)
Kurze Frage eines technisch sehr unerfahrenen...

  • Was genau limitiert den nutzbaren Sample-Speicher z.B. in einem Nord-Wave oder einem Sledge?
  • Wäre es technisch möglich, grössere Speicherbausteine zu benutzen, als die ab Werk verbauten?
  • Könnte das herstellerseitig implementierte OS überhaupt auf einen grösseren Speicher zugreifen?


Hintergrund meiner Fragerei: Da eine "Geräte-Modding"-Gemeinde in diesem Bereich kaum vorhanden ist (oder sehr stumm bleibt), fragte ich mich,
warum dies wohl so ist. Bzw. wo die Gründe dafür eigentlich zu suchen sind.


Über regen Austausch und (hoffentlich fundierte) Antworten freue ich mich.
 
Bei Sledge wie Blofeld ist das so: Da ist so viel Flash-Speicher im verwendeten DSP-Chip einfach mit dabei gewesen, und man hat es eben für Samples genutzt. Das hat man dort also nicht extra zusätzlich eingebaut, sondern extra den Code geschrieben und externe Software dann auch, um Samples übertragen zu können.
 
Das klingt nach einer starren, nicht modifizierbaren Lösung.

Es würde zumindest für die Blofeld/Sledge-Familie vieles erklären;
man müsste quasi den kompletten Custom-DSP-Chip austauschen. Keine Chance.
 
Michael Burman schrieb:
Bei Sledge wie Blofeld ist das so: Da ist so viel Flash-Speicher im verwendeten DSP-Chip einfach mit dabei gewesen, und man hat es eben für Samples genutzt. Das hat man dort also nicht extra zusätzlich eingebaut, sondern extra den Code geschrieben und externe Software dann auch, um Samples übertragen zu können.
Zum Vergrößern anklicken....
Nicht ganz. Im Blofeld gibt es eine CPU (FREESCALE MC9S12UF32PBE), einen DSP (FREESCALE DSP56371), (SAMSUNG K9F1208U0B) und einen DAC (AKM 438). Der Speicher wurde ursprünglich für OS und Patches vorgesehen. Kleiner als 64M x 8 Bit gab es nicht. Stefan Stenzel hat das so lange keine Ruhe gelassen, bis er eine Methode gefunden hat, aus dem Flash Samples zu streamen.

Aber mit Mods ist da sicher nichts zu machen. Es ist sicher einfacher, einen ganzen Sampler zu entwickeln, als das Waldorf System zu hacken.
 
Interessant ist das aber auch bei aktuellen Geräten und dem Preis für Speicher. Wieso sind die Geräte immer noch so limitiert!? Da wird eine Bibliothek von 1gb für Samples in höchsten Tönen gelobt und das ist ja mehr als beim Vorgänger usw, dabei ist das doch total wenig. Wenn man schaut, was ein Handy hat, wie viel auf schnelle SD Karten passt und wie billig die dann immer noch sind, da kann es doch kein Problem sein, den Geräten ordentliche Speichergröße zu verpassen.
 
Exakt diesen Sachverhalt wollte ich mit diesem Thread genauer untersuchen.
 
Eine schöne Übersicht über die Effekte und die Voices im Genos, aber ansonsten bin ich - bis auf die Bestätigung des NAND-Flash - gerade so schlau wie zuvor...

Magst du die entsprechende Stelle kurz zitieren?
 
Zuletzt bearbeitet:
ollo schrieb:
Wieso sind die Geräte immer noch so limitiert!?
Zum Vergrößern anklicken....
Ein Smartphone ist ein Smartphone, ein Sample-Player ist ein Sample-Player und ein PC ist ein PC. Dass ein Smartphone locker mit 128 GB hantieren kann (das ist kein RAM) und ein PC locker 64 GB RAM haben kann, bedeutet ja nicht, dass ein Sample-Player identische Architekturen nutz und all das ebenso locker kann.
 
Ich verstehe nicht, warum manche Geräte mit Compact-Flash Slot (Octatrack, Electrix Repeater) nur Flash Karten bis zu einer bestimmten Größe verwenden können. Denn meines Wissens ist der "Controller" mit der ganzen Ausleselogik bei CF schon in die Karte integriert. Kann das jemand näher beleuchten?
 
swissdoc schrieb:
bedeutet ja nicht, dass ein Sample-Player identische Architekturen nutz und all das ebenso locker kann.
Zum Vergrößern anklicken....
Vielleicht sollte man das vielleicht noch genauer erläutern: Es geht darum, dass man nicht unbedingt dann Zugriff auf den gesamten Speicherbereich hat, wenn man ihn auch wirklich braucht.
Vereinfachendes Beispiel: ein RAM-Adressbus mit 32Bit-Breite (das ist schon mal ganz ordentlich) kann 4GB direkt adressieren. Das bedeutet: wenn ich zwei Speicherbereiche, die weiter auseinander liegen, auslesen will, dann muss ich dazwischen immer noch eine Bereichsumschaltung über einen langsameren Vorgang legen, die zwischen den verschiedenen 4GB Stücken hinundher springt. Das ist im PC oder im Handy kein Problem, 1.) weil es da keine wirkliche Echtzeitanforderung gibt, und 2.) weil es beim PC aufwendige, mehrstufige Caching-Mechnismen gibt, die soweit wie möglich Daten im Voraus abfragen und dann in direkt auslesbaren Cache-Speichern ablegen. Das funktioniert aber nur für einigermaßen erwartbare Ereignisse. ZB Wiedergabe von zuvor aufgenommenem Audio in einer DAW, oder Abspielen einer MIDI-Sequenz über einen Software Sampleplayer. Da weiß der PC vorher, welche Daten demnächst abgefragt werden. Ein Hardware-Sampleplayer weiß aber nicht, was der Musiker demnächst spielen wird. Also hat er nicht wie der PC die Zeit, gemütlich vorher Daten zu holen, die demnächst gebraucht werden. Deswegen muss er sich letztlich mit den (im Beispiel eines 32Bit Adressbus) 4GB begnügen.
 
swissdoc schrieb:
ollo schrieb:
Wieso sind die Geräte immer noch so limitiert!?
Zum Vergrößern anklicken....
Ein Smartphone ist ein Smartphone, ein Sample-Player ist ein Sample-Player und ein PC ist ein PC. Dass ein Smartphone locker mit 128 GB hantieren kann (das ist kein RAM) und ein PC locker 64 GB RAM haben kann, bedeutet ja nicht, dass ein Sample-Player identische Architekturen nutz und all das ebenso locker kann.
Zum Vergrößern anklicken....

Und genau das ist die Frage, wieso nicht? Wenn ein Smartphone 4GB Arbeitsspeicher und 128GB Festspeicher in eine Handfläche bekommt, wieso wird bei einem großen Keyboard die Erweiterung von 256mb auf 1GB abgefeiert, wo Speicherchips wirklich nicht einen Preisunterschied ausmachen dürften.

fanwander schrieb:
Das funktioniert aber nur für einigermaßen erwartbare Ereignisse. ZB Wiedergabe von zuvor aufgenommenem Audio in einer DAW, oder Abspielen einer MIDI-Sequenz über einen Software Sampleplayer. Da weiß der PC vorher, welche Daten demnächst abgefragt werden. Ein Hardware-Sampleplayer weiß aber nicht, was der Musiker demnächst spielen wird. Also hat er nicht wie der PC die Zeit, gemütlich vorher Daten zu holen, die demnächst gebraucht werden. Deswegen muss er sich letztlich mit den (im Beispiel eines 32Bit Adressbus) 4GB begnügen.
Zum Vergrößern anklicken....

Naja, spätestens wenn ich mit einem Midikeyboard am PC live spiele, weiß der auch nicht mehr, was als nächstes kommt, ähnlich wie der Sample-Player.

Und umgekehrt geht es ja auch. Eine Kamera schaufelt auf kleinem Raum übelst viele Daten in Echtzeit auf eine Speicherkarte, und Video ist da nochmal sehr viel anspruchsvoller als Ton. Das muss das Auslesen von Audio dagegen doch ein Klacks sein.
 
Zuletzt bearbeitet:
ein pc hat aber im vergleich zu einem sampler eine riesige latenz - in der zeit kann er sich die daten über drei ecken besorgen ;-)
 
Einen PC kann man trotz großem Speicher schon mit deutlich kleineren Datenmengen an die Wand fahren. Ich hatte das neulich mit einem 16MB Wavetablesatz als Multisample: Trotz optimiertem Zugriff, ausgerichtetem Speicher und ähnlichen Umständlichkeiten hat sich die Auslastung des Systems bei Modulationen der Ausleseposition z.T. schlagartig verdoppelt, weil da eben nichts mehr mit Cache und Prefetching geht und man recht unvorhersehbar in den Daten herumspringt.

Abhilfe bei gleicher Klangqualität verschaffte in dem Fall eine Verkleinerung der Datenmenge um den Faktor 3 - kombiniert mit einer aufwändigen Interpolation, die deutlich erhöhte Anforderungen an die CPU selbst stellt. Da bringen mir auch 4GB Ram nichts, wenn ich nicht schnell genug an die Daten komme - auch wenn diese Dinge bei normalem Streaming erst später auftauchen als in meinem "Extremfall".

Normale Computerhardware hat sicher schöne Kennwerte auf dem Papier. Sie ist aber in einem Synth eher problematisch, weshalb ich sie nicht als Maßstab heranziehen würde.
 
ollo schrieb:
Naja, spätestens wenn ich mit einem Midikeyboard am PC live spiele, weiß der auch nicht mehr, was als nächstes kommt, ähnlich wie der Sample-Player.
Zum Vergrößern anklicken....
Wie Tom F schreibt: Die Latenz ist in dem Fall dann grottig.

Und umgekehrt geht es ja auch. Eine Kamera schaufelt auf kleinem Raum übelst viele Daten in Echtzeit auf eine Speicherkarte, und Video ist da nochmal sehr viel anspruchsvoller als Ton. Das muss das Auslesen von Audio dagegen doch ein Klacks sein.
Zum Vergrößern anklicken....
Bild ist timingmäßig eine NULL-Herausforderung. Bild braucht 24 Ereignisse pro Sekunde und kann sich dabei einen vom Auge nicht wahrnehmbaren Jitter von 25% leisten.
Audio braucht 44100 Ereignisse pro Sekunde, und jeglicher Jitter ist seeeehr schnell in der Signalqualität wahrnehmbar. Audio muss also fast 2000 mal so gut sein.
ERGÄNZ: Und zudem ist es so, das man bei Bild nirgends solche Aktionen macht, wie sie Cyclotron im Beitrag "über mir" mit der Wavetable beschreibt.

Und beim Daten-Schreiben schreiben die Kameras 1.) nicht(!) in Echtzeit auf die Karte. Da werden irgendwann irgendwelche Blöcke geschrieben, und 2.) funzt das nur wirklich, wenn der Speicherbereich nicht fragmentiert ist. Mach mal bei einer Digicam eine SD-Card mit Bilder voll, lösche dann jedes zehnte Bild und nimm dann mal eine Film auf....
 
Zuletzt bearbeitet:
fanwander schrieb:
Bild ist timingmäßig eine NULL-Herausforderung. Bild braucht 24 Ereignisse pro Sekunde und kann sich dabei einen vom Auge nicht wahrnehmbaren Jitter von 25% leisten.
Audio braucht 44100 Ereignisse pro Sekunde, und jeglicher Jitter ist seeeehr schnell in der Signalqualität wahrnehmbar.
Zum Vergrößern anklicken....

Die Überlegung ist halt, wenn ich 50 oder 60 Bilder in Full-HD oder sogar höher und der Ton, der ja noch dazu kommt oder bei einem Audio-Rekorder der zich Spuren gleichzeitig in noch höherer Qualität auf eine SD-Karte schreiben kann und man davon ausgeht, das schreiben meistens langsamer ist als lesen, es doch eigentlich dagegen ein Leichtes sein müsste, dann "nur" Audio auszulesen. Auch wenn das im Extremfall viele kleine Samples sind, die dann aus dem Arbeitsspeicher geholt werden müssen. So als Laie gesehen, darum ging es dem Threadersteller ja auch unter anderem.
 
Du schreibst aber einen konsistenten Datenstrom und der Jitter beim Schreiben ist komplett irrelevant. Ob Du bei 50pic/s in den ersten 500ms nur ein Bild schreibst, und in den zweiten 500ms die anderen 49 Bilder, ist total egal. Und wie schon gesagt: das funktioniert nur bei nicht sehr fragmentierten Medien.
 
Es gibt Streaming-Technologien. Die 4 GB können die ersten Samplewerte von längeren Samples enthalten. Der Rest wird vom langsameren Speicher nachgeliefert. Der Kronos tut das z.B. Evtl. auch der Forte.

Es ist einfach so, dass die meisten Hersteller sich keine Mühe machen bzw. die Kosten scheuen. Technologie ist da. Man muss nur können und wollen das in die Entwicklung einzubeziehen.
 
Michael Burman schrieb:
Es gibt Streaming-Technologie.
Zum Vergrößern anklicken....
Ja, aber die funktioniert nur für straightes Sample-Streaming, nicht für Synthesen. Einfachstes Beispiel: dynamisch gelayerte Samples. Wenn Du Velocity-abhängig mal kurz 5kByte brauchst, die irgendwo hinten beim Gigabyte Nummer 93 liegen, hilft Dir Dein Streaming nix.
 
Wenn Du normale PC Hardware zugrunde legst, ist der Speicherzugriff ab einer bestimmten Größe der entscheidende Flaschenhals - wie von mir beschrieben auch schon unterhalb der 4GB, wenn es mehr sein soll als nur einfaches Abnudeln von Anfang nach Ende. Auch variable Startpunkte, biderektionales / reverses Lesen, Loops usw. ist etwas, wofür Streaming nicht ausgelegt ist. Sonst hätte es in meinem o.g. Fall ja gar keine Probleme geben dürfen, weil das ja ein vergleichsweise kleiner Datensatz ist und alles sofort zur Verfügung stünde. Dem ist aber nicht so.
 
Streaming wird ja gerade für längere Samples eingesetzt wie Klavier, Streicher usw. Da wird nicht wild von Sample zu Sample hin und her gesprungen. Bei so langen Samples gibt es dann sogar gar keine Loops mehr.
Wer wildes Auslesen von Samples in Echtzeit beabsichtigt, wozu braucht er mehr als 4 GB im direkten Zugriff? :agent:
So viel Speicher, sprich weit über 4 GB, zum direkten Spielen ist doch eher für traditionelle Klavier- und Orchester-Sounds interessant.
 
Ein Note - On ist so ein wildes herumspringen, wenn Du Layers, Multisamples oder variable Startpunkte hast. Wie gesagt, auch Deine vorgeladenen Daten sind ja noch nicht in der CPU, sondern erst mal im RAM. Dann kommt u.a. noch die Änderung der Schrittweite (oder gar der Waveform) bei Pitchmodulation hinzu - auch etwas, was Streaming nicht so mag. Und manchem wird das einfache Abspielen von A nach B ohne irgendeine Option dann doch zu dröge sein. Für Akustiksamples vielleicht ok, den Klangkreativen aber sicher schnell zu öde. Gut, dass ist nur eine Vermutung... .
 
Damit drehst Du aber den Thread um und widersprichst quasi der der Ausgangsfrage von Kollege Hairmetal (oder besser Du widersprichst seiner zu vermutetenden Annahme, die seiner Frage wohl zugrunde liegt). Der will ja wohl gerade selbst beliebig (große) Samples reinladen, um sie dann synthetisch zu verwursten, und frägt, warum das nicht geht.
 
Synthetisch verwursten geschieht im operativen Speicher. Man kann auch große lange Samples durch den operativen Speicher jagen und verwursten.

Adressierung ist natürlich generell ein Thema. Wenn die Rechner-Architektur z.B. nicht in der Lage ist mehr als 4 GB zu adressieren, dann geht eben nicht mehr.
 
Zuletzt bearbeitet:
Michael Burman schrieb:
Da wird nicht wild von Sample zu Sample hin und her gesprungen
Zum Vergrößern anklicken....


Das könnte täuschen... Wenn man (mal am Beispiel Klavier) jetzt zusätzlich auch Release-Samples und Pedal-Samples hat, die dann mit den Velocity-Samples "multipliziert" oder "in Echtzeit geswitched" werden müssen, so kann ich mir das Gehüpfe des Speicherzugriffs sehr bildlich vorstellen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.


Neueste Beiträge

News

Zurück
Oben