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

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!"

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.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev