option for buffer population in dsp function about extempore HOT 6 CLOSED

Hi Timo,

On Tue, Aug 14, 2012 at 7:05 PM, Timo Westkämper
[email protected]:

It would be nice to have the option to populate buffers as an alternative
to sample by sample processing in the dsp callback.

Looking at the C++ code it looks like this option has already some stubs
available.

This should already be implemented. dsp:set! accepts two (and only two)
closure signatures.

[double,double,double,double,double_]_
a closure that takes sample in, channel, time, user data, and returns
sample out.

and

[void,float_,float_,float,i8_]_
a closure that takes input buffer, output buffer, time, user data. (void
return type)

The size of input buffer and output buffer is defined by the i64 globals
IN_CHANNELS, CHANNELS, FRAMES
(these are defined at the top of audio_dsp.xtm)

such that the size of the input buffer in 32bit float samples is
IN_CHANNELS*FRAMES
this may be interleaved or non-interleaved depending on the portaudio
config (usually interleaved).

obviously you are responsible for filling the output buffer appropriately.

This would make the following cases more intuitive

• processing of multi channel input
• generation of multi channel output with interdependent channels,
  e.g. stereo mixing etc
• maybe faster usage of polyphony, since instruments can be muted for
  a full buffer population

there is certainly a performance improvement when using the buffered
option, significantly reducing the number
of closure calls required. Overall you can get as high as a 30% performance
gain in my brief experiments.

However, clarity is lost, as is our nice functional style. So if you are
after processing cycles then buffers
are recommended, but for livecoding I highly recommend you take the
performance hit and stick with the
more functional approach, at least when playing around. This avoids a
whole bunch of pointer arithmetic
and looping that is bypassed in the more functional approach.

Also note that by default code optimization is OFF. You can turn it on by
calling (llvm:optimize #t).

It's worth pointing out that multichannel input is available in the
standard sample by sample approach,
although admittedly obscurely ;) The user data in sample by sample
actually now contains ALL input
channels. In other words the user data is a double* with IN_CHANNELS
number of elements and
remains the same for each output call in the frame. In the case of 4 in
and 8 out this would mean
that the same user data buffer of 4 elements (input samples) would be made
available to all 8 calls
to the dsp routine (i.e. once for each output channel). This is in
additional to the standard in sample
that works as usual (i.e. in chan -> out chan). This user data should
support everything you need.

We should obviously change the name user data. My apologies for that, the
name is an old carry
over from impromptu and is no longer valid.

This should all be working as discussed but if anything isn't working "as
advertised" please
let me know and I'll fix it ASAP.

Cheers,
Andrew.

So maybe as an addition to

in:double time:double chan:double data:double*

the following signature could be supported

in:double** out:double** time:double count:uint32 data:double*

in - pointer for input buffers
out - pointer for output buffers
time - time of start
count - size of individual buffers
data - same as in the other signature

maybe also

in_buffers - number of input buffers
out_buffers - number of output buffers

count, in_buffers and out_buffers could also be environment variables

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/59.

from extempore.

Great, but why floats for the buffer signature? Wouldn't it be consistent to have doubles there as well?

I agree that for live coding the sample by sample approach might be more intuitive.

Feel free to close this ticket, since the requested signature is already implemented. Is it documented somewhere?

from extempore.

no but we'll get onto that ;)

also, should just mention that this is all only implemented for portaudio
(i.e. not coreaudio)
I'm pretty sure portaudio is the default build profile on OSX as well these
days so shouldn't
be a problem.

floats because I'm assuming people will use the buffered approach when
performance
is more important than style ;) while on 64bit architectures the whole
float vs double thing
is less critical but it does become more important when talking about SIMD
(i.e. /4,float/) )

On Tue, Aug 14, 2012 at 8:20 PM, Timo Westkämper
[email protected]:

Great, but why floats for the buffer signature? Wouldn't it be consistent
to have doubles there as well?

I agree that for live coding the sample by sample approach might be more
intuitive.

Feel free to close this ticket, since the requested signature is already
implemented. Is it documented somewhere?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/59#issuecomment-7721864.

from extempore.

Ok, is this already supported for Linux / JACK?

from extempore.

JACK no, Linux yes through portaudio.

I would suggest sticking to portaudio at the moment as the
jack side hasn't been updated in a long while.

OR you could bring it up to speed if you like ;) A nice
small isolated bit of code for you to get stuck into.

There's also the start of an ALSA option in there that would
be great to finish off :)

Cheers,
Andrew.

On Tue, Aug 14, 2012 at 8:41 PM, Timo Westkämper
[email protected]:

Ok, is this already supported for Linux / JACK?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/59#issuecomment-7722225.

from extempore.

I will take a look, thanks ;)

from extempore.