On 26/03/2013 4:55 PM, Alan Wolfe wrote:
I just wanted to chime in real quick to say that unless you need to go
multithreaded for some reason, you are far better off doing things
single threaded.
Introducing more threads does give you more processing power, but the
communication between threads
Hi Didier,
you should be aware that DirectMusic is deprecated for a long time now
( was pretty much born dead)
Thanks, yes I know that. I like retro :-)
Seriously though, I hardly touch any of DM (and never have), it's just that
synth that is still relevant.
It's the underlying engine
Hi Ross,
Thanks, couple more questions then:
- There can be significant jitter in the time at which an audio callback
is called.
Can you define jitter? Callbacks with different frame counts, or dropped
frames?
If the former, it would seem my proposed mechanism could adapt, as long as
On 26/03/2013 5:28 PM, ChordWizard Software wrote:
Hi Ross,
Thanks, couple more questions then:
- There can be significant jitter in the time at which an audio callback
is called.
Can you define jitter? Callbacks with different frame counts, or dropped
frames?
If you call
On Mar 24 13:09 robert bristow-johnson wrote:
...
this zero-padding issue applied to overlap-adding is for fast
convolution, using the FFT and iFFT to accomplish simple filtering with
a possibly very long FIR filter. but it has to be FIR, not IIR.
...
I guess in every case a filter can be
It's not so easy nowadays to program a real time audio windows app, I
think. It's been a long time since I've done such a thing, but think
about it as that thread-switching, kernel heartbeat interrupts and
buffering aren't what you're supposed to do much with. In general, one
process
