Subject: Re: LADPA (was Re: [linux-audio-dev] emagic (logic) drops VST support under OS X)
From: Paul Davis (pbd_AT_op.net)
Date: Wed Sep 04 2002 - 17:33:21 EEST
>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
This archive was generated by hypermail 2b28 : Wed Sep 04 2002 - 17:43:10 EEST