why is channelIsMuted/Playing readonly? about theamazingaudioengine HOT 5 CLOSED

It's readonly as some channels might not want to make that property changeable via its interface, but might want to implement some other way to affect those properties - like, for instance, a channel that will fade in/out over time when triggered. If the property were required to be readwrite, that would take that opportunity away.

So, to summarise: The property doesn't need to be readwrite to work - it just needs to emit KVO notifications on changes.

from theamazingaudioengine.

I'm not sure I follow you, why would readwrite properties take away the opportunity for a channel to implement a fade in/out over time?

The problem now is that one can't have a generic id<AEAudioPlayable> variable and set channelIsMuted on it, it will result in compilation error (assignment to readonly property). This defeats the purpose of using a protocol that can be implemented by many classes (polymorphism) and needs ugly casting hacks like this:

id<AEAudioPlayable> theChannel;
...
((AnyChannelClassThatHasReadWriteProperty*)theChannel).channelIsMuted = YES;

from theamazingaudioengine.

I designed the protocol so that the implementing class had full control over how the property was accessed - including using a secondary system to actually manipulate those values, rather than letting the 'user' manipulate them directly. So, say you have a public module that, for whatever reason, wants to perform smooth fades instead of hard boundaries when muted/unmuted. You could implement -mute and -unmute methods, or a separate boolean property 'muted', which would emit KVO for channelIsMuted at the appropriate times, leaving the actual channelIsMuted property readonly so the user can't bypass the fades or put the system into an inconsistent state.

I'm doing this in Loopy, for a concrete example; I don't want channelIsMuted to be writable, because it'll bypass the user-assigned fade settings. Instead, I have mute/unmute methods that manipulate this internally.

I suppose I can see that some projects might want external control over the mute state of all channels - I think I'd recommend making a new protocol that inherits from AEAudioPlayable and provides a readwrite channelIsMuted property, for that case.

I'm open to debate on this one - it could be that I've overthought it, although I'm presently happy with the way it is.

from theamazingaudioengine.

But couldn't an implementing class re-declare the channelIsMuted property as read-only if the author don't want the 'user' (developer) to change it? I'm not sure I understand why you need it to be read-only in the protocol.

Also, it might be better for such a fading mute property to also accept direct changes of the muted property. Maybe the developer using the class does want to mute/unmute without fading.

Yes, making a new protocol that inherits from AEAudioPlayable is what I did here, but all the AEAudioPlayable stuff bundled with TAAE does not use that protocol (of course) so I then need to cast it: id<AEAudioPlayable2> foo = (id<AEAudioPlayable2>)someStandardChannelObject;

from theamazingaudioengine.

Technically speaking, they could, but I believe this would violate the principles of a protocol, which defines the expectations one has of a class that implements it.

I guess I don't feel too strongly about it - if you do, I'm okay with accepting a pull request. This is a case of 'whoever cares more, wins' =)

from theamazingaudioengine.