On 01/20/2010 01:56 PM, Harry Van Haaren wrote: Okay, then I'll explain the basic idea of timing with JACK midi, which is special because sample synchronized. If you want to use ALSA midi directly then it's different and not covered below. So currently, in JACK you can either create audio or midi ports. Every time your jack process() is called you have to deal with a buffer of N audio frames on your audio ports, where N is the jack buffer size. The jack_position_t::frame, as set by jack_transport_query(), indicates the transport frame position of (the first frame of) this buffer. Now what about a midi output ports? They are meant to contain midi events, which you can write into the midi port buffer using either jack_midi_event_reserve() or jack_midi_event_write(). Both of these functions accept a time argument which is meant to be the frame offset of the event relative to the beginning of the buffer. Now putting things together, assuming that you want a midi event to occur at 00:00:10 (H:M:S), here's an untested example of what your process() might contain: double event_time = 10; // seconds jack_nframes_t event_framepos = event_time * jack_get_sample_rate(client); jack_nframes_t buffer_size = jack_get_buffer_size(client); jack_position_t position; jack_transport_query(client, &position); jack_nframes_t event_offset = event_framepos - position.frame; void* port_buffer = jack_port_get_buffer(midi_output_port, nframes); unsigned char* buffer; jack_midi_clear_buffer(port_buffer); if (event_offset >= 0 && event_offset < buffer_size) { jack_midi_event_write(port_buffer, event_offset, ...); } For BBT I guess that you just need to compute the event_framepos of my above example using the various values (beats_per_minute, beats_per_bar, etc...) of jack_position_t. I also recommend that you look at the (tested) JACK midi example clients. Hope that helps -- Olivier

Hey, Thanks for the JackMidi crash course. That's definatly some food for thought. I've tried to get the JACK Midi things working before, but I've never managed. I see the value in the sample-accurate-ness of JACK midi, so I think ill skip the AlsaSeq implementation. I've the docs there though, seem noteworthy just to have read. Pedro: Thanks for the links, there's seems to be material in both. Olivier: Thanks you, I'll play around with the JACK example clients, and see how the brain here reacts... :-) Cheers guys, I'm off to do some trials, will post back if I find a "perfect" solution! -Harry

On Wed, Jan 20, 2010 at 09:01:36PM +0100, Olivier Guilyardi wrote: well.. the real problems are a bit deeper. and not really touched be any example clients. you need to have lockfree access to the note sequence. while still being able to manipulate it from the gui thread. several approaches to achieve this are possible. and it depends a bit on taste and the app to select them. but the major part of complexity lies here. -- torben Hohn

On Thu, Jan 21, 2010 at 07:48:20AM -0500, Paul Coccoli wrote: you can specify an Allocator for most STL containers. but i am not aware of anybody using them with an RT safe allocator. might be possible. but the allocator is not the problem. its lockfree access. dunno... i never looked at implementing an allocator. shouldnt be that hard. but as stated, this is still a trivial part of the problem. -- torben Hohn

On January 21, 2010 09:28:19 am torbenh wrote: You mean the heap? MusE-1 does this. See muse/memory.cpp and muse/memory.h, and the usage of it for allocating play and record events in muse/mpevent.h Ultimately it just uses 'new' for the actual allocation. MusE-2 does not custom allocate, but like MusE-1 still uses inter-thread messaging. You might find some good ideas in both. We have this in MusE-2's equivalent, it appears to just use default alloc rather than the commented out attempt: // typedef std::multiset<MidiEvent, std::less<MidiEvent>, // __gnu_cxx::__mt_alloc<MidiEvent> > MPEL; class MidiEventList : public std::multiset<MidiEvent, std::less<MidiEvent> > I think it's because in MusE-2, being a Jack midi app, audio event lists (used by audio thread) and midi event lists (used by midi thread) were unified. In MusE-1, an ALSA midi app, for the audio and midi threads the two lists are separate, requiring custom alloc. What about instead of alloc, would this be of use to you (us)? In SGI's help Allocators.html: "pthread_alloc A thread-safe allocator that uses a different memory pool for each thread " Tim.