• 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: AU interface consistency
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AU interface consistency


  • Subject: Re: AU interface consistency
  • From: Urs Heckmann <email@hidden>
  • Date: Mon, 30 Sep 2002 22:21:17 +0200

Am Montag, 30.09.02, um 21:18 Uhr (Europe/Berlin) schrieb email@hidden:

Hi Bill,

Thanks for the reply. I can see that it is standard convention, at least with VST, to have a supplied user interface. I can see the benefits in it when standard controls aren't good enough. But those interested in interface consistency will not want to subject their users to whatever may pop up (however good it may be).

Thanks!

-- John


I second that.

Sure, there are controls in the audio world, that can't be matched by standard user interface widgets. Think of sampleeditors, visual envelope editors with control point handles etc. These need to be implemented individually.

But there are also controls that have become common with identical behaviour, like sliders with two max-min handles (see Emagic plugins), knobs, buttons, radio groups etc., that need to be "skinnable" by custom made graphics. It IMO is absolutely necessary to have standard prototypes that could be passed the needed graphics ressources and sport identical behaviour like command-click == set default value. It would furthermore be nice to have source code of these for peeking implementation details if you for some reason or another need to derive from these, i.e. to add additional behaviour.

A secondary issue is the graphical framework used. Quartz drawing would be comfortable but might cost more performance (If you have heavy cpu load by audio processing, you can't need drop outs by eye candy). Quickdraw might expire somewhen. It would be a desaster if everybody had to do his own benchmarking and adopting the several techniques that exist.

My suggestion would be inventing a site like musicdsp.org, preferredly moderated by CoreAudio group, where example implementations of controls could be posted, commented and evolved. That would be a more open and faster approach than providing such examples via SDK (and even more convenient than that open-source-cvs-hassle).

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: AU interface consistency
      • From: Art Gillespie <email@hidden>
    • Re: AU interface consistency
      • From: email@hidden
  • Prev by Date: kAudioUnitErr_InvalidElement on component open
  • Next by Date: IOAudioControl for arbitrary device data
  • Previous by thread: Re: AU interface consistency
  • Next by thread: Re: AU interface consistency
  • Index(es):
    • Date
    • Thread