On Wed, Jul 23, 2008 at 04:21:54PM +0100, Si Mills wrote:
I hope im not misunderstanding, but doesn't the s-abstraction way of
using 'datastore' to change presets eliminate dropouts - Why is there
a need for a ram disk? I mean is there a lag between hitting the giant
message box and
Frank Barknecht wrote:
I would recommend to preload all textfiles that should be streamed to
[sssad] into memory.
Under linux I think cat *.sssad_states.txt /dev/null will do.
--
peace, love harmony
Atte
http://atte.dk | http://myspace.com/attejensen
http://anagrammer.dk |
Hi Si,
The problem Hans and I were discussing relates to storing/loading sssad
presets to/from disk. Again, it's not sssad's problem; it's a general
issue with Pd. When the dsp service is delayed by long file accesses,
dropouts happen.
That said, it's important to design sssad-using
Hallo,
Phil Stone hat gesagt: // Phil Stone wrote:
The problem Hans and I were discussing relates to storing/loading sssad
presets to/from disk. Again, it's not sssad's problem; it's a general
issue with Pd. When the dsp service is delayed by long file accesses,
dropouts happen.
Yep.
Hi Frank,
Frank Barknecht wrote:
Hallo,
Phil Stone hat gesagt: // Phil Stone wrote:
The problem Hans and I were discussing relates to storing/loading sssad
presets to/from disk. Again, it's not sssad's problem; it's a general
issue with Pd. When the dsp service is delayed by long
what i have done is create a large textfile for presets that can be loaded
when the patch is opened, which in turn sends its data to up to 1000
textfile objects. pd seems to have no problem with so many textfile objects
storing data
it might even be cheaper to do it this way than storing numbers
