Subject: Re: [linux-audio-dev] quasimodo/csound opcodes
From: Stephane Conversy (Stephane.Conversy_AT_lri.fr)
Date: Tue Jun 06 2000 - 12:27:19 EEST
Paul Barton-Davis wrote:
> >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 ?
no, it isn't, but it can't be done 'automatically', and I'm not sure
at that point that the wrapper files the script generates are
good enough to say :"ok, let's tweak them, knowing that
if we have to rebuild it again, all the hand-crafted work
will be lost".
> 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.
? I don't understand your point. This is what is done, except that Run
calls
the opcodes by passing the right structure.
> 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.
>
yes, and I think it's too bad. The more I think of this, the more I think
that the way we (ladspa) handle plugin is not general enough, but
it can't be more general.
I mean, only simple plugins have well defined ports, that manipulate
LADSPA_Data. But if you want a list of parameters (as with an envelope),
then you have to cope with LADSPA_DATA pointer.
With the current scheme, you have to provide a function that takes an
envelope
and setup the list (ie set_envelope_list(env*, ....)). ie: the host knows
it manipulates
an envelope, not some kind of general plugin.
Maybe we should provide a pointer to such a function, and special 'lists
ports', but
I think they will never be ports type general enough.
> 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.
>
another example...
> this also causes the opcodes/plugins to have to duplicate the
> generator code, but the "helper" approach may assist with this.
>
> --p
There is another problem with csound opcodes: some of them call hosts
functions
(to stop it for example)...
-- Stéphane Conversy http://www-ihm.lri.fr/~conversy/ mailto:conversy_AT_lri.fr
This archive was generated by hypermail 2b28 : Tue Jun 06 2000 - 11:56:00 EEST