• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Mutitimbral - philosophy
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mutitimbral - philosophy


  • Subject: Re: Mutitimbral - philosophy
  • From: Philippe Wicker <email@hidden>
  • Date: Fri, 18 Jul 2003 10:38:11 +0200

On Friday, July 18, 2003, at 08:00 AM, Brian Willoughby wrote:

My rough draft was flawed. It focused too much on voice allocation as a CPU
load factor. If it is possible to describe load in more general terms, then I
think that would be a powerful feature for a host to automatically manage load
between multiple MDs using generic parameters. It seems useful to have a pair
of parameters, one which shows the current value of the "load" factor, and
another which sets a top limit so that the MD will not use too much CPU. Any
ideas on how to do this generically and centrally from the host so that it is
more user friendly than diving into each MD manually?

The difficulty here is the heterogeneity between different MDs. Voices allocation algorithms are not standardized, neither their semantics nor their names (although some basic ideas are likely to be found everywhere). It could be however possible to give a higher role to the host if the API provides some standardized mechanism enabling the host to query and set some voice allocation stuff. For instance, a MD could be requested to return to the host the list of algorithms it implements (their names), and it could be requested to return at the MD scope and/or at part scope (for part selected as a destination) the current used algorithm and associated parameters at MD or part scope. The problem here is "what are the parameters and their types?", this depends on the algorithm and is MD specific. Maybe GetParameterList with dedicated scopes could be used here? Following this approach, the problem to solve is very much like the generic UI for an AU. With the difference that it would be better in that case to group all UIs elements in a unique window to give the user the whole picture.

Any other ideas?

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.

References: 
 >Re: Mutitimbral - philosophy (From: Brian Willoughby <email@hidden>)

  • Prev by Date: Restarting MIDI
  • Next by Date: Re: Hardware control surfaces (was Re: Private Parameters)
  • Previous by thread: Re: Mutitimbral - philosophy
  • Next by thread: Re: Mutitimbral - philosophy
  • Index(es):
    • Date
    • Thread