buffer~ size and waveform~ view length
Currently, I'm sending a float into a "size $1" message, to resize two buffers. It changes the display size in waveform~ very quickly and automatically if I'm inputting a smaller number - but if I try to resize to a larger number, I tend to have to click and drag the float.
This is in a patch with several resized buffers and playbacks. When I isolate the mechanic into a single patch, it seems to work fine. Is there something like a polling rate for the waveform~ update? Or a way to ensure the accuracy?
I am running on Max 6.
The problem only seems to occur after I've initialized the DAC.
I don't seem to be using a lot of the CPU- but maybe this is related to the I/O Vector?
If I understand the nature of this, then you probably want to set a maximum buffer length, and then crop the buffer after your process is done. You should also check the 'buftime' message to waveform~, this will update the rate in milliseconds that the waveform is redrawn (careful as lower values are a huge CPU hog).
Question: Are you actually wanting to resize the buffer, or just your view of the buffer? I tend to treat buffers roughly how I treat tapin~ objects, which is that I usually set the length higher than I'll ever need it and then just use some portion of that range. It may be the slow-downs are because you are reallocating the buffer with another size. The waveform~ object has messages to adjust the portion of the buffer that is displayed if that's all you need.
Thanks! These work-arounds definitely give me a route to follow.
The buffer is actually getting resized - the waveform~ is not updating consistently (even with the buftime set). If I add a "display length" message with a delayed bang, it seems to function as another work-around. Just a little curious about what this is all about - maybe you can suggest some reading about how Max prioritizes or drops messages?
Actually, I take that back - the "pipe" + size message does not work :)