4 Dec
2002
4 Dec
'02
6:07 a.m.
On Wed, Dec 04, 2002 at 01:09:57 -0800, Tim Hockin wrote:
The central part can be very open, eg in URIs you're allowed to assign
URIs from any domain you have control over, so I could label somthing
"http://plugin.org.uk/foo#23". This means that anyone with a website can
assign URIs.
[NB I know it starts with http:, but it /not/ a URL, me and some others
argued it should have a non-resolvable protocol name, but...]
I dont really like using strings for UIDs though. Its too easy to read
semantics into them.
No, its a waste of DSP cycles to check whether something's there or not.
I dont bvelieve the host can draw a nice UI automatically, the best it can
do is a usable UI.
Well, a
guaranteed unique ID is really rather handy when you want to
load up a project on another system and be *sure* that you're using
the right plugins... That's about the only strong motivation I can
think of right now, but it's strong enough for me.
Ok, I see your motivation for this. I hate the idea of 'centrally assigned'
anythings for something as open as this. I'll think more on it.. IMHO, plugins
should not worry about whether or not their outputs are
connected. (In fact, there are reasons why you'd want to always
guarantee that all ports are connected before you let a plugin run.
Open inputs would be connected to a dummy silent output, and open
outputs would be connected to a /dev/null equivalent.)
I disagree with that - this is a waste of DSP cycles processing to be sent
nowhere. Slight change - a plugin only needs to handle
connected inouts. If an inout
is not connected, the plugin can skip it or do whatever it likes.
This is still complexity (if we have a timestamp system), if ther are no
events on the input hte instrument will ingore it anyway.
Should I use a different word than 'port'? is
it too overloaded with
LADSPA?
No, thats exactly a good reason to use the word port (unless youre
describing something thats actually different).
So the host would know that if it connects 1 output,
the name is "mono", and
if it connects 2 ouptuts, the names are "left", "right", etc. Then
it can
connect "left" to "left" on the next plugin automatically. And if
you want
to hook it up to a mono output, the user could be asked, or assumptions can
be made. This has the advantage(?) of not specifying a range of acceptable
configs, but a list. It can have 1, 2, or 6 channels.
I'm not sure I like the idea of varying the behaviour of the system
depending on the number of connections, I have hardware that does this and
it drives me nuts. Especially when patchbays come into it. ITs kind of
forgivable in hardware, as noone wants to buy a sperate mono and stereo
reverb, but in software I dont think theres any such excuse.
I'm back to being in a quandary. Someone convince
me!
Dont bundle up channels! People dont do that in studios for a good reason.
a single channel on a single connections is simple, unambiguous, obvious.
But say you have 2 channels is that L+R, M+S, C+M? how about 8, is it 7.1,
8.1 pre filter, 5.1 in ADAT? What do you do when you have a 5.1 bundle
and you want to send it as 5.1 in ADAT? Does that require a 5.1 rebundler?
I think its much better just to have discrete, mono channels that can be
assigned as needed.
* you can limit polyphony in the host
- when I trigger the 3rd voice on an instrument set for 2-voices, I
can note_off() one of them
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.
Side note: is there a mechanism in jack for me to
pass (for example) a
'START NOW' message or a 'GO BACK 1000 samples' message to a Jack port?
Jack has strinport comtrols that can be use to move the conceptual time of
the jack system, loop, sync etc.
Actually, our focus is slightly different. I'm
FAR less concerned with
sample-accurate control. Small enough buffers make tick-accurate control
viable in my mind. But I could be convinced. It sure is SIMPLER. :)
I thought this too unltil recent, but Benno demonstrated to me that sample
accurate is not significantly harder, and is more efficient in general.
I've contemplated an array of params that are
configurable per-note. Not
everything is. What if we had something like
If the per-voice params are different to he poer-instrument params then
something has gone seriously wrong.
I think INT, FLOAT, and STRING suffice pretty well.
And I MAY be convinced
that INT is not needed. Really, I prefer int (maps well to MIDI). What
kinds of knobs need to be floats?
Seen as plugins internally work in float, all knobs need to be float ;)
I'd assume a violin modeller would have a BOWSPEED
control. The note_on()
would tell it what the eventual pitch would be. The plugin would use
BOWSPEED to model the attack.
voice_on is proably more instrument neutral. Not everything is a note (eg.
my LADSPA gong).
I agree - Bool is a flag on INT. File is a flag on
String.
I dont think you can do anything useful with a generic file string, what
could be host use it for?
With this I agree. One of the reasons I HATE so many
APIs is that they are
grossly over normalized. I don't need a pad_factory object and a pad object
and a plugin_factory object and a parameter object and an
automatable_parameter object and a scope object... I want there to be as
FEW structs/objects as possible.
Good, so ditch int and string and replace them with a generic binary type ;)
That said, one I am considering adding is a struct
oapi_host. This would
have callbacks for things like malloc, free, and mem_failure (the HOST
should decide how to handle memory allocation failures, not the plugin) as
Memeory allocation failures dont really happen in RT systems, you get
massive overruns first.
Yeah, I know.
It's just that I get nervous when something tries to do
"everything", but leaves out the "custom format" fallback for cases
that cannot be forseen. :-)
We're speaking of controls here. In my mind controls have three
characteristics. 1) They have to specify enough information that the host can
draw a nice UI automatically. 2) They are automatable (whether it is sane
or not is different!). 3) They alone compose a preset. What would a
raw_data_block be? I don't really want the plugins writing files.
I'd rather see the host
write a preset file by reading all the control information, or by the host
calling a new char *oapi_serialize() method to store and a new
oapi_deserialize(char *data) method to load.
Agreed.
- Steve