Processes for Fluid.BufCompose~

@danieleghisi This looks awesome! Is there a minimum version of bach I should be using? I’m on 0.7.9 from the package manager, but am getting an instant crash in llll_get() when I open help files, e.g.

Thread 0 Crashed:: CrBrowserMain  Dispatch queue: com.apple.main-thread
0   ears.crop                     	0x0000000116216f7f llll_get() + 415
1   ears.crop                     	0x00000001161f747a llllobj_test() + 58
2   ears.crop                     	0x00000001161954cc main + 60

Do I need 0.8.x from the webstie instead?

Ouch, that’s 100% true… you surely need AT LEAST bach 0.8. And I hope that’ll suffice, otherwise I’ll send you a development version. I should add a version check beforehand with proper warnings.

bach 0.8 is available here:

we haven’t put it on the PM yet, we’ll probably go directly with 0.8.1 on PM in a couple of months.

Let me know if that fixes it
Daniele

Yes, they’re happy now – these are great!

What would be the syntax to mix all channels of a multichannel buffer into one mono buffer?
I’m doing it in several steps, one channel after the other, which is of course not efficient.
Thanks, Hans

It has to be done iteratively. A trick would be to do in pairs:

a+b = t1; 
c+d = t2; 
t1+t2=result

One day (soon-ish) there will be a syntax review of bufcompose with arrays as input, but that is not for the next few weeks.

How many buffer channels have you got?

the source buffers have eight channels
for now I’m using

process mybuf 0 -1 $1 1 monobuf monobuf

The $1 receives numbers 0…7 from an uzi

for 8, this is not as bad as we think (compare to any of the real processes we do inside the other objects) but I have the same reflex as you (to my coding colleague’s despair) and it shows our age (computers are now so fast but we still think of optimising all the time - but as @a.harker @weefuzzy and @groma like to remind me of the first rule of optimisation: do not optimise :wink: Actually, the most eminent computer algorithmic specialist, Don Knuth, says it more elegantly:

The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming .

Now, because I cannot take it out of my brains, this sum of 8 channel can be done in binary summing like this:
1+2=12
3+4=34
5+6=56
7+8=78
12+34=1234
56+78=5678
1234+5678=sum
7 operations

Your iterative option does it in 7 too
1+2=sum
sum+3
sum+4
sum+5
sum+6
sum+7
sum+8

for larger numbers it gets better but for the complexity of the code to maintain and for the difference, under a large number of channels, I would not bother and use basic iterative code… the code @weefuzzy shared has a clever trick to do the first one as a pair (which is more complex code for fun) but starting with a simple silence short ‘sum’ buffer does about the same and only adds one run…

For info, in Alpha02, I use BufCompose to do a convolution of a FIR filter - dirty and fun and quick enough not to bother. We should release soon :wink:

actually, thinking about it, pair-wise never gets better. It’s always n-1 sums, which we achieve with @weefuzzy trick…

The real refactor of doing a single summing pass with the new syntax of arrays of args as input will change things, but that is not for the next weeks. Soon though as it is on the radar to test other things.

It works like charm here ! Thank you !!

The reason that I asked: I have eight buffers. Each one is over a minute long and contains 8 channels. I’m only summing them into a mono file to get
one ‘mono’ visual representation of the content to specify regions for granulation. This is essentially a screen-space issue, I have no space to show all 8 channels of all 8 buffers. It does work almost instantly on shorter buffers, but with that amount of data it feels redundant to do this iterative process and wait…

I understand. I’ve done a (still dirty) multichannel buffer visualiser in javascript, which downsamples (takes the peaks) like the warpy2 example in the groove~ helpfile. It could be easily adapted to check the max of each channel for each pixel… would that help?

Only for your specific case, you could maybe use the quick and dirty classical way which uses a sfpay~ reading all files 25 or 100 times faster, get the envelope and display them with jit.poke~ and jit.graph ? You could then save onto disk the resulting waveform into a jitter matrix.
Or indeed a JSUI with downsampling. There are several available. I like the jitter version though because you can easily do much more afterwards.
That does not answer your question relative to summation within fluidDOT.

Yes, that would be great!

Actually not. Sorry. Just made a comparison with the javascript warpy.js from the groove help - versus the syntax I’m using with buffercompose.
Even with the iteration of the 8 channels, buffercompose it is about 5 times faster than the javascript method.

it will be - javascript is slooooooow! but the gui I’ve made is useful for grouping similar looking ranks as you will see in a new object coming soooooooon! :wink:

@tutschku if its just visual real estate you’re trying to save why not over translucent waveform~ objects? No rewriting necessary.

@danieleghisi ears.objects are really nice! ears.expr is the object I never knew I needed

@jamesbradbury - brilliant solution. Sometimes I seem to use expensive laser machinery to cut carrots. Being reminded that a knife would do the job as well is helpful.

2 Likes

Glad it is of use to you @tutschku :slight_smile:

Thank you @jamesbradbury (there’s a bug in the arguments arrow in its help file, though; of course the arguments are not start/end, but just the mathematical expression).
For my personal stuff, I’ve also been missing something like ears.pan quite a lot…