[LAD] Conciderations of Design

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Linux Audio Developers <linux-audio-dev@...>
Date: Friday, November 11, 2011 - 10:19 pm

--00151749f7820bb0fc04b17ceb3d
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes

Hi All,

Recent thoughts of mine include changing the "direction" of operations in
real-time program design:
Eg: Don't call a set() on a Filter class to tell it its cutoff, every time
there's a change,
but make it ask a State class what its cutoff should be every time it runs.

I'm now considering implementing this pattern, but I'm wondering have
others done this before?

Along the same lines, say I have a single linked list of AudioElements, and
the 3rd element needs info, should
it request it, be told it, or have some other system to inform it of events?

I'm seeing downsides to each approach:
1: Tell it on every change -> performance hit
2: Request it every time it runs -> Keeping control over the many values &
unique ID's of class instances

Experience & Opinions all welcomed, -Harry

--00151749f7820bb0fc04b17ceb3d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi All,Recent thoughts of mine include changing the "direc=
tion" of operations in real-time program design:Eg: Don't ca=
ll a set() on a Filter class to tell it its cutoff, every time there's =
a change,but make it ask a State class what its cutoff should be ever=
y time it runs.I'm now considering implementing this patter=
n, but I'm wondering have others done this before?Along the=
same lines, say I have a single linked list of AudioElements, and the 3rd =
element needs info, shouldit request it, be told it, or have some oth=
er system to inform it of events?I'm seeing downsides to ea=
ch approach:1: Tell it on every change -> performance hit2: =
Request it every time it runs -> Keeping control over the many values & =
unique ID's of class instancesExperience & Opinions all wel=
comed, -Harry
--00151749f7820bb0fc04b17ceb3d--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[LAD] Conciderations of Design, , (Fri Nov 11, 10:19 pm)
Re: [LAD] Conciderations of Design, Thorsten Wilms, (Sat Nov 12, 10:31 am)
Re: [LAD] Conciderations of Design, David Olofson, (Fri Nov 11, 11:42 pm)
Re: [LAD] Conciderations of Design, Harry van Haaren, (Sun Nov 13, 6:43 pm)