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

On Wed, February 24, 2010 23:15, Harry Van Haaren wrote: No access to university lecturers I'm afraid, or programmer friends, just online, and a local linux user group once a month. After posting, I remembered the age-old-advice from the ancients... "Search the archives!" http://lists.linuxaudio.org/pipermail/linux-audio-dev/2005-June/012941.html 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: 1) MODEL: 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 3) CONTROLLER: 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 jack_process_cb). * 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. lastly: 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. james.