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: Philippe Wicker <email@hidden>
- Date: Sun, 22 Jun 2003 03:04:44 +0200
On Saturday, June 21, 2003, at 11:40 PM, Bill Stewart wrote:
You could also pass a "token" - here's where the 100MBytes of samples
are... 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.
I think this is a bit of a stretch, and I'm not sure what your point
is... EVERY C API uses the same kind of semantic - typically any
passing of large data is done by not **copying** it around, but these
values are passed by reference (ie pointers) - or by tokens (like the
FILE types in stdio for instance)...
The API is OK with me and I'm OK with the API. As often in a
discussion, the original starting point has been lost in the meantime.
The original point was "I need to share data, and for this I want a
common address space". Absolutely no objection against the API, only
questions about what best fits a particular need.
Despite this - the basic design of a separation and encapsulation of
model/view/controllers have been written with these constraints for
how long in how many different languages in how many different
OS's/kernels/etc?
Philippe Wicker
email@hidden
_______________________________________________
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.