[LAD] wanted: good online reading material for RT audio/midi software design?
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
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,
the gui - where the user controls generation of notes and is shown notes
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