by booblers » Mon Jan 16, 2012 5:56 pm
Am I missing something?
As described it looks like for your PUID script Trix you would have to calculate the PUIDs and then, as you say, store them in an object temporarily. No problem.
So you do that. Then you register an event OnTagWrite(). In this event handler you write your new PUIDs that you've calculated and stored in an object.
Now you have to generate the event manually for each file with, eg, a SongData.WriteTags() so that your event handler can fire and actually write the tags.
But in this scenario you can't control what is firing the WriteTags() event. You are firing it manually, sure, but there is nothing to stop the event from firing from other places as well, correct? So when tags are written when the player is finished playing a track you might also fire the event - even if you didn't want to.
This means that any attempt to read/write custom tags has to take into account events coming from other places. In other words - your object now has to keep a list of songs the event will apply to and etc. Is this what you meant by a performance issue?
Making the events available would be good for some scenarios but in other scenarios wouldn't one prefer having the TaggedFile object linked to SongData and available outside of the events?
Then scripts like yours would just look like:
Calculate PUID
SongData.TaggedFile.SetFieldValue( field: string; value: string)
SongData.WriteTags()
Is that not better in many scenarios?
Again, I note that any functionality is better than none. But having the ability to modify tags outside of events seems like makes the most sense to me.
Am I missing something?
As described it looks like for your PUID script Trix you would have to calculate the PUIDs and then, as you say, store them in an object temporarily. No problem.
So you do that. Then you register an event OnTagWrite(). In this event handler you write your new PUIDs that you've calculated and stored in an object.
Now you have to generate the event manually for each file with, eg, a SongData.WriteTags() so that your event handler can fire and actually write the tags.
But in this scenario you can't control what is firing the WriteTags() event. You are firing it manually, sure, but there is nothing to stop the event from firing from other places as well, correct? So when tags are written when the player is finished playing a track you might also fire the event - even if you didn't want to.
This means that any attempt to read/write custom tags has to take into account events coming from other places. In other words - your object now has to keep a list of songs the event will apply to and etc. Is this what you meant by a performance issue?
Making the events available would be good for some scenarios but in other scenarios wouldn't one prefer having the TaggedFile object linked to SongData and available outside of the events?
Then scripts like yours would just look like:
Calculate PUID
SongData.TaggedFile.SetFieldValue( field: string; value: string)
SongData.WriteTags()
Is that not better in many scenarios?
Again, I note that any functionality is better than none. But having the ability to modify tags outside of events seems like makes the most sense to me.