may i drop in a different request : basic buffer manipulation OSC commands : /b_copy : copy a range of samples from one buffer to another(we could have a skip argument here that could then be used for de- interleaving)
like possible args: source buffer target buffer (can be identical to source buffer) source offset (samples not frames ; defaults to 0) target offset (samples not frames; default to 0) numSamples (-1 = as many as possible) source step (defaults to 1) target step (defaults to 1) so copying the left channel of a stereo buffer a to mono buffer b: source buffer = a; target buffer = b; source offset = 0; target offset = 0; numSamples = -1 source step = 2; target step = 1; same for the right channel, but source offset = 1alternatively one could argue for an argument "skip" instead of "step" where skip = step - 1.
/b_mix : add a range of samples from one buffer to another like target = target * weight1 + source * weight2 /b_mult : multiple ranges of samples from one buffer into another like target = target * source * weight;/b_norm : normalize a buffer (i tried to do a trick using a zero amplitude sinus b_fill with normalize option but that didn't work)
these operations would be very usefull and can only be done in "realtime" now using UGens. all of them could be asynchronous commands.
?? best, -sciss- Am 06.06.2006 um 13:21 schrieb stefan kersten:
On Tue, Jun 06, 2006 at 12:57:31PM +0200, Sciss wrote:for interleaved formats, i doubt that a probably really small performance improvement will justify all the extra logic needed to add a channel-extraction OSC command. apart from the bits of extra buffer memory, i think it's straight forward to read in all channels and then pick out the ones you need using array indices or Select.arthis might be true for PlayBuf, but there are other buffer access ugens that fail on multichannel data (like TGrains). i think adding channel selection arguments to both b_read and b_allocRead would be a very valuable addition. <sk>