Subject: Re: [linux-audio-dev] protux, stereo and interleaving
From: David Olofson (david_AT_gardena.net)
Date: Sun Feb 11 2001 - 14:16:50 EET
On Saturday 10 February 2001 12:38, Iain Sandoe wrote:
> On Sat, Feb 10, 2001, David Olofson wrote:
> > On Friday 09 February 2001 13:36, Iain Sandoe wrote:
[...]
> >> This (for some of my applications) might become more acute (I
> >> have in mind scientific applications where I might have, say, 8
> >> channels all considered and processed as a group).
> >>
> >> not, maybe mainstream requirement - but a couple of euros for
> >> the pot. Iain.
> >
> > Yeah, this is the kind of processing I have in mind - otherwise
> > I'd just stick with the original idea of not supporting
> > interleaved data at all, or in very limited ways. (Converter
> > plugins rather than actual "transparent" support.)
> >
> > However, where's "mainstream" headed?
>
> Please note, though, I'm 100% behind PBD's observations re.
> "studio" channels & so on. There is nothing more frustrating the
> record/edit process than arbitrary grouping of channels forced by
> some non-transparent part of the underlying structure.
>
> de-interleaved (or non-interleaved) is essential for those jobs -
> so I guess (as I think you are saying) both is the real
> requirement.
I agree. The multichannel "ports" I'm talking about are essentially
to be treated as a special optimization, still without being
incompatible with normal, LADSPA style mono ports. That's why I want
the pitch parameter. An example:
------------ -----------------------
| Automation |-->| Master Mixer |---> L
| sequencer | | |---> R
------------ -----------------------
| | | ^ |
| | | 32 ch bus |
| | | ^ |
| | -----------------------
| `-------->| Multi Channel EQ |
V -----------------------
-------- | ^ |
| Some |<----------| ^ |
| mono | | ^ |
| plugin |---------->| ^ |
-------- | ^ |
-------- | 32 ch bus |
| Some |<------| ^ |
| other | | ^ |
| plugin |------>| ^ |
-------- | ^ |
-----------------------
| |
| HDR with EDL |
| |
-----------------------
Here, the Master Mixer and the Multi Channel EQ come from a plugin
package that's optimized for building custom multichannel mixers
using elements (rather than complete stripes), and therefore
"internally" use interleaved buffers on N channels; in this case 32
channels.
Now, with the pitch parameter, the mono plugins on the left can
easily be connected directly to the bus - the host just gives them a
pitch of 32 * sizeof(sample) along with the buffer pointer.
Of course, it would be quite easy to throw in (in this case) two
"extract/insert single channel from/into interleaved buffer" plugins
in between each mono plugin and the bus, or something smarter like
two plugins capable of partial selective (de)interleaving. It would
also be possible to completely avoid the problem, and force the mixer
plugin package to use countless mono channels instead of interleaved
multichannel ports.
I think interleaved data could help performance a bit in this
situation, but I also think the extra interface plugins would cost
more than the pitch parameter. However, the pitch parameter hits
*all* plugins all the time. (Or does it actually, to any significant
extent?)
In short:
1) Mono only,
2) multi + pitch or
3) multi + (de)interleaver plugins?
> An effective/nice way of locking channels together (post record) is
> also very useful.
This isn't directly related to the above, I think, but yes, some sort
of "original relationship data" should be stored somewhere where it
won't get lost while editing.
> For example, I quite often record "live" in the studio and then
> want to relate the recording back to Old-Fashioned Western (tm)
> bars/beats etc. So that other tracks can be added on a sequencer
> approach.
>
> It is essential to lock the tracks exactly because one will be
> fiddling with the "notational timebase" - this affects the start
> time of the audio (in bars/beats) and it must affect _all_ the
> audio the same...
I'm sure I'm following here... Indeed, fiddling with the "time track"
as they call it in some apps, should keep audio in the right places
musically, but I'm having some trouble seeing how you could make sure
that is always the case when changing the tempo. (Some audio/MIDI
programs do it by time stretching/compressing the audio to fit the
MIDI timing exactly, but that has a tendency of either severely
degrading the quality, or take ages to perform - usually both!)
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------> http://www.linuxaudiodev.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`--------------------------------------> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Sun Feb 11 2001 - 16:34:25 EET