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

Multitimbral Music Devices - Question and Proposal


  • Subject: Multitimbral Music Devices - Question and Proposal
  • From: Urs Heckmann <email@hidden>
  • Date: Mon, 14 Jul 2003 19:11:11 +0200

Hi,

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


Basic assumption: A multitimbral, preset based device consists of n "parts". These parts act like independent twins (or clones or instances) of the same prototype of apparatus, just they reside in a single box. Thus they can receive musical control data (notes etc.), .aupresets and automation data seperately. To address them independently, some sort of channel-mechanism needs to be applied, like good ol' midi channels.


The questions first:

- Is there a chance to determine if a host requests parameter settings / state for saving an aupreset or saving state for a song? (Latter would contain state of all current Instruments, first would save only the instrument that's currently selected in the editor view [Yes, I know this would be a mix of dsp + view, but I do seek pragmatic advice here])

- Is there already any mechanism implemented regarding multichannel parameter changes? (I can't see any relation between parameter stuff and groups)


Proposal:

- Each "part" of a multitimbral MusicDevice is implemented as a seperate Element in the Global Scope of the AU. Thus, parameter changes / automation data can be assigned to the correct part.

- SaveState / RestoreState / NewFactoryPresetSet in AUBase (and wherever other place needed) get overloaded with an additional Element attribute to properly handle persistence in a multitimbral Music Device (would that be a hard task from CoreAudio API point of view?)

- There's still only a single editor View for the whole multitimbral device. A new Property "CurrentEditElement" or the like lets host know what's meant if situation is uncertain otherwise. In cases where the whole gui or anything handles all parts at once (dunno), there's a predefined constant "CurrentEditAllElements" or something. Dunno.

- Summed up: If host saves settings for song, it subsequently requests state of all Elements. If host saves a single aupreset file, it only saves the settings in CurrentEditElement (or a bank-like format with enumerized data-keys on CurrentEditAllElements).

- More input from more sophisticated minds


Maybe I'm confusing things. If my questions/ideas are stupid (because a solution already exists and I was - as usual - too stupid to see it without example code), don't hesitate to tell me.


What do you think?

Thanks,

;) 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>
  • Prev by Date: Possible bug in CAGuard
  • Next by Date: Re: AudioConverter Mono issue
  • Previous by thread: Possible bug in CAGuard
  • Next by thread: Re: Multitimbral Music Devices - Question and Proposal
  • Index(es):
    • Date
    • Thread