Re: more AU info and plugins (should be "I need to share data")
Re: more AU info and plugins (should be "I need to share data")
- Subject: Re: more AU info and plugins (should be "I need to share data")
- From: Marc Poirier <email@hidden>
- Date: Sun, 22 Jun 2003 10:23:06 -0500 (CDT)
On Sun, 22 Jun 2003, Philippe Wicker wrote:
>
>>> First of all, how would share that pointer?
>
>>
>
>> I do this with Set/GetParameter, private scope and ID, and a little
>
>> kludge (a union) to pass my pointer as a Float32.
>
>
>
> But how? Your two audio components have no awareness of each other.
>
> How does one know anything about the ComponentInstance of the other?
>
>
>
> I just don't think that this example pertains to the topic at hand.
>
> What we are talking about are components that *are* aware of each
>
> other via the Component Manager (like a GUI component with respect to
>
> an audio component).
>
>
Not completely clear on this point. I think of 2 approaches. In both
>
cases the AU are linked with a framework which embeds a sample manager.
>
This sample manager instance is created by the first initialized AU and
>
destroyed by the last cleaned up AU, its address is saved in a global
>
variable and may be accessed via an internal API. From here I may
>
either use Set/GetParameter in the GUI components using the scope as a
>
selector and the element as a parameter, or I can link the GUI to the
>
framework which embeds the sample manager.
Ahhh, okay, well with such a solution, you have the flexibility to do
whatever you want, with or without Component Manager. Sounds like the
best way for this application. But really at this point not very relevant
to the original issues in this thread... ;)
>
> I think we're getting to the point with sample data that loading it
>
> into memory is *not* the most efficient means - think of GigaStudio
>
> for instance and the impact that has had on software based samplers...
>
>
I don't know GigaStudio. I suppose that you're talking of a sample
>
player that do not load the whole samples in memory but instead streams
>
them from a disk? That's a good idea. Just wondering what are the
>
performances (in term of number of voices) compared to the RAM based
>
design.
Giga was the first to design a software sampler that did a combination of
disk streaming and samples in memory. The basic design, as I understand
it, is that you keep the first small snippet of each sample in memory and
then stream the rest from disk. This way, when a voice is instanciated,
Giga can start getting the less responsive disk streaming happening, but
still start the note with optimal performance by beginning it from more
responsive memory. Now this has become pretty standard practice and any
software sampler that's trying to meet today's standards does this, or
offers it as an option.
Marc
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.