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 updating all the abstractions?
I was inspired the other day by a Max discussion on the pattr object,
which is used for state saving. This in turn can be used from
arranging pieces to to creating very nice random instruments that
flick between presets very quickly...
Is this a problem for sssad at the moment?
On 23 Jul 2008, at 15:24, Hans-Christoph Steiner wrote:
On Jul 22, 2008, at 2:31 AM, Enrique Erne wrote:
Phil Stone wrote:
Hi Atte,
Now that you're on your way with sssad, there's a nice trick you should know. If you find that loading a preset causes dropouts, consider using a ram disk to hold your presets during performance. This solved all my dropout problems, and it's easy to do (I can post a script for OS X if anyone wants it).
The ramdisk thing is definitely handy, I just hope that sssad can be tweaked to work without causing dropouts. Any ideas what the cause
is?.hc
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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 abstractions so that preset-changing doesn't cause discontinuities as well. For instance, use [line~] lags for changing parameters to smooth out the jump. It's certainly possible to "flick btween presets very quickly" with sssad-using abstractions; I do it all the time with [polywavesynth].
Phil Stone pkstonemusic.com
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 updating all the abstractions?I was inspired the other day by a Max discussion on the pattr object,
which is used for state saving. This in turn can be used from
arranging pieces to to creating very nice random instruments that
flick between presets very quickly...Is this a problem for sssad at the moment?
On 23 Jul 2008, at 15:24, Hans-Christoph Steiner wrote:
On Jul 22, 2008, at 2:31 AM, Enrique Erne wrote:
Phil Stone wrote:
Hi Atte,
Now that you're on your way with sssad, there's a nice trick you should know. If you find that loading a preset causes dropouts, consider using a ram disk to hold your presets during performance. This solved all my dropout problems, and it's easy to do (I can post a script for OS X if anyone wants it).
The ramdisk thing is definitely handy, I just hope that sssad can be tweaked to work without causing dropouts. Any ideas what the cause
is?.hc
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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.
Generally everything that touches the disk, is dangerous. [sssad] doesn't touch the disk at all, so it's not guilty here. ;)
I would recommend to preload all textfiles that should be streamed to [sssad] into memory. You don't need a ramdisk for that, just enough textfile objects. Those come cheap.
Ciao
Frank
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 file accesses, dropouts happen.
Yep.
Generally everything that touches the disk, is dangerous. [sssad] doesn't touch the disk at all, so it's not guilty here. ;)
I would recommend to preload all textfiles that should be streamed to [sssad] into memory. You don't need a ramdisk for that, just enough textfile objects. Those come cheap.
Six of one, half dozen of the other. :-) That's essentially what I'm doing with a ram disk: preloading textfile objects into memory. The nice thing about it, though, is that your Pd object doesn't have to care
- it all looks like a filesytem, whether its from ram disk or hard disk,
so you can use both/either according to your needs.
Best,
Phil
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 in an array, if textfile is just storing integers, rather than floating point numbers?
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.
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 updating all the abstractions?
Just to be clear, s-abstractions should not experience any dropouts at all when you use the [sssad/datastore] abstraction.
Chris.
-
Atte André Jensen -
Chris McCormick -
Frank Barknecht -
hard off -
Phil Stone -
Si Mills