4 Dec
2002
4 Dec
'02
5:10 p.m.
On Wednesday 04 December 2002 20.46, Steve Harris wrote:
It's different with audio ports, though. (Unless they were in fact
abstract objects, controlled by the host only through events sent to
the plugin. I were thinking along those lines in MAIA.)
An audio input or output either needs to have a valid buffer (which
may be a fake silence buffer, or a trash "/dev/null" buffer), or you
must ensure that the plugin checks the pointer.
I would prefer that plugins get to handle this themselves in any way
they like.
Dead simple:
Just say you don't support disconnected ports.
The host will have to give you fake buffers if
it wants to leave ports "open".
Nice but simple:
Accept disconnected ports, and just check the
pointers, or whatever. (Note that passing NULL
buffers might have other users. In Audiality,
it's legal for inputs, and means "silence for
one frame". IIRC, you can turn the feature off,
if you like, forcing the host to always pass
valid buffers.)
Elegant (implementation dependent):
Accept disconnected ports. If the plugin is
a complex beast, chances are it has an internal
list, tree or network of things to do. All you
do is deal with disconnected ports when
contructing that list, tree or network.
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.
Agreed. I think you either use a monophonic patch/instrument, or you
just let the synth make the best use of it's voice reserve.
Note that per-note/voice controls have nothing to do with this -
unless you make the same mistake I did in Audiality; use voice
numbers as note IDs... A voice is one thing, and a note is another. A
note may not have a voice at all times.
OK, I'm starting to come round on this one.
Well, the file dialog would need some extra info, but it does make
sense to use the same file selector (provided by the host) for
everything it could handle, within reasonable limits. (If you want
the preview button to work for Audiality AGW scripts, you need to
wait for me to hack a custom file selector. ;-)
//David Olofson - Programmer, Composer, Open Source Advocate
.- Coming soon from VaporWare Inc...------------------------.
| The Return of Audiality! Real, working software. Really! |
| Real time and off-line synthesis, scripting, MIDI, LGPL...|
`-----------------------------------> (Public Release RSN) -'
.- M A I A -------------------------------------------------.
| The Multimedia Application Integration Architecture |
`----------------------------> http://www.linuxdj.com/maia -'
--- http://olofson.net --- http://www.reologica.se ---
On Wed, Dec 04, 2002 at 11:05:21AM -0800, Tim Hockin
wrote:
[...]
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. 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.