Re: [LAD] Conciderations of Design

David: Thanks for such insight & in-depth response. The points you've made
are being taking into concideration at the moment. "Polling" is indeed
probably the term I was looking for, but didn't come to mind.

I suppose I should have shed light on the "use-case" a touch more in my
initial question: Its for a live program where all processing is done in
blocks. So no need for sample accuracy or any of that, polling is the
winner :D

Re: Connection logic... I've not yet decided how to approach this.
Currently "state" is handled in each class, but this provides bigger
problems: every parameter change needs to be passed to that class, and the
way I have that implemented currently means about 6 function calls, and
lots of array access... hogs up JACK cpu time and is inefficient.

Thorsten: Intresting read, I don't think FRP is a route I'm going to take
at the moment, as it would null all work I have done so far... but it did
get me thinking in different ways :)

Jeff: Nice balance between performance & flexibility. As prev noted, its a
"block-processing" app, so I won't implement the audio rate controls. Never
the less, thanks for the tip!

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sun Nov 13 20:15:01 2011