Only one at a time, but they are tables of perhaps 300000 points. Then I copy
data from the input buffer into the table.
In your situation I'd try to do everything that doesn't necessarily need to happen in 0 logical time to extend to > 0 logical time. Unless you really need the new tables immediately after the buffer was filled, I'd suggest to copy them over 'slowly'. One approach once mentioned by Miller Puckette is to do array copying by doing it in the audio domain within an upsampled sub-patch. This would make DSP drop-outs during array copying much less likely.
Hmmm...perhaps it would be better, to play them into another [tabwrite~]. Its just that I wanted them immediately an event ended so that I could do reversed playback of an event just as the next event begins.
It has to be running with the audio, since the audio is being re-mixed in
real
time.
Wrong. Dynamic creation happens in 0 logical time. Now let's consider a case where you dynamically create several objects in one go. After every single object the DSP graph is recompiled. The real time this process takes is quite high. Now if you'd first turn off DSP, create all necessary objects dynamically and then turn DSP on again, the DSP graph is recompiled once and the real time this takes is much shorter. If you're lucky, it will be so short (shorter than your current audio buffer setting), that you don't even notice a drop out.
Just to make myself more clear: It's perfectly possible to turn DSP off and on again in 0 logical time without noticing it at all, even when there is some audio processing going on.
WHOA! I did not think of that. I'll try it.
Ed
Everything works fine if I'm using the onboard sound - e.g. OSS, but the problems only happen when I switch to jack. Of course the onboard sound would be
OK if I was using only output, but the whole point is to live-sample the input.
The mic input on my laptop is really crappy.
- try to get the DSP graph building into a separate thread.
well, this involves pd~ or the like....
Dammit again - I'm using the second core of the machine for the live score, dynamic object creation in GEM
- but I see the new version of Inscore supports PD, so all my work over the
last 6 months has been for nothing.
I wouldn't be too sure about that. Try to figure out what needs to really happen in 0 logical time, since most often the problems of audio drop outs is that Pd is requested too much to compute in 0 time. Try to distribute as much as possible over time, so that as many things as possible happen continuously and as little things as possible need to be calculated instantly.
Roman