In what way does the threaded soundfiler affect execution order? Is it only, that one cannot expect to get the file lengths from soundfiler's outlet in a defined order?
this is the critical setup:
|read /path/to/soundfile arrayname( | |t b a| | | | |soundfiler| | |
with a syncronous soundfiler, the soundfiler will output the number of samples before the |t b a| can output the bang.
with the threaded soundfiler, the process will be started, the |t b a| will output the bang and the soundfiler will output the number of samples after the process finished...
this is an inconsistent behaviour, but since there is still the possibility of access the array syncronously using messages, i don't consider this as a big problem. having two different ways to access arrays with both messages and a threaded soundfiler should give us the best possibilities to use the way, we need...
cheers ... tim