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.