simply stopped after some short time - it's also the same with the associated help file. I tried to debug it, but gave up after some time.
what do you mean about the help file? you mean readanysf.pd? the help file needs to be debugged?
Nono, what i wanted to say is that the readanysf~ stop bug appears when using the help file.
The
other thing is that readanysf~ is using two threads that are passing the data but i wanted really low latency.
hmm, it should only be using one thread. I think flext starts the second thread as a helper ?
Sorry, you are right - only one thread in your code. I don't know why i thought something else. The flext helper thread is just there in the background to silently start new threads with low initial priority.
- the built-in readsf~ is really trashy, sorry. I can't understand how
a
soundfile player can be part of the main distribution, that spits out
noise
when the file isn't fully preloaded. With many parallel players and
heavy
system load the preload time is impossible to anticipate for an
autonomous
patch.
I think this might have to do with the windows implementation. AFAIK, the windows version still isn't threaded. Can that be?
Actually it's the same code for Windows and linux, which is threaded. I had an installation running linux not too long ago that also had the readsf~ noise problem.
best greetings, Thomas