23 Dec
2002
23 Dec
'02
8:16 a.m.
On Monday 23 December 2002 09.00, Tim Hockin wrote:
Agreed - I am not convinced we need it.
If you're sync'ing with beats or measures, you're fine. But if you're
doing it the traditional way - sync'ing with a note value - you'll
need to know what one beat actually is. Then you'll need the beat
value as well.
[...]
Yes.
It doesn't really change anything - and the selection of a suitable
queue is still something that belongs in the plugin implementation.
(Most simple plugins will want a single queue, since otherwise,
they'll just have to merge the incoming queues anyway.)
I think treating these "event sets" as event types of their own is
the cleanest approach. It means there are no special cases; they're
just another "control" type, and can be connected as normal Controls.
You could consider them a different Port type as well, but they're
not *that* different from controls. Control Ports have abstract ports
and are accessed through events. Audio Ports have buffer pointers.
Different connection APIs. Do we need a third kind that is physically
identical to the Control API?
Yes indeed.
you can't - we'd need to make METER a
two-control tuple...
...Isn't this really the domain of the user, though? What is it
used for?
Do you actually need the beat value for anything on this level?
Remember that tempo and position are based on the *beat*, rather
than on a fixed note value, so you don't need the beat value to
know what one beat is in terms of musical time. One beat is N
ticks. Yeah. It's
just that HDRs tracking the play cursor and that kind
of stuff is so commonly used that I think it makes sense to have
the timeline work the same way.
OK, So we have some mechanism to indicate STOP/START and another to
indicate position. You can get position changes regardless of
STOP/START state. Does that sound correct? Well, if TEMPO
uses a "special" event, it *cannot* be a normal
float (or whatever) control, and thus it *must* be hinted as a
different type, or the host wouldn't be able to make correct
connections. I've never suggested that these events should be
hinted as normal controls unless they really are 100% compatible
in all respects.
One event set <==> one event data type.
What if, rather than have these as controls, they were explicit
event_ports. The host has to call
"plug->get_event_port(some_indexing_scheme);" anyway, right? What
if it had a list of 'special' queues.
plug->get_event_port(plug, EVPORT_TEMPO);
Then we get all the goodness of events, without the overloading of
the notion of controls. Just another idea. The SEEK
control, OTOH, would provide the information needed to
get it right most of the time, though. (It doesn't work if you
pitch bend
Which is exactly what I dreamed it up for. It's not particularly
useful for CD-quality rendering, but for live play or studio work,
it's SO nice. (I've had a weekend off, as it seems did everyone
else :)
Yeah... I read the ALSA driver writing HOWTO, started working on the
new XAP logo and fixed some stuff in Audiality. Though I still
haven't figured out what that subtle clicking when looping in cubic
interpolation mode is coming from. *Must* be the "first sample"
special case in the mixer, but I can't seem to figure out what's
wrong with it. :-( (BTW, does anyone know if h/w synths and samplers
do this, or if they just let the interpolation delay the output?)
Oh, and then I've been trying to build some MIDI sequencers, but Jazz
requires some ancient version of wxWindows that's no longer available
for download, and midimountain won't build with GTK 1.2.9, and GTK
2.0.x refuses to build with 1.2.9 installed. And MusE can't tell
controls in MIDI files from notes. I just need a simple, basic MIDI
file editor, but it seems like nothing will work without hacking...
seq24 builds just fine BTW, but it doesn't seem to be the right kind
of tool for what I need to do.
Well, that's a weekend off for me! ;-)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---