[linux-audio-dev] XAP Time/Transport - varispeed/shuttle

David Olofson david at olofson.net
Mon Dec 23 07:17:00 UTC 2002


On Monday 23 December 2002 09.00, Tim Hockin wrote:
> > > 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.
>
> 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.


[...]
> > 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?

Yes.


> > 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.

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?


> > 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.

Yes indeed.


> (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 ---



More information about the Linux-audio-dev mailing list