Re: Garageband 3/audio units odd behaviour
Re: Garageband 3/audio units odd behaviour
- Subject: Re: Garageband 3/audio units odd behaviour
- From: Rick Sustek <email@hidden>
- Date: Thu, 8 Feb 2007 15:13:46 -0800
Oh I certainly feel your pain, Dave, with regards to supporting
multiple plugin formats, and trying to keep the code as clean and
common as possible!
It seems like this thread has leapt into the philosophical realm,
regarding the basic question of if the audio processing threads
should be left running, when there really isn't any work to be done.
There seems to be good pros/cons for both approaches, and some of
them depend on the live vs. non-live contexts, and the specific
purposes of certain host apps.
No easy answer, and no clear industry consensus... sighhhh!
I try to keep the basic perspective that it really isn't my CPU to
waste, it belongs to the user, and the user most likely wants to run
more than just my lowly software. The vast majority of the users
would not be happy to see their CPU running at 100%, but neither hear
nor see any activity. So along these lines, in applications where it
makes sense, I like seeing a button that allows the user to stop/
start the whole audio processing machine.
However, in Dave's case (and others) there is a desire to "get some
audio thread time", under the control of the plugin, rather than via
the host. Or, at least a standard way to tell the hosting app to
"give me some thread, man!".
Have fun,
-Rick
Begin forwarded message:
From: "Muon Software Ltd - Dave" <email@hidden>
Date: February 8, 2007 2:27:32 AM PST
To: <email@hidden>
Subject: RE: Garageband 3/audio units odd behaviour
Reply-To: email@hidden
Well, not so much an assumption, but more of a defined role.
The defined role of the plugin, is to hook into an audio stream and
do something useful with it. The fact that a plugin can
exhibit a GUI
at all, is really just fluff, to make it easier to modify the
parameters of the processing.
I can take that onboard for an AU effect. But for an AU instrument or
generator I think there should be something in the spec that takes
into
account the fact that audio could be generated without MIDI having
been sent
to the instrument first by the host.
It is certainly arguable that your feature of providing
"browsing and
previewing" is outside the established role of what an audio plugin
should do, but let's not! ;-)
No, lets not go there....but I am tempted to add that it wasn't a
problem in
Peak when I set up two of your machines on the Bias booth at NAMM to
demonstrate this particular AU for Jason, so at least Peak appears
to share
a similar world view to me :-)
So to get your feature, there is nothing stopping you from launching
a new thread, and opening your own instance of the chosen audio
output device, and playing out some sound. With a few tricks, you
could even run the sound through the processing code of your plugin,
so that the preview would be modified accordingly. What you
would not
be able to do, is to also hear the effect of any plugins that were
down stream from yours, since their processing is associated to the
host's thread, not yours.
There's nothing to stop me, no you are absolutely correct. I could
easily
access the audio device myself and stream my previews to it.
However, many developers don't have the luxury of coding for one
specific
host or even platform. In fact I would say that the vast majority
of us
operating at a commercial level have to make the same code work
well as VST,
AU, RTAS etc. To have to implement such a heavyweight hack just to
get the
AU to work properly in GB3 is a direction I wouldn't want to take
the code
in.
BTW, you mention AU Lab as a host that doesn't exhibit the problem.
But, if you click on the little waving icon, you can stop the audio
processing thread, and indeed see the same problem there!
Of course, and you can do the same thing in Sonar on windows IIRC.
You do
have to worry though about what the benefit of stopping the audio
thread to
the user actually is however...
Kind regards
Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
inc.com
This email sent to email@hidden
_______________________________________________
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