hi, just was trying out the latest changes to the soundfiler - seems to work well on win32 now - queueing up hundreds of files to be loaded into preexisting arrays is no problem. had one crash but cant reproduce so let's assume its unrelated..this is a 1.4 amd & slow hd... .
i think there should be one caveat in regards to multithreaded objects in general, and that is you can no longer rely on the patch depth--right to left execution order..had to make some slight changes in file loading externals and move around some counters, etc, so that things would work again...but of course the benefit outweighs the minor hassle...just think there should be fair warning of that, assuming the threaded soundfiler made the default...
thanks for the excellent addition... cr
i think there should be one caveat in regards to multithreaded objects in general, and that is you can no longer rely on the patch depth--right to left execution order..had to make some slight changes in file loading externals and move around some counters, etc, so that things would work again...but of course the benefit outweighs the minor hassle...just think there should be fair warning of that, assuming the threaded soundfiler made the default...
well, i never thought about the excecution order when writing the new soundfiler ... but you are right, i should add a warning.
anyway, since the soundfiler _has_ to work asyncronously to avoid dropouts, there is no other way to solve this that makes sense ...
i'm curious if anyone has tried to compile it on osx ... i'd be glad to get some feedback...
cheers ... tim
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
i think there should be one caveat in regards to multithreaded objects in general, and that is you can no longer rely on the patch depth--right to left execution order..had to make some slight changes in file loading externals and move around some counters, etc, so that things would work again...but of course the benefit outweighs the minor hassle...just think there should be fair warning of that, assuming the threaded soundfiler made the default...
well, i never thought about the excecution order when writing the new soundfiler ... but you are right, i should add a warning.
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?
Ciao
Frank Barknecht _ ______footils.org__
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
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
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.
Okay, just as I supposed. I also don't see this as being that big a problem. It could be worked around with another ordering:
[read /path/to/soundfile arrayname( | [soundfiler] | [t b f a whatever]
Doing it this way is the cleaner idiom anyways IMO.
Ciao
Frank Barknecht _ ______footils.org__
-
Frank Barknecht -
ix -
Tim Blechmann