strange snapshot~ bug in poly~ context
In the last out of eight voices in a poly~ object, all snapshot~ objects don't function after turning on dsp. In all the other it works fine, but in this one it doesn't. I use a few of them with the argument 1 i.e. [snapshot~ 1]. When I increase the poly count to nine, a few others voices stop working as well.
I don't expect any useful feedback as this is so out of the ordinary, I just wanted to mention it here for the record. I was able to solve this issue by providing again the argument of 1 in the right inlet after turning on dsp, using [dspstate~]. I'm running this patch on MacOS10.13.6, max 7.3.5, dsp 48000/256/64).
I would avoid using [snapshot~] with anything less than 5 ms. If you want to test at audio rate, why not use a combination of [delta~], [==~], [edge~], things like this?
Another note when I see the patch: as far as I know, putting two [deferlow] objects one after the other is the same as using just one - do you see a difference? I would suggest to try and avoid using [deferlow] inside the [poly~] altogether, and give the 'loadbang' bang from your host patch, when it's loaded, if you need the voice number in the host patch.
Thank you for this input! An audio rate and therefor precise sequencer generates a counter that triggers midi events. It needs to be in audio, so various voices will remain in sync when they need too. The argument 1 represents 'as fast as possible'. Probably there won't be a lot of difference with an argument of 5, I could try that; out of curiosity, why would you avoid anything less? It does seem to work fine in all the other voices, as well as after providing the argument once more in the right inlet.
The two deferlows were there in an attempt to solve the issue of that single voice not starting properly (and it took me a while to figure out it was the snapshot~ object, first I thought it was a gen~). The main patch turns on audio automatically, and I wanted to make sure all voices reported their presence.
And indeed, the edge~ object is good alternative, gonna try that.
Thanks again.
I mentioned 5 ms, but 5 was more of an intuitive number. It's a general approach of mine: when I need extremely fast Max processing, I try to see if there is a way to do it in MSP (signal) world instead. The processing load in MSP is not necessarily heavier than in Max.
Another way to look at the [snapshot~] refresh rate: I know you use a 64 sample vector size, which is 1.3 ms at 48 kHz. So, this is close to your 1 ms snapshot~ refresh rate. But if you were to use a vector size of, say, 256, that would be roughly 5ms. In that case, there would be no interest to use anything less than 5 ms for your [snapshot~]: snapshot~ is going to give you the same number for the duration of the whole audio vector, the first value in the vector I think (we could check that).
while your advice is true for the given case, i still dont see a good reason why the object stops outputting data when more than 8 instances are running.
if you put a metro 1 in poly 20 that also works...
Depending on the status for audio interrupt I found mixed results in the case of [edge~]->[snapshot~] in order to trigger once a changing value. The helpfile for snapshot~ shows the offset option that fixes certain situations but that's just too messy.
I went back to triggering as fast as possible, this time taking into account the vector size, using [count~] and [edge~]. I'm aware of the gap between theory and practice. As Roman points out, external triggering might simply be a safe choice.
Anyway, I am not able to reproduce this outside the context of patch that generates the error (sometimes I'm even loosing three voices). It has a rather long loading time, it uses gendsp code, pattrstorage, a lot of gui...
