> > 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
