• 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: Scheduling ramp parameters
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Scheduling ramp parameters


  • Subject: Re: Scheduling ramp parameters
  • From: Bjorn Roche <email@hidden>
  • Date: Thu, 13 Jul 2006 16:32:14 -0400 (EDT)

On Thu, 13 Jul 2006, William Stewart wrote:


On 13/07/2006, at 6:52 AM, Bjorn Roche wrote:

On Wed, 12 Jul 2006, William Stewart wrote:


Well, the main difference so far is that you aren't scheduling in the render notification - that is potentially a big difference.

No, as I said below, I have put my scheduling code in the pre-render notification, and still I have the same problem :(. I will look into scheduling "in bulk", and see if that fixes it.


and if there's one thing I've learned about Audio Units it that if you do things differently, some popular audio unit out there will break.

2. I am scheduling the parameters right before my own render call, rather than in the pre-render notification. It has been suggested on this list that the best place to schedule parameters is in the prerender notification, but I don't see how it could be an issue as long as I do it right before the render and from within the same thread.

If the AU does something to clear this state between your call to AudioUnitRender and its call to your pre-render, then this doesn't work of course. You should also bare in mind that the AU's only thread context for doing work is the call the host makes to AudioUnitRender. The suggested guideline is to schedule these activities in the pre-render notification for this reasons.

I put the scheduling code in the pre-render notification. My code isn't any messier, which is nice, but I still have a problem with that one AU.

Have you checked that the parameter itself is a rampable parameter? Does that AU pass the auval test? (It explicitly tests multiple scheduling and ramping)

Yes it validates. This is a world-class convolution reverb plugin (costs around $500) and the parameter I've been playing with presents itself as rampable:


Parameter ID:1148344180
Name: Dry/Wet Mix
Parameter Type: Generic
Values: Minimum = 0.00, Default = 1.00, Maximum = 1.00
Flags: Values Have Strings, Can Ramp, Readable, Writable
  -parameter PASS

Of course, that doesn't mean it isn't broken is some more subtle way.


Apple's stereo mixer has ramp-able parameters:
You could host this AU (just masquerade this as a stereo-stereo effect) - you'll just have to make sure you ramp the volume say on the input scope (not global which is the normal scope for effects)

Do you mean this one: aumx smxr appl - Apple: AUMixer ?

It could take some work to ramp the input as opposed to the global scope, but I'll see what I can do. Thanks for the tip!

	bjorn

-------------
Bjorn Roche
Check out my CD Mastering Software
for Mac OS X : http://www.xowave.com


_______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
References: 
 >Scheduling ramp parameters (From: Bjorn Roche <email@hidden>)
 >Re: Scheduling ramp parameters (From: William Stewart <email@hidden>)
 >Re: Scheduling ramp parameters (From: Bjorn Roche <email@hidden>)
 >Re: Scheduling ramp parameters (From: William Stewart <email@hidden>)

  • Prev by Date: dyld returns 2 when loading AppleHDAHALPlugIn
  • Next by Date: Re: dyld returns 2 when loading AppleHDAHALPlugIn
  • Previous by thread: Re: Scheduling ramp parameters
  • Next by thread: program naming
  • Index(es):
    • Date
    • Thread