[linux-audio-dev] Plugin APIs (again)

Steve Harris S.W.Harris at ecs.soton.ac.uk
Wed Dec 4 13:37:00 UTC 2002


On Wed, Dec 04, 2002 at 06:59:12PM +0100, David Olofson wrote:
>                                                   I definitely prefer 
> having the host merge/sort, or even having senders sort/insert when 
> sending events. I'm doing the latter in some cases currently, but I'm 
> not sure it'll stay that way. When you know there's only one sender 
> to a port, you can just tack events onto the end of the list, but 
> that only works for very simple plugin nets. The main problem with 
> sender sort/insert is that it more or less requires a function call, 
> while "add as last event" is a very simple operation that is 
> preferably inlined.

I agree, you dont want event sorting code in every instrument, you will
end up with some very odd behaviour due to bugs.
 
> Good point. In fact, I would say that pitch and velocity are just two 
> arbitrary "instantiation parameters" for notes. For some instruments, 
> they're hardly applicable at all, while for others, they're 
> completely insufficient. That's why I'm leaning more and more towards 
> entirely doing away with on/off events as such, and just using 
> controls. A synth can interpret a "velocity" control like an on/off 
> switch with note on velocity - or as bow speed, or air flow/pressur, 
> or whatever...

Yes, but voice_on/off is a commonly useful abstraction. Hoever making sure
htat the API is scale neutral (unlike generic MIDI) is important. I'm not
sure what the best way to ensure this is.

Obviously pitch and velicty are optional, not all instruments have either.
Thats one reason if favour of using well know portt names to indicate what
voice parameters normally map to what MIDI controls.
 
> How about the host knowing that this is the name of a file that 
> should go with the project? I would suggest the following file name 
> "flags":

OK, that is a good point, it would make the host able to store the session
more easily, and package it up my copying the file into local space, and
changin the path.
 
> Right, either you get memory - or you're screwed.
> 
> That said, it's possibly to implement real time memory managers, and 
> I think the host designer should have the option.

But if the api is like LADSPA you're not allowed to do allocation in the
RT part anyway, so you may as well stick to malloc and friends. If hte
host is desperate to use something else it can override them with
LD_PRELOAD.
 
> Good point. I still think it's nice if hosts can construct basic GUIs 
> for simple plugins, but I see no point in taking any major design 
> measures with host constructed GUIs in mind.

Sure, but simple instruments dont require file i/o or any of that stuff
anyway.

- Steve



More information about the Linux-audio-dev mailing list