• 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: Multitimbral Music Devices - Question and Proposal
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Multitimbral Music Devices - Question and Proposal


  • Subject: Re: Multitimbral Music Devices - Question and Proposal
  • From: Urs Heckmann <email@hidden>
  • Date: Tue, 15 Jul 2003 15:12:51 +0200

Am Dienstag, 15.07.03, um 14:33 Uhr (Europe/Berlin) schrieb Frank Hoffmann:

On Montag, Juli 14, 2003, at 07:11 Uhr, Urs Heckmann wrote:
Hi,

so now I'm in a mess. I don't want to, but I have to. Multitimbral Music Device. Geeeze.

What do you think?
Oh no, please don't. Which reason can there be to do something like this? If a user wants to get another part, he can and should just open another instance of the Audio Unit. Which other reason do you propose?

Frank

He Frank, I don't want this for me. Of course not. I bashed multitimbral, and I meant it.

However. I hate marketing and featurism. But sometimes you have to obey to these rulings to earn money. This sometimes becomes a critical aspect, usually short time after a Keynote Event [Frank and I sat in the first row, during the storm event, hehe].

And who knows what it's good for. - Being able to process all voices of a multitim Music Device within one render call will be rewarded by nice use of cache. It's easier to use Logic along with Live on stage, because you can trigger different sounds without venturesome Environments (well, you could use RAX + RT Player instead). No doubt, despite all hassle, multitim has some pros as well.

And it's not limited to multitim. It's not even limited to homogenous "parts". It could also drive modular Plugin environments. Think of a simplified Numerology running as a plugin inside [your fav host here], where each module is its own AU Element, being fully automatable, regardless of configuration, thus enhancing the functionality of [your fav host here].

I've gone through AU specs and found that Elements idea offers almost everything to do it right. Hence, why not make AU the first platform I know (well, I know only 2 in-depth) that does it right, and without workarounds?

Cheers,

;) Urs
_______________________________________________
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.

  • Follow-Ups:
    • Re: Multitimbral Music Devices - Question and Proposal
      • From: Frank Hoffmann <email@hidden>
References: 
 >Re: Multitimbral Music Devices - Question and Proposal (From: Frank Hoffmann <email@hidden>)

  • Prev by Date: Re: kAudioUnitProperty_FactoryPresets
  • Next by Date: Re: Multitimbral Music Devices - Question and Proposal
  • Previous by thread: Re: Multitimbral Music Devices - Question and Proposal
  • Next by thread: Re: Multitimbral Music Devices - Question and Proposal
  • Index(es):
    • Date
    • Thread