4 Dec
2002
4 Dec
'02
2:36 p.m.
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