Mike S

is there a quick way of getting function in to a buffer that doesn't require uzi or a counter? i know this works fine for smaller buffer sizes but it can take a while with larger ones

getting-function-in-to-a-buffer

You could generate the function once and then write it to a file.

The signal objects could maybe do this faster than uzi, but I haven't tested it.

count~ --> get function value --> peek~ (or poke~)

though maybe getting the function value slows it all down anyways...

For the scheduler, anytime you can use an uzi instead of a counter, it's much faster, though it's also more possible that time-intensive processes will get skipped or done out of order. I imagine this one works fine.

The signal objects could maybe do this faster than uzi, but I haven't tested it. 

count~ --> get function value --> peek~   (or poke~)

For the scheduler, anytime you can use an uzi instead of a counter, it's much faster, though it's also more possible that time-intensive processes will get skipped or done out of order. I imagine this one works fine.


I'm not sure about any speed increase but using a [jit.buffer~] certainly makes patching everything together a whole lot easier.

the problem with uzi is that with longer envelope times it causes max to beachball for a while, this sometimes introduces max's famous snap crackle and pop in to the audio.

i have tried signal objects before, and to be honest they would be ok with this project (drum synth) as the envelopes aren't that long. the real reason for this is to have sample accurate triggering, i have another thread somewhere about syncing an oscillator to an envelope and this is essentially what i'm doing in the drum synth.

the only way (bar adsr~) i can figure to have the envelope sample accurate with the start of the oscillator is to write it to a buffer and read it using count~ or play~ while simultaneously reading a frequency envelope for the oscillator.

i had thought that i could use zig zag to store a list of the points, and then trigger this with a signal, but i don't think it works like that.

the only way (bar adsr~) i can figure to have the envelope sample accurate with the start of the oscillator  is to write it to a buffer and read it using count~ or play~ while simultaneously reading a frequency envelope for the oscillator.

i had thought that i could use zig zag to store a list of the points, and then trigger this with a signal, but i don't think it works like that.


Mike, have you found a quick way to get a function into a buffer~ without using peek~, jit.expr or jit.buffer~ as Luke suggested above? I have a js algorithm that generates a list of numbers ranging from -1. to 1. of overall length 2^x (with x user defined) and was wondering if there is a way to get these numbers into a buffer~ without using peek~.

I didn't find another way, though with the benefit of a few more years piddling away in Max I would suggest using two buffers, and maybe fading between them to stop clicks. Obviously if the buffer is long then you might run in to the problems I found.

It might be interesting to try the MXJ route thought I don't know if this would be any more useful. You can peek and poke in Java but I do remember results being fairly similar on another project.

It kind of depends on what you're doing, if things don't have to be that quick then you could do some form of slowing the whole operation down.

The length of the js generated list of samples (2^x) is kind of patch/performance depended, and this number (2^x) also changes the samplesize of the buffer~. At the moment, I am getting the data inside there using the peek~ object. For short buffers the time it takes to fill the buffer~ is not a big issue, but for longer ones, problems like the ones you describe in this thread, can occur. An idea I had was to scipt the buffer~ object with the js code, and see whether this might make things faster, but haven't tried it yet.

getting function in to a buffer~