linuxaudio.org

--e89a8f83a7d77da12604b9d15cc3

Content-Type: text/plain; charset=ISO-8859-1

Content-Transfer-Encoding: quoted-printable
Hi everyone, hoping to get opinions from gurus on here, who have been

*incredibly* helpful in getting my project to where its at. A million thank

yous!
Ok, the situation so far, which is working well:

- the app uses a generalized 'message' structure, all the different forms

of messages fit into this structure by having it act alike a union. ( ie, a

message always takes up the same amount of space, no matter the type )

- messages do not container pointers, in order that they be simple to send

and receive over network clients, hardware, etc

- there are ringbuffers between my audio thread and real time thread
What I'm tackling:

- I want to add the capability for messages to have deferred execution, so

they can be sent with a 'process at 4:3:1' kind of thing

- I think the best tradeoff for my app so far will be to use a hybrid of a

timeline array and a linked list. there will be coarse time values stored

by raw array indexing, speeding up lookup, and fine time values will be

stored in the messages themselves

- so, when the engine is processing deferred messages, it will go and check

timelineArray for all messages at bar 1:beat 1, which will be a linked list

of all the messages with start time between bar:1 beat 1 and bar 1: beat 2

( time resolution may change, this just for example

- then the engine iterates on every tick through that list of messages.

This way, iteration on every tick is limited to a reasonable sized linked

list and I can play with the cpu vs data storage equation by simply

changing the resolution of the time line array
Issues:

- I need to allocate memory for new linked list items in the realtime threa=

d

- the timeline array needs to be able to grow in the real time thread
Thoughts:

- I don't need to get it perfect *right now* but I need to be able to

change it to Really Good later

- I checked out some resources, like this one the Design Patterns for *Real=

*

-*Time* Computer *Music*

Systems

and the supercollider book chapter and see there are a lot of options

- I could pre-allocate a giant list of messages and pluck the data off that

list when I need to make a new one

- I could pre-allocate a block of memory and allocate off that

- I could allocate in the non-realtime thread and then pass memory over in

queues.
Would love to hear opinions on how others would solve these, including

tradeoffs of each.
thanks!

iain
--e89a8f83a7d77da12604b9d15cc3

Content-Type: text/html; charset=ISO-8859-1

Content-Transfer-Encoding: quoted-printable
Hi everyone, hoping to get opinions from gurus on here, who have been *incr=

edibly* helpful in getting my project to where its at. A million thank yous=

!Ok, the situation so far, which is working well:

- the app uses a generalized 'message' structure, all the diff=

erent forms of messages fit into this structure by having it act alike a un=

ion. ( ie, a message always takes up the same amount of space, no matter th=

e type )

- messages do not container pointers, in order that they be simple to =

send and receive over network clients, hardware, etc- there are =

ringbuffers between my audio thread and real time thread

What I'm tackling:- I want to add the capability =

for messages to have deferred execution, so they can be sent with a 'pr=

ocess at 4:3:1' kind of thing- I think the best tradeoff for=

 my app so far will be to use a hybrid of a timeline array and a linked lis=

t. there will be coarse time values stored by raw array indexing, speeding =

up lookup, and fine time values will be stored in the messages themselves

- so, when the engine is processing deferred messages, it will go and =

check timelineArray for all messages at bar 1:beat 1, which will be a linke=

d list of all the messages with start time between bar:1 beat 1 and bar 1: =

beat 2 ( time resolution may change, this just for example

- then the engine iterates on every tick through that list of messages=

. This way, iteration on every tick is limited to a reasonable sized linked=

 list and I can play with the cpu vs data storage equation by simply changi=

ng the resolution of the time line array

Issues:- I need to allocate memory for new l=

inked list items in the realtime thread- the timeline array need=

s to be able to grow in the real time threadThoug=

hts:

- I don't need to get it perfect *right now* but I need to be able=

 to change it to Really Good later- I checked out some resources=

, like this one the=A0De=

sign Patterns for Real-Time Computer Music Syste=

ms

and the supercollider book chapter and see there are a lot of options<=

/div>- I could pre-allocate a giant list of messages and pluck the dat=

a off that list when I need to make a new one- I could pre-alloc=

ate a block of memory and allocate off that

- I could allocate in the non-realtime thread and then pass memory ove=

r in queues.=A0Would love to hear opinions on how=

 others would solve these, including tradeoffs of each.

thanks!iain
--e89a8f83a7d77da12604b9d15cc3--