Hi,
that's what I read in the UCS NL, today:
S******ner continues to add in some really neat UCS features, especially the UCS Tagger / Searcher tool
(...)
Basehead has also (very reluctantly it would seem) added into some UCS capability into their program as well
Don't know, perhaps there is a secret conspiracy of SM and UCS... ?
@mspisak Well like any major feature there is a demand vs benefit consideration and the UCS project has been around for many years, but gained little traction in that time and there was some vocal demand around here by a few users initially and Steve did speak with a number of content creators and commercial developers in the industry that were not even considering it at the time so there was some reluctance on how needed the feature really was in the wider scope or who would find it useful within the confines of a "US Based" tag language approach.
As I pointed out last year there are quite a few anomalies in the tagging some find difficult to deal with mainly because of the difference in what Americans call something like a Truck or Tractor as apposed to say Australians calling it a Ute or Semi but using the "language file" conversion it is possible to get in and change this tho it breaks standardization.
Gritty points aside, it's a bit of a case of "you don't know how useful something is until you use it" and audio guys are not well known for openly accepting change, we are stubborn people who like to do things a certain way, but with the ability to now easily tag files by DnD and then filter sounds instantly with a click with little effort AND have things all match between libraries is certainly a time saver and far outweighs the small limitations in flexibility. I personally am looking to get my field recorded library updated to make use of it butr will only implement catID from UCS not the rest of the naming convention.
So it's not that we don't want to add things like UCS in, if demand is there its what users want and will be promoted for consideration, but there is a long list of features we are looking to add in the coming year along with a focus on stability and cross platform compatibility with a limited team so the time invested we need to be certain it isn't just for the benefit of a few hard core vocal users.
they are just Butt hurt cuz I said this in a PPP Blog 8)))
"Put it this way… In my 20+ career as a Hollywood Sound Designer, I may have been searched/browsed via [category] a whole 35 times Evah! Haha!"
Plus those two been in bed together since the start and the "rivals" were honestly hoping I wouldn't add support for it cuz it was the latest attempt to try and keep people from ditching their horribly dated software.
Oppppsss Too Bad Guys! we added full UCS Support! 😉
The BH users spoke and wanted it so we made it happen and we didn't skimp on anything along the way cuz that wouldn't be cool to our UCS people. 8)
I am pleased to see the first steps towards using UCS in Basehead, but am disappointed that the perception is that is just the Categories and SubCategories supported, it is so much more than that.
I would like to see parsing of UCS formatted file names into fields on import. By that I mean a file name that follows the UCS
CatID-UserCategory_VendorCategory-FXName_CreatorID_SourceID_UserData
- CatID = Abbreviated Category / Subcategory (as defined by UCS list)
- UserCategory= An optional tail extension of the CatID block that can be used as a user defined category, microphone, perspective etc.
- VendorCategory= An optional head extension to the FXName block usable by vendors to define a library specific category. For example, the specific name of a gun, vehicle, location, etc.
- FXName = Brief Description or Title (under 25 characters preferably)
- CreatorID = Sound Designer, Recordist or Vendor (or abbreviation for them)
- SourceID = Project, Show or Library name (or abbreviation representing it)
- UserData= A User defined space, often used for an ID or Number for guaranteeing that the Filename is 100% unique... or storing things such as microphone type, location, perspective etc.
@SteveT what BH fields would you map these parts of UCS s to ?
- -UserCategory
- _VendorCategory
- -FxName
- _CreatorID
- _SourceID
- _UserData
For me
- CreatorID =manufacturer
- SourceID = library
- VendorCategory and FXName could be combined into a field, but it is not obvious to me which BH field to use. Ideally I would like BH to have an option of UCS fields.
- So all of the above and Category SubCategory CategoryFull, Synonyms and Explanations.
I am using Reaper and have created IXML USER:name=value fields for Metadata. with these names and embedded metadata on Render. Along with several other existing standard fields.BEXT, INFO, etc. I would switch them all to lower case space with _ if bh would prefer.
- USER:UserCategory
- USER:VendorCategory
- USER:FXName
- USER:CreatorID
- USER:SourceID
- USER:UserData
- USER:Category
- USER:SubCategory
- USER:CategoryFull
- USER:Synonyms
- USER:Explanations
I have drunk the nectar of a globally distributed convention that is UCS.
We have 3 new UCS features coming in BETA this weekend in the search and display department, but not these unfortunately.
When we polled user 6 months ago no one seemed to care about anything besides Cat/Subcat.
Pop what you wrote ^^above^^ in the RequestBase and let's see who else wants it also now and if it gets some traction we can slap it in a future version no problem. 😉
