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!
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
