4 Dec
2002
4 Dec
'02
4:49 p.m.
On Wednesday 04 December 2002 19.31, Steve Harris wrote:
[...]
Well, yes, but I'm becoming more and more convinced that it only
makes sense in the internals of some
Yes, that's the idea. Getting the best of two worlds: Separate
(possibly human readable) files, as well as useful project management
capabilities.
That's not the whole story. When you hit malloc(), we're talking
*unbounded* latency. That means it may take 10 seconds to instantiate
a plugin. This may be ok if you never instantiate plugins "live", but
if you do (for live gigs, or whatever), you should be nervous about
this.
Maybe it's no big deal; most people can probably just instantiate all
plugins before starting to play. I just don't like assuming that this
will never be an issue, when the solution is as simple as two host
calls that would normally wrap malloc() and free().
Well, then there's no problem. It's just that if we design an API for
simple instruments, I can quarantee that it won't be too long before
we're here again, discussing a third API for "advanced instruments".
(That will probably happen anyway, but we can at least *consider*
covering what we know already.)
Or we just design an event system and strap that onto JACK as well as
a stripped version of LADSPA. :-)
//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 ---
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.
I use "linear pitch". 1.0 would be your MIDI standard middle C. +1.0
would give you the next higher semitone, and +12.0 would give you the
next higher octave.
Being that note IDs have nothing to do with pitch, you can use
whatever scale you like, as well as starting all notes at the same
pitch, or whatever.
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.
Yes, indeed. Most poeple will just want to throw a synth in and start
playing, so hosts must have a way of figuring out some sensible basic
routing. Musicians in general probably don't want to connect ten
"cables" on the screen before they can even get the basic data from
the MIDI controller into the synth. :-)
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.
Yeah - on some platforms. And it's a rather messy hack for something
like that, IMHO.
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.