> > 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 _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list