Re: Audio Unit Presets and undo
Re: Audio Unit Presets and undo
- Subject: Re: Audio Unit Presets and undo
- From: Bjorn Roche <email@hidden>
- Date: Sat, 9 Jun 2007 11:23:48 -0400
On Jun 8, 2007, at 3:43 PM, Ian Kemmish wrote:
On 7 Jun 2007, at 6:56 pm, Bjorn Roche <email@hidden> wrote:
On Jun 7, 2007, at 6:40 PM, William Stewart wrote:
Have a look at the audio unit event listener - there's a tech note
on this (http://developer.apple.com/audio) - you can use this with
the object API to help to ensure that you don't get notified when
you change parameters and to find out when others do
I'm all set for parameters. My issue is with properties (specifically
parameter list changes and preset changes). Am I missing something?
bjorn
I suspect that in the most general case, this is unsolvable without
more communication between host and AU. For example, my synth has
its own undo mechanisms (including the usual flipping back and
forth to compare a saved version of a voice with the edited
version). Ideally, I would want to be able to tell my host that
any changes coming up are part of an undo operation so that it
could either ignore them completely or handle them specially.
If there were more guarantees about the AU's and host's
responsibilities in the API, then this could perhaps be handled
with Mac OS X's own undo machinery, but as far as I can see there
aren't. My host may not even have an Undo item in its Edit menu.....
So, given that any solution to your problem is (as far as I can
see) going to be a kludge, how about timestamping all events that
you're going to be recording for undo purposes, and coalescing any
that are less than some time interval apart. Since properties are
more intended to be part of the GUI than performance parameters,
the actual size of the interval is probably not too critical - some
fraction of a second perhaps?
Well, I'm glad I'm not the only one! I think I've solved a lot of the
issues that were causing really bad things, so my big worry right now
is when the user selects undo/redo in my app and it fires an event in
response and my app interprets that as a new event because it comes
after the undo operation is complete! This results in a new edit
which may then wipe a great deal of the undo stack. I think you're
right that a timing kludge is the only reasonable way out of this.
Thanks,
bjorn
-----------------------------
Bjorn Roche
XO Wave
Digital Audio Production and Post-Production Software
http://www.xowave.com
http://blog.bjornroche.com
http://myspace.com/xowave
_______________________________________________
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