[LAD] wanted: good online reading material for RT audio/midi software design?

James Morris james at jwm-art.net
Thu Feb 25 01:00:34 UTC 2010

On Wed, February 24, 2010 23:15, Harry Van Haaren wrote:
> We seem to be fairly intrested in the same things James!
> I don't know if you have access to University Lecturers... if you do, go

No access to university lecturers I'm afraid, or programmer friends, just
online, and a local linux user group once a month.

> I didnt really find any great
> resources online. If you do find any, please post back here! :-)

After posting, I remembered the age-old-advice from the ancients...

"Search the archives!"


talking about design, model-view-controller, more toward controlling a
synth, but at least the MVC design is a lead as to figuring out what I
must do.

there's probably more LAD posts which are relevant, it's just a matter of
figuring out the search terms to get them.


reading that thread above, this is how i'm now figuring things:

jack_process callback - where midi data is output, timebase polled,

2) VIEW:
the gui - where the user controls generation of notes and is shown notes
that play

 i)  time pattern: 1d - note position & duration
 ii) pitch pattern: 2d - pitch & velocity

i) time pattern:

( * pattern data modifiable by gui)

* input data comes from the model to provide data about the 'when' that is
'now' (where 'now' is however many frames to be processed in

* the data output by the pattern goes back to the model which...

ii) pitch pattern:

iia) * input data comes from the model requesting a pitch and velocity
     * box is algorithmically placed where it will fit, within the
       pitch/velocity grid giving the pitch and velocity data in answer
       to model's request
     * gui is told (somehow) to display the box

iib) * input data comes from the model requesting removal of a box
     * box is removed from grid (freeing up space for future box placement)
     * gui is told (somehow) to remove a box from display

this working-out using MVC design seems to indicate that the box placement
to obtain pitch/velocity is going to be within the RT thread (ie called
from jack process cb).

which is precisely the idea i began with and discounted because i believed
i would need malloc/free to create linked-lists of box placement data.

which suggests setting reasonable limits for the size of patterns and
using arrays or some-such of a pre-determined size.


1) i find writing emails can be helpful in working things out.

2) this app i place somewhere between an arpeggiator and a sequencer. it's
usage is neither. a usage scenario might be to create interesting
sequences modified in real-time by user, which are recorded by a sequencer
which can be edited note-by-note later. or just as a live performance
thing. this is all presuming it is possible to create something useful
sequences with it!

3) it won't/can't/shouldn't record.


More information about the Linux-audio-dev mailing list