So I was looking at some older HIRT patches (for the pre-processing discussion in this thread) and I was struck by the luxury of not having to type hirt. in front of each objects, not to mention the overall legibility of looking at the patch.
Now granted in those you sort of have an ir prefix (irmeasure, iraverage, etc…) but those make sense.
Obviously theres the FrameLib stuff with fl. but denote a domain/sublanguage thing going on, and to a certain extent that’s the same with the bach. stuff, but for FluCoMa it seems needless.
You’ll have to be careful with naming stuff as many are just generic algorithm names, but there’s probably a good solution for each use case (and things like nmfmatch are distinctive enough I would think).
You can always alias them if you want a quick fix.
1 Like
@weefuzzy will whip you. the problem is to be a good citizen for each community, which is the most important part of the project. both communities have prefixes to mark ownership and avoid conflicts with the huge list of things available out there…
My two cents: I would also advise against dropping the prefix. Personally, I’ve ended up with lots of externals with more or less standard names and I never know straight away where they come from (CNMAT externals are usually a good guess…).
Of course there are ways to retrieve such information, but having a prefix is definitely the best way to go, in my opinion.
1 Like
If that’s the case, maybe a shorter prefix. Like fc. or fcm.. Hell, even just f..
Yes, I’m with @danieleghisi on this – a prefix is about the only mechanism we have for preventing collisions / hinting at the provenance of externals.
I’m not at all averse to something shorter though; I think we ended up with fluid on the basis that the shorter options all felt close enough to existing prefixes that it could be a source of frustrating errors (fc. -> fl.; fcm. -> ftm.). But, if people find that preferable to typing out fluid.…
Fair enough.
I would lean towards fcm. since it’s closer to the actual name than fc., f., or fluid. for that matter. But then again I don’t use any ftm. objects.
With the exception of @saguaro I don’t know (m)any folk who still are, esp. in the absence of an official 64-bit build, so maybe fcm. is a possibility.
1 Like
I’m overhauling everything to 64 bit finally so fcm. is OK with me.
fcm is definitely not ok with me, don’t worry 
-
I would not want to offend my very few friends at/from IRCAM with the ftm
-
it saves 2 characters only so in effect irrelevant.
I recommend people to do an alias as @jamesbradbury pointed out - you can even do a new fluid. object alias, imagine how amazing life is simpler - just to confuse people, I recommend to replace the native ‘f’ alias
seriously, just add this to your init folder file (and thanks to @danieleghisi for the code stolen in bach)
max definecommand F patcher inserttextobj fluid.;
max definecommandinstructions patcher F "fluid object or abstraction";
I presume we could do a init file as part of our package for Max. Would that be appreciated? I have mixed feelings with those, as I think there are limited options (52) and therefore I find it intrusive on people’s workflow…
Having to mess around with init files kind of undermines the portability of code though, so if it’s fluid. and that, I would go with no change at all.
fluid. is a weird prefix in general as it does little to communicate the context of the provenance (is it a library for fluid physics? is it related to fluidsynth?, etc…), and is not only long, but awkward to type (the lui part isn’t fast with how it lays out).
But of all the things to pick fights about, I don’t feel so strongly about this one.
1 Like
Hopefully there is more to this forum than picking fights
I like fluid. I would prefer no prefix, but the community is so large now…
I was kindly told that I made a mistake: what I imply is ‘shortcuts’ not aliases. I think @a.harker has a very decent optional init file, and I think that this is probably a good compromise (as well as good knowledge transfer as our powerMaxcoders could implement their own sets of shortcuts)
1 Like
I dont mind fluid.name~.
flucoma.name~ is too long and fcm.name~ is my alias for all the objects now 
I agree with @rodrigo.constanzo that its a bit ambiguous what it does, but so is fl.name~ for FrameLib. There is nothing implicit about the prefixes used anywhere, except they denote the package and we learn what that is.
EDIT:
I will add, I have created a python script which will automatically create the init file for. Seems like a useless reason to script, but as more externals get added to the project you can just re-run the file to reconstruct your init file.
The .py script should go at the top level of your package. AFAIK runs off python 2.7, so will execute on any Mac.
Create_Alias.py.zip (977 Bytes)
I agree with