by Barry4679 » Sat Jul 24, 2021 4:45 am
rusty wrote: ↑Fri Jul 23, 2021 1:54 pm
I think that rather than 'half done' one could say that it's designed for a more limited usecase (for users that work with specific other apps, and just have a need to see the data from those apps). Some users may have hundreds of different extended tags (depending on what other apps they're using), and adding all of them to the MM DB would be untenable for performance, UI overload, and cross-media-format tag (in)compatibility reasons.
That said, I could envision a feature that allows for the definition of custom fields mapped to tags on a per-media-format basis. But this would be a tremendous undertaking with limited benefits.
Point taken re the design intent.
Also accept that the feature would have limited benefits, but is hard to see that if would be a
tremendous undertaking.
All it would take is:
- for those Extended tags where the user had registered a link to one of the Customx database columns
- the CustomX column is marked as read-only
- when MM5 updates the track's Extended tag value, it also pushes that value to the corresponding Customx cell in the database
- and when MM5 did an add/rescan of the tracks, it updated the Customx column
- and when MM5 did an Update Tags (Ctrl+S), it pushes CustomX values down to the tracks
Everything else comes for free, because the linked Customx column can be treated like just any other data carrying column,
with existing logic. The Customx column could continue to be stored in the tracks, which would be duplication as pointed out by LowLander, but that is not a material impact.
The difficult thing could be the read-only bit. ... That would be a nice to have feature, but is not essential. People can understand limitations like that. Right now I can rename a track using File Explorer, or tag it outside of MediaMonkey. Those actions cause the MM5 database to get out of sync. People understand that, and deal with it. ... IMO that complication|hassle would be preferable to having some data element that was important enough fir me to maintain in MM, but which remained all but invisible within MM.
I don't have any personal Use Case for this feature, but it would likely be of significant benefit for those who do. Presumably there is a body of such people, otherwise you would have implemented the feature in the 1st place.
[quote=rusty post_id=484719 time=1627066478 user_id=182]
I think that rather than 'half done' one could say that it's designed for a more limited usecase (for users that work with specific other apps, and just have a need to see the data from those apps). Some users may have hundreds of different extended tags (depending on what other apps they're using), and adding all of them to the MM DB would be untenable for performance, UI overload, and cross-media-format tag (in)compatibility reasons.
That said, I could envision a feature that allows for the definition of custom fields mapped to tags on a per-media-format basis. But this would be a tremendous undertaking with limited benefits.
[/quote]
Point taken re the design intent.
Also accept that the feature would have limited benefits, but is hard to see that if would be a [i]tremendous undertaking[/i].
All it would take is:
[list]for those Extended tags where the user had registered a link to one of the Customx database columns
[list]the CustomX column is marked as read-only [/list]
[list]when MM5 updates the track's Extended tag value, it also pushes that value to the corresponding Customx cell in the database[/list]
[list]and when MM5 did an add/rescan of the tracks, it updated the Customx column [/list]
[list]and when MM5 did an Update Tags (Ctrl+S), it pushes CustomX values down to the tracks[/list][/list]
Everything else comes for free, because the linked Customx column can be treated like just any other data carrying column, [i]with existing logic[/i]. The Customx column could continue to be stored in the tracks, which would be duplication as pointed out by LowLander, but that is not a material impact.
The difficult thing could be the read-only bit. ... That would be a nice to have feature, but is not essential. People can understand limitations like that. Right now I can rename a track using File Explorer, or tag it outside of MediaMonkey. Those actions cause the MM5 database to get out of sync. People understand that, and deal with it. ... IMO that complication|hassle would be preferable to having some data element that was important enough fir me to maintain in MM, but which remained all but invisible within MM.
I don't have any personal Use Case for this feature, but it would likely be of significant benefit for those who do. Presumably there is a body of such people, otherwise you would have implemented the feature in the 1st place.