sfplay~ clear bug

Jan 20 2011 | 7:26 pm

I've only recently tried to use clear or clear 'number', to find that it doesn't work. This has been noticed before:

so seems to have been around a while. The documentation describes how it should work, but it doesn't.

I have good reasons for wanting to use sfplay~ as opposed to something else, and this behaviour is proving to be a major problem.

Presumably it has flagged up as a bug ? Is it hard to fix ???

Ciao,

Dave

Dave Holton
Jan 20 2011 | 10:23 pm
Yes, verified. Thanks for the report.
Emmanuel Jourdan
Jan 21 2011 | 8:50 pm
The problem has been fixed for the next incremental version. The error message is just misleading, it should say "clear requires audio off" instead, which is what you have to do in order to send clear.
davehuntaudio@btinter
Jan 22 2011 | 12:08 pm
Perhaps strangely I never got an error message (Max 5.1.7, Mac OS 10.4.11 (I know it's old but but solid on a G5 workhorse)). 'clear' just didn't work.
So, you're implying that turning audio off for the whole patch (which in my case contains several sfplay~ instances), then back on afterwards would work.
Looking forward to the fix.
Dave
Emmanuel Jourdan
Jan 22 2011 | 1:18 pm
Yes, the DSP chain must be off in order for the clear message to succeed.
carloskleiber
Jan 23 2011 | 12:08 am
Hello, I am glad to find this thread as I was trying out similar stuff as documented here: http://forum.ableton.com/viewtopic.php?f=35&t=156691&p=1247766#p1247766
Emmanuel, does this mean sfplay~ is just not appropriate for real time use where one tries to load and manage samples on the fly? Or is there a workaround? carloskleiber
edit.. I have read the other thread about this, https://cycling74.com/forums/sfplay-from-hell#post-141192 ...I guess something might work for me between sflist~ (although that guy claims sflist~ presents the same audio on/off problem) and buffer~... cheers, ckl