Hi, thanks IOhannes for the previous answer but consider this:
Audiobuffer settings, in this model, is an effective way to deal with
Readsf~ bangs when finishes playing a soundfile, this bang triggers the
same readsf~ to open and play a randomly chosen file (open $1.wav, 1).
Since readsf~ has to go to that file wherever it is and start reading, the
audiobuffer setting allows gap-less playback between files.
If I give 500ms readsf~ will have half a second to go anywhere in the
hard-drive and start streaming.
5400rpm hard-drives need more time to achieve this than a Pendrive. My
netbook plays my abstractions (with more than 3 readsf~ simultaneously)
with 100ms with no problem from a Pendrive but need 500ms to do it from the
Here the point is that 500ms using ASIO is fine but 500ms in MMIO has gaps.
And as mentioned previously with the toggle and the osc~ it feels that MMIO
is computing faster than 500ms.
I think that in this situation the audiobuffer is a kind of read ahead for
readsf~ which is very useful.
I switched back to 0.42.5-extended and using MMIO 500ms was fine both giving gap-less playback and the toggle in the osc~ felt more like 500ms.
It will be very cool if 0.44-extended allow 500ms or more in MMIO.
If I put 500 in the Delay(ms) using MMIO in the audio settings changes are heard faster than 500ms in ASIO. tested with a toggle to a (*~) in between osc~ and dac~ in 0.43.4-extended.
This didn`t happened in previous versions.