• 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: more AU info and plugins (should be "I need to share data")
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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: Andrew Kimpton <email@hidden>
  • Date: Sat, 21 Jun 2003 14:13:50 -0700

I'm coming to this thread a little late (and perhaps my point/question) is what started this all, but consider the following three pieces of UI information that are all pretty common in an Audio Effect or processing plugin.

VU Meter,
Waveform display (Amplitude over time)
Frequency display

In these cases the data under examination is changing very rapidly (in the DSP part of the plugin), it might be changing as rapidly as the buffer rate, but even if we 'slow' the rate to that of the screen (what's the point of displaying more frequently than screen updates ?) The rate of the data is still 60-85Hz

The quantity of data is also large in the last two cases, probably a 'buffer' or 'array' of between 256 & 512 32bit floating point values (ie 1-2KBytes of Data), there are probably other examples of realtime display with even more data.

These are simple bounded examples, is the decision (feeling) that they are too large and of too high a rate to be handled through Get/Set Property ? If so the UI implementor has no choice (these displays are must have's in many processing plugins) but to 'reach over the wall' and obtain or maintain some other reference, pointer or communications channel with the DSP Component.

If such behaviour is felt likely to break apps in the future, or even break them now then someone (Apple) should set some strong guidelines and provide alternatives or workarounds where appropriate. Or make it clear to the app vendors that they should do nothing in their applications to break the above mechanisms of access.

I've not (yet) seen AudioUnits performing this sort of visual feedback (though I've not looked as hard as I might across the list of units on OSXAudio.com) perhaps the lack of guidelines is why - it certainly gives me pause before rushing to implement a plugin with such UI features.

Andrew 8-)
_______________________________________________
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: more AU info and plugins (should be "I need to share data")
      • From: Bill Stewart <email@hidden>
    • Re: more AU info and plugins (should be "I need to share data")
      • From: Philippe Wicker <email@hidden>
References: 
 >Re: more AU info and plugins (should be "I need to share data") (From: Philippe Wicker <email@hidden>)

  • Prev by Date: Re: more AU info and plugins (should be "I need to share data")
  • Next by Date: Re: more AU info and plugins (should be "I need to share data")
  • Previous by thread: Re: more AU info and plugins (should be "I need to share data")
  • Next by thread: Re: more AU info and plugins (should be "I need to share data")
  • Index(es):
    • Date
    • Thread