Function:loadToFloatArray not working on k-rate (patch attached)

[Dan Stowell]

Hi -

Function:loadToFloatArray doesn't complain if the function produces
k-rate output, it gives you numbers, but they may not be the numbers
you expected: K2A interpolation is always imposed.

s.boot
{SinOsc.ar(1)}.loadToFloatArray(1, action: {|array|
array.size.postln}) // I get 44100 as expected
{SinOsc.kr(1)}.loadToFloatArray(1, action: {|array|
array.size.postln}) // I expect 44100/64 but get 44100

There's a comment in the method source code saying "no need to check
for rate as RecordBuf is ar only" but that's not true (no longer true,
at least).

The attached patch updates Function:loadToFloatArray so that it works
transparently with k-rate functions rather than forcing them to
interpolate. I guess this patch is not urgent so it should only make
it into 3.3 if a new RC happens for other reasons. Feedback welcome.

Dan
--
http://www.mcld.co.uk

Index: build/SCClassLibrary/Common/GUI/PlusGUI/Math/SignalPlusGUI.sc
===================================================================
--- build/SCClassLibrary/Common/GUI/PlusGUI/Math/SignalPlusGUI.sc (revision 9081)
+++ build/SCClassLibrary/Common/GUI/PlusGUI/Math/SignalPlusGUI.sc (working copy)
@@ -136,7 +136,7 @@
 + Function {
 
  loadToFloatArray { arg duration = 0.01, server, action;
- var buffer, def, synth, name, numChannels, val;
+ var buffer, def, synth, name, numChannels, val, rate;
  server = server ? Server.default;
  if(server.serverRunning.not) { "Server not running!".warn; ^nil };
 
@@ -148,18 +148,18 @@
  val.dump;
  Error("loadToFloatArray failed: % is no valid UGen input".format(val)).throw
  };
- if(val.rate != \audio) {
- val = K2A.ar(val);
- };
+ rate = val.rate;
  if(val.size == 0) { numChannels = 1 } { numChannels = val.size };
- RecordBuf.ar(val, bufnum, loop:0);
- Line.ar(dur: duration, doneAction: 2);
+ RecordBuf.perform(RecordBuf.methodSelectorForRate(rate), val, bufnum, loop:0);
+ Line.perform(Line.methodSelectorForRate(rate), dur: duration, doneAction: 2);
  });
 
  Routine.run({
  var c;
  c = Condition.new;
- buffer = Buffer.new(server, duration * server.sampleRate, numChannels);
+ buffer = Buffer.new(server, duration
+ * server.sampleRate * if(rate==\control, 1/server.options.blockSize, 1),
+ numChannels);
  server.sendMsgSync(c, *buffer.allocMsg);
  server.sendMsgSync(c, "/d_recv", def.asBytes);
  synth = Synth(name, [\bufnum, buffer], server);

[Scott Wilson-3]

I think there will be a new RC because of the libsndfile issues, so  
why don't you add it so it can be tested?

S.

On 23 Apr 2009, at 12:00, Dan Stowell wrote:

> Hi -
>
> Function:loadToFloatArray doesn't complain if the function produces
> k-rate output, it gives you numbers, but they may not be the numbers
> you expected: K2A interpolation is always imposed.
>
> s.boot
> {SinOsc.ar(1)}.loadToFloatArray(1, action: {|array|
> array.size.postln}) // I get 44100 as expected
> {SinOsc.kr(1)}.loadToFloatArray(1, action: {|array|
> array.size.postln}) // I expect 44100/64 but get 44100
>
> There's a comment in the method source code saying "no need to check
> for rate as RecordBuf is ar only" but that's not true (no longer true,
> at least).
>
> The attached patch updates Function:loadToFloatArray so that it works
> transparently with k-rate functions rather than forcing them to
> interpolate. I guess this patch is not urgent so it should only make
> it into 3.3 if a new RC happens for other reasons. Feedback welcome.
>
> Dan
> --
> http://www.mcld.co.uk
> <loadToFloatArray_kr.patch.txt>

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

[Dan Stowell]

OK, that sounds fair enough.

Thanks
Dan

2009/4/23 Scott Wilson <s.d.wilson.1@...>:

> I think there will be a new RC because of the libsndfile issues, so why
> don't you add it so it can be tested?
>
> S.
>
> On 23 Apr 2009, at 12:00, Dan Stowell wrote:
>
>> Hi -
>>
>> Function:loadToFloatArray doesn't complain if the function produces
>> k-rate output, it gives you numbers, but they may not be the numbers
>> you expected: K2A interpolation is always imposed.
>>
>> s.boot
>> {SinOsc.ar(1)}.loadToFloatArray(1, action: {|array|
>> array.size.postln}) // I get 44100 as expected
>> {SinOsc.kr(1)}.loadToFloatArray(1, action: {|array|
>> array.size.postln}) // I expect 44100/64 but get 44100
>>
>> There's a comment in the method source code saying "no need to check
>> for rate as RecordBuf is ar only" but that's not true (no longer true,
>> at least).
>>
>> The attached patch updates Function:loadToFloatArray so that it works
>> transparently with k-rate functions rather than forcing them to
>> interpolate. I guess this patch is not urgent so it should only make
>> it into 3.3 if a new RC happens for other reasons. Feedback welcome.
>>
>> Dan
>> --
>> http://www.mcld.co.uk
>> <loadToFloatArray_kr.patch.txt>
>
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscription, etc.):
> http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>

--
http://www.mcld.co.uk

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/