[PD] finding the cause of clicks when using sssad WAS: saving state of a patch

[Hans-Christoph Steiner]

Part of the problem could also be that it is using canvas_open()  
which means it searches the whole Path when using a relative name.   
Try using absolute path names for the file to see if that speeds  
things up (canvas_open() tries absolute file names first).

It would be possible to use a thread in [qlist] and [textfile]  
without changing their behavior, but it would mean some trickery  
would have to be used.  Something like this:

- read file into memory using a low-priority thread
- use while(reading); flag to block other messages until thread is  
done reading

Then as long as you don't send another message to [qlist] while it is  
reading, it shouldn't cause an interruption.  But it would still have  
deterministic behavior, since it would always wait until the reading  
was complete before processing more messages.  Ideally, it would send  
a message when it is done reading, so that you can use that to move  
to the next step of the program.

Perhaps there is cause to make [fasttextfile] which is similar to  
[textfile] but doesn't search the whole path like [qlist]/[textfile]  
and uses thread/blocking/complete message I outlined above.

.hc

On Jul 23, 2008, at 10:54 AM, Phil Stone wrote:

> Hi Hans,
>
> I don't think this is anything to do with sssad, really.  It is due  
> to Pd's lack of a threaded file loader/saver.  The way I understand  
> it (and this is borne out by my experience), if a file operation  
> cannot complete within one dsp cycle, the next dsp cycle is delayed  
> until after the file operation completes, thus causing dropouts.
>
> Ram disks help (with files that are not too big) because they speed  
> up the file operation to the point where it can happen safely  
> within one dsp period.
>
> This has been discussed many times on the list without any hope of  
> change, but it would be so great for Pd's use in live performance  
> if some tasks could be relegated to a background thread.  Or, to  
> put it another way, the dsp engine should have highest priority at  
> all times.
>
>
> Phil Stone
> pkstonemusic.com
>
>
> 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
>>
>>
>>



------------------------------------------------------------------------ 
----

                   ¡El pueblo unido jamás será vencido!