Three strange behaviours of the Buffer created using ".cueSoundFile"

Dear users and developers,

I have found three strange behaviours of the buffer instance created using the class method “.cueSoundFile”.

[1] “.plot” terminates preloading a sound file for streaming using the class DiskIn:

b = Buffer.cueSoundFile(s, Platform.resourceDir +/+ "sounds/a11wlk01-44_1.aiff", 0, 1);

b.plot;

{ DiskIn.ar(1, b.bufnum) }.play

[2] The sound file path is not added to the client-side buffer information being created using the class method “.cueSoundFile” while the new sound file path is added to the client-side buffer information updated using the instance method “.cueSoundFile”::

c = Buffer.cueSoundFile(s, Platform.resourceDir +/+ "sounds/a11wlk01-44_1.aiff", 0, 1)

c.path // -> nil

{ DiskIn.ar(1, c.bufnum) }.play

c.cueSoundFile(Platform.resourceDir +/+ "sounds/a11wlk01-44_1.aiff", 0, 1)

c.path // -> it returns the actual path of the sound file.

The same occurs when using “c.querry” instead of “c.path”.

[3] The post window echos the server’s sample rate when creating a buffer using the class method “.cueSoundFile” while the instance method “.query”, which is sent to the same Buffer instance, returns the sound file’s sample rate. However, the post window echos the sound file’s sample rate when updating that buffer using the instance method “.cueSoundFile”; and the instance method “.query”, which is sent to the same Buffer instance after updating that buffer, returns the sound file’s sample rate:

d = Buffer.cueSoundFile(s, Platform.resourceDir +/+ "sounds/a11wlk01-44_1.aiff", 0, 1)

// -> Buffer(1, 32768, 1, 48000.0, nil)

// Here, 48000.0 seems odd, but it is the sample rate of the local server.


d.query 

// -> Buffer(1, 32768, 1, 48000.0, nil)
// bufnum: 2
// numFrames: 32768
// numChannels: 1
// sampleRate: 44100.0

// Here, it echoes oddlt 48000.0 again. However, it returns the correct sample rate of the buffer: 


d.cueSoundFile(Platform.resourceDir +/+ "sounds/a11wlk01-44_1.aiff", 0, 1)

// -> Buffer(2, 32768, 1, 44100.0, /Users/prko/Dropbox/prko/__myDocs/Writings/Making Sound using Open Sources/mixed/SuperCollider.app/Contents/Resources/sounds/a11wlk01-44_1.aiff)

// It echoes correctly.


d.query 

// -> Buffer(1, 32768, 1, 44100.0, /Users/prko/Dropbox/prko/__myDocs/Writings/Making Sound using Open Sources/mixed/SuperCollider.app/Contents/Resources/sounds/a11wlk01-44_1.aiff)
// bufnum: 2
// numFrames: 32768
// numChannels: 1
// sampleRate: 44100.0

// It echoes correctly and returns correctly.

I think that the followings are expected for the consistent behaviours:

  1. The instance method “.plot” should not block the preloading of the sound file when DiskIn.ar is streaming in that sound file.

  2. The Post windows should echo the path when a buffer instance is being created using the class method “.cueSoundFile”, and the instance method “.path” sent to that buffer should return the sound file path. Please consider that the Post window does echo the path when a buffer instance is being updated using the instance method “.cueSoundFile”, and that the instance method “.path” sent to that updated buffer returns the sound file path.

  3. The Post window should also echo the sound file’s sample rate instead of the server’s sample rate when a buffer instance is created using the class method “.cueSoundFile”. Please consider that the Post window does when a buffer instance is updated using the instance method “.cueSoundFile”.

Please let me know if I misunderstand the correct behaviours of the buffer created by “.cueSoundFile”.

Thank you so much for reading this long post, and sorry for the wordy sentences.

Best regards,

Some brief responses:

  1. For speed, plot retrieves buffer data using a temporary disk file. I believe it’s writing this disk file that closes the one you’re streaming. If it’s changed to use getToFloatArray instead, then plotting large buffers would be painfully slow, so I think this won’t be fixed.

  2. That seems fixable.

  3. This one is impossible to fix because the -> Buffer output is synchronous, but the updated values from the server are available only asynchronously (i.e., too late to post). You’ll find the same behavior with Buffer.read as well.

hjh

Thank you for your quick response! I want to report what I have found further.

Regarding the 2nd issue:

I tested it today with SC 3.9.3. When creating a new Buffer instance using the class method “. cueSoundFile”, sclang on SC 3.9.3 adds the path of the sound file. When evaluating the following code under SC3.9.3,

b = Buffer.cueSoundFile(s, Platform.resourceDir +/+ "sounds/a11wlk01-44_1.aiff", 0, 1)

the Post window returns the following strings on the Post window:
-> Buffer(0, 32768, 1, 48000, C:\Program Files\SuperCollider-3.9.3\sounds/a11wlk01-44_1.aiff)
The path is then correctly retrieved the sound file path reffered to on that buffer using “.path” and “.query”:

b.path

-> C:\Program Files\SuperCollider-3.9.3\sounds/a11wlk01-44_1.aiff
b.query

-> Buffer(0, 32768, 1, 44100, C:\Program Files\SuperCollider-3.9.3\sounds/a11wlk01-44_1.aiff)
bufnum   : 0
numFrames  : 32768
numChannels : 1
sampleRate : 44100

If I remember not wrongly, SC 3.8 also has the same behaviour as SC 3.9.3.
It seems to be changed with upgrading into SC 3.10. I hope it can be easily fixed.

Regarding the 3rd issue:

I now understand why this phenomenon occurs. First, however, I want to point out a distinguished difference between the returned strings when evaluating Buffer.cueSoundFile and Buffer.read.

When evaluating the following code while the local server is running at the sample rate 4,800Hz under SC 3.12.2,

b = Buffer.cueSoundFile(s, Platform.resourceDir +/+ "sounds/a11wlk01-44_1.aiff", 0, 1)

the Post window returns the following strings:
-> Buffer(0, 32768, 1, 48000.0, nil)

However, when evaluating the following code while the local server is still running at the sample rate 4,800Hz,

c = Buffer.read(s, Platform.resourceDir +/+ "sounds/a11wlk01-44_1.aiff");

the Post window returns the following strings:
-> Buffer(1, nil, nil, nil, /Users/prko/Dropbox/prko/__myDocs/Writings/Making Sound using Open Sources/mixed/SuperCollider.app/Contents/Resources/sounds/a11wlk01-44_1.aiff)

I think this ‘nil’ is much better than a wrong sample rate…

Furthermore, when evaluating the following code for the first time after creating the buffer,

b.query

the following strings, including still the wrong sample rate, are returned on the Post window.
-> Buffer(0, 32768, 1, 48000.0, nil) bufnum: 0 numFrames: 32768 numChannels: 1 sampleRate: 44100.0
The first line followed after the arrow (->) still shows the wrong sample rate:
-> Buffer(0, 32768, 1, 48000.0, nil)
However, the queried sampleRate is correctly shown:
sampleRate: 44100.0
When evaluating secondly the same code,

b.query

all information is correctly displayed in the Post window for the first time:
-> Buffer(0, 32768, 1, 44100.0, nil) bufnum: 0 numFrames: 32768 numChannels: 1 sampleRate: 44100.0

What does happen then with the buffer instances created using “.read”?

When evaluating the same thing on buffer instance created using “.read”

c.query

all information is correctly displayed in the Post window even though it is evaluated for the first time after creating that instance:
-> Buffer(1, 107520, 1, 44100.0, /Users/prko/Dropbox/prko/__myDocs/Writings/Making Sound using Open Sources/mixed/SuperCollider.app/Contents/Resources/sounds/a11wlk01-44_1.aiff) bufnum: 1 numFrames: 107520 numChannels: 1 sampleRate: 44100.0

Thus,

for me, the behaviour of the buffer instance created using “.read” is comprehensible, while the sampleRate-related behaviour of the buffer instances made using “.cueSoundFile” is incomprehensible.

What do you think about it?

I want to apologise if my writing on this post sounds somewhat rude and wordy. My writing skill is still not good, and I am not good at briefly reporting the problem. So please forgive me if not so polite, and I wish you could understand that this post is being written by a non-native English speaker.

Best regards,