onar3d

As the title suggests, I'm pretty certain that I've found a bug

In short, if sfplay is consecutively given two files to play that have the same filename but are located in different paths, the second open command is ignored.

As the title suggests, I'm pretty certain that I've found a bug 

im-pretty-certain-i-ve-found-a-bug-in-sfplay

this isn't a bug. look at the warning in your max window.

ComfortableInClouds wrote on Sat, 23 May 2009 18:29

i can see why and where it can be a problem.

the name of the buffer will be made of the 

filename, and as a programmer you have to 

"open, open filename" or "open xyz, open filename".

ComfortableInClouds wrote on Sat, 23 May 2009 18:29this isn't a bug. look at the warning in your max window.

the name of the buffer will be made of the 
filename, and as a programmer you have to 
take that into account (yourself).

a workaround could be to always use
"open, open filename" or "open xyz, open filename".

And apologies for getting back to you with such a delay, I had to be away from computers for a few days.

Roman Thilenius: Running on Max 5.0.7 on windows vista, I get no error messages. Unless the ones you refer to are those telling that the audio files cannot be found, as I only posted the patch in the forum and didn't include the actual .wav files.

ComfortableInClouds: Thank you for your suggestion, indeed having a "dummy" file in between open commands worked, although including a dummy.wav in my distribution is not the most elegant solution

The fact that sfplay actually names the buffer from the filename escaped me as it was not mentioned in the online documentation of sfplay~...

Although I understand that the behaviour I experienced is explained by this, as a programmer I can intuitively see that automatically using the filename as an ID may not be as good a solution as using the full filepath instead, or if that is too long, a hash generated from it.

ComfortableInClouds: Thank you for your suggestion, indeed having a "dummy" file in between open commands worked, although including a dummy.wav in my distribution is not the most elegant solution 

The fact that sfplay actually names the buffer from the filename escaped me as it was not mentioned in the online documentation of sfplay~... 

I'm pretty certain I.ve found a bug in sfplay