Forums > MaxMSP

sfplay~ clear bug

January 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:

http://cycling74.com/forums/topic.php?id=28355#post-141192

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


January 20, 2011 | 10:23 pm

Yes, verified. Thanks for the report.


January 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.


January 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


January 22, 2011 | 1:18 pm

Yes, the DSP chain must be off in order for the clear message to succeed.


January 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,
http://cycling74.com/forums/topic.php?id=28355#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


Viewing 6 posts - 1 through 6 (of 6 total)