Re: Not authorised errors
Re: Not authorised errors
- Subject: Re: Not authorised errors
- From: Bill Stewart <email@hidden>
- Date: Wed, 13 Aug 2003 16:00:05 -0700
OK
So, we've added this error code to AUComponent.h:
kAudioUnitErr_Unauthorized = -10847
Please discontinue the usage of -1 for this report, and replace it with
this result code (as this is what host apps will use to check against)
Bill
On Saturday, August 9, 2003, at 07:11 PM, Chris Reed wrote:
>
I had originally disabled saving in Ritmo, but I've turned it back on
>
now (in the 1.0.3 release) for several reasons.
>
>
Most importantly, if a potential customer is working on a song with
>
your demo plug-in it's a major pain to them to not be able to save the
>
song, purchase your plug-in, and re-open the song to continue where
>
they left off. I realise that it's common to disable saving for demo
>
modes, but I think audio plug-ins are a special case where it really
>
works against you (and the user).
>
>
Also, the host may save its own list of parameter values along with
>
the class info dictionary (Logic does this). Unless you have
>
additional data held in the class info, your plug-in state will be
>
restored anyway. And if you do have extra data, state will only
>
partially be restored--just the exported parameter values. This makes
>
it look a lot more like a bug (incomplete saving) than a disabled
>
feature.
>
>
Btw, Ritmo wasn't returning an error but it was returning an empty
>
dictionary. No hosts complained about this until DP.
>
>
Anyway, I think the Unauthorised error is a great idea. And I don't
>
think it is too much to ask to have developers update their code to
>
return the new error instead of -1.
>
>
-chris
>
>
On Saturday, Aug 9, 2003, at 07:46 US/Central, Marc Poirier wrote:
>
>
> On Sat, 9 Aug 2003, Urs Heckmann wrote:
>
>
>
>> Hi everybody,
>
>>
>
>> Why not let the user save settings? - I guess it would be nice for
>
>> demo
>
>> users if they could get back their efforts after registering. Would
>
>> make it even more attractive...
>
>
>
> I don't know who's doing this, but it's not at all uncommon to disable
>
> saving as a way of crippling demo versions.
>
>
>
>> And why return an error code? - Just not setting anything on
>
>> RestoreState does the trick as well.
>
>
>
> Because then you're able to alert the user to the fact that the
>
> settings
>
> weren't saved. Otherwise, it seems like they were saved, but they
>
> weren't, and then the user thinks that there's a bug. Of course, if
>
> you're returning some arbitrary code like -1, then this doesn't work,
>
> which is why Bill is proposing a defined code. Or maybe it could be
>
> enough for demo plugs to put a note in their readmes that save is
>
> disabled? I don't know, no one ever reads readmes, do they...
>
>
>
> Marc
>
> _______________________________________________
>
> 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.
>
>
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
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.