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

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


On Wed, Dec 04, 2002 at 11:05:21AM -0800, Tim Hockin wrote:
> > I dont really like using strings for UIDs though. Its too easy to read
> > semantics into them.
> 
> I agree about semantics, but self-maintenance makes this much more
> appealing.  Of course, domain registration expires.

Thats why its inportant to choose your URIs carefully. It could also be
viewed as another rason to issue central ints, they dont expire ;) As long
as there is a reserved block for experimentation, its its easy to get real
IDs it should all be OK.
 
> > > I disagree with that - this is a waste of DSP cycles processing to be sent
> > > nowhere.
> > 
> > No, its a waste of DSP cycles to check whether something's there or not.
> 
> can we meet in the middle and say that for some cases it is easier to assume
> silence, and in others it is easier to check for presence?

OK, maybe. But (as discussed elsewhere) in an event system theres no need
to check, there wont ever be any events on unconnected inputs.
 
> > I'm not sure about the other arguments, but polyphony control is complex
> > and probably only the instrument can do it usefully. If you want this you
> > might have to do it by telling the instrument what its max poly should be.
> 
> Perhaps this, with some way of the instrument telling the host about numbers
> of voices.

If you think its neccesary, it is meaningless in some cases though and I'm
not clear on what it would be useful for. Every instrument feature adds to
the barrier to entry and needs to be justified.

> > I dont think you can do anything useful with a generic file string, what
> > could be host use it for?
> 
> The host could provide a standard file-open dialog for filenames.  The host
> could provide a text-box for speech-synthesis.

OK, I'm starting to come round on this one.

- Steve



More information about the Linux-audio-dev mailing list