Re: [PD] Fwd: finding the cause of clicks when using sssad WAS: saving state of a patch
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. --- http://mccormick.cx ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: finding the cause of clicks when using sssad WAS: saving state of a patch
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 | http://modlys.dk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Fwd: finding the cause of clicks when using sssad WAS: saving state of a patch
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
Re: [PD] Fwd: finding the cause of clicks when using sssad WAS: saving state of a patch
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: finding the cause of clicks when using sssad WAS: saving state of a patch
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: finding the cause of clicks when using sssad WAS: saving state of a patch
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: finding the cause of clicks when using sssad WAS: saving state of a patch
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? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
