>Ok, this is kind of what I was getting at. So in effect what we could
>do right now is simply come up with our plugin abstraction layer
>straight away without waiting for JACK to implement anything else?
the only real obstacle to JACK implementing anything else at this time
is providing some routines for allocating variably sized chunks of
memory from shared memory.
the audio data buffers are always the same size, which makes their
allocation and management simple. buffers for MIDI, control
information, strings, etc. require something more like malloc(3).
richard g. has told me in the past that he has some code for doing
this. if used, it would be really very simple to get JACK to be able
to pass around non-audio data. we already have the framework for it:
typedef struct _jack_port_type_info {
const char type_name[JACK_PORT_TYPE_SIZE]; /* what do you think ? */
void (*mixdown)(jack_port_t *, jack_nframes_t); /* function to mixdown multiple
inputs to a buffer. can be
NULL, indicating that multiple
input connections
are not legal for this data
type.
*/
long buffer_scale_factor; /* If == 1, then a buffer to handle
nframes worth of
data is
sizeof(jack_default_audio_sample_t) * nframes bytes large.
If anything other than 1, the
buffer allocated
for input mixing will be this
value times
sizeof
(jack_default_audio_sample_t) * nframes bytes in size.
Obviously, for non-audio data
types, it may have
a different value.
if < 0, then the value should be
ignored, and
port->shared->buffer_size should
be used.
*/
} jack_port_type_info_t;
so, to pass around, for example, string data, you'd just register
jack_port_type_info_t string_type = { "string", NULL, -1 };
to use the data in the buffer, a client would have to do this:
size_t buffer_size = jack_port_buffer_size (port);
where jack_port_buffer_size(p) is just a macro for (p)->shared->buffer_size
what's missing is code to allocate the buffer itself.
this stuff might (or might not) be a lot further along than you
think :)
--p
