Subject: Re: [linux-audio-dev] quasimodo/csound opcodes
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Mon Jun 05 2000 - 21:26:33 EEST
>I don't know what to think. I think q opcodes needs a rewrite to handle
>the fact that sample_count may change and sample_rate is not
>the same across instances. I don't know if it's worth continuing...
the vast majority use `ksmps' to tell them how many samples to
process. at the moment, this is a global variable, as per
Csound. although it could be adjusted globally, what would be better
is to figure out a way to pass it into the opcode. given that nearly
all of them include a local declaration of `ksmps' it can't be *too*
much work, can it ?
however, i tend to think that it would be more valuable to drop the
entire Csound-compatible calling convention in favor of one that is
more transparent. that is, don't try to define opcode-specific data
structures that are passed in to the opcode. just pass in the same
thing as run()/runAdding() does, and have them infer the rest from
there. example:
void
fooRun (LADSPA_Handle handle, unsigned int nsamples)
{
FooPrivateDataType fd = (FooPrivateDataType *) handle;
char *buf = fd->buffer;
char *something = fd->something;
while (nsamples) {
...
nsamples--;
}
}
something like that, anyway.
as for the wavetables - this needs a totally different approach to the
one in Quasimodo/Csound. the tables should be considered private to
the opcode/plugin, instead of part of a shared resource. this would be
good because i was planning on adding a namespace to the tables in
Quasimodo anyway. this way, you don't set up a port that is connected
to a wavetable - you set up as many ports as the relevant generator
requires, and run the generator internally. that way, when the plugin
is removed, it can clean up its wavetables all by itself. much cleaner
than the Csound all-tables-are-shared approach, though if there was a
really common shared table, it does lead to duplicated memory regions.
of course, there is still the problem that ports are untyped, and in
some typical cases (wavetables generated from soundfiles), the value
of the port needs to be some kind of string.
this also causes the opcodes/plugins to have to duplicate the
generator code, but the "helper" approach may assist with this.
--p
This archive was generated by hypermail 2b28 : Mon Jun 05 2000 - 21:59:54 EEST