Strange Umenu problem - displays loaded files/folders non-alphabetically!
Latest OSX, latest Max, Retina MacBookPro.
I think this may have started recently, but I just noticed it today...
whichever method I use to load a folder into umenu (with autopopulate on), the contents of the umenu are arranged in what appears to be a random order (though it's the same non-alp[habetical ordering every time i reload the umenu).
eg - in the umenu/prefix settings tab of the Help patcher, I drag/drop a folder (which in the Finder contains items sorted alphabetically) into the drop zone bpatcher. The umenu loads as expected, but the items in the menu are arranged (apparently) randomly.
I've tried adding folders containing other folders and containing files of different kinds, and they all end up non-alphabetical.
Following a suggestion on the Facebook group, I also tried [dropfile]->[folder]->[umenu], but ended up with the same results - a non-alphabetical listing of the files.
I've looked at different date orderings, (eg "created","modified") but that's not the order they end up in in the umenu. Not sure what else it could be.
Anyone have any thoughts as to what might be causing this (I assume that the umenu listing should be alphabetically sorted)? And how to fix it?
thanks
David
Hello David.
I'm experiencing the exact same problem as you.
Like you, I was wondering if it could be the latest Max update I made or maybe the MacOS update to High Sierra that was causing this behavior.
Not so long ago, each time a was building a [umenu] by dropping a folder, it was always alphabetically sorted.
Have not seen anyone apart from you on the Cycling forum reporting this behavior.
Does someone has an idea how I could force a [umenu] to sort items alphabetically.
Thanks a lot for any suggestions.
I can report I have the same problem - I'm on a new MBP with high sierra
At least it’s not just me. Maybe best to send a report to cycling...
(Which i’ve just done)
It's a bug in Max with High Sierra,
They've known about it for a long time, but didn't care to fix it promptly or let us know before updating.
Apparently they'll fix it sometime in the next 6 months.
It's been a huge headache for me, and I'm really annoyed that C74 didn't communicate that there are bugs in High Sierra
I was wondering BENJ3737 if you have found a way to bypass the bug?
And thanks for the update about this bug.
Also thanks a lot @DavidEstevens for reporting the bug to Cycling.
yeah you have to collect it into a list with 'zl group', then use 'zl sort' to alphabetize, then use 'zl tier' to split them up again
Wow!
Thanks for your great help BENJ3737!
I really appreciate.
Cheers.
I guess that that will work if you’re using a drop zone to load the files, but not if you’re loadbanging a folder-name message to umenu (which is what I mostly do).
I suppose I could load the files into an invisible umenu, then dump the contents of that through zl sort into a visible umenu, but that’s a bit of a cludge which i’d have to do (and later remove) at multiple places in several software instruments. So hopefully the update fix will arrive very soon.
Sorry ,
I can’t reproduce the bug. I tried with two methods:
1 pressing choose in the umenu inspector to find the folder
2 by using a load mess prefix/ folder path/ connected to the umenu.
In both cases the umenu is alphabetically ordered.
Macbook pro 15” 2016
Mac Osx 10.13.2
Max 7.3.4
Cheers,
ric
I'm puzzled Riccardo Dapelo.
Thanks for your contribution.
Here's the patch I use in which the problem arise.
Macbook Air (11-inch, Early 2014)
Mac Osx 10.13.2
Max 7.3.4
Hi Doug, tested your patch. For me it’s ok, the umenu is alphabetically ordered. The loading method is quite similar to method 2 in my previous post.
Anyway, here’s all fine.
ric
Thanks Ric for your reply.
I cannot understand why it is not working on my side.
I just downloaded Doug's patch, and the umenu is not alphabetically ordered for me, either. High Sierra, early 2015 MacBook Pro, updated Max 7.3.4.
First, an apology for putting an exclamation mark at the end of my original subject - in my email client the active link (in the email notifications from the site) excludes it which means having to manually change the link in the browser to get to this page!
Anyway, here's how I worked around the problem. I'm hoping this is fixed soon, as I don't really want to have to kludge all my existing patches!
Thank you very much David for sharing your work around.
It works fine for me.
Hopefully, this strange behavior will be fixed eventually.
Here's a slimmed-down version for alphabetically sorting a umenu's content, using just 1 umenu. Tested in Max6 on OSX 10.13.
Thanks Torsten - your subpatch works for me beautifully!
Another object I hadn't come across before! Nice.
Thanks for sharing Torsten. Cheers.
i can report the same problem.... Not happy:(
OMG! It turns out that polybuffer~ also loads the files in a folder in a random alphabetical order. And AFAIK there's no way to sort the files once they're loaded - which means that if I load a umenu with the contents of the polybuffer~, that menu will be non-alphabetical.
I _can sort the umenu once it's loaded, but then when I use that menu to set the buffer to refer to in groove~, it will select the wrong sound in polybuffer~ (because you select the relevant buffer by its buffer name, not the name of the loaded file.
it really bothers me that C74 doesn't care to communicate with their customers about this. They knew it was a bug before any of us stumbled upon us, and could have saved us some grief by being upfront about it.
AND they're going to charge us for an upgrade just to get it working again.
I just realised that I'm going to have to do something with around 20 umenus in my workshop and installation patcher, and am trying to decide what the neatest way of fixing it will be (and I'm setting up a workshop on sunday!). It actually looks like it's going to be an unholy mess - there's already a huge amount of "wiring" around all of the umenus, and my attempt at putting Torsten's solution inside a [patcher] object to save space suggests that [getattr ] likes to be connected _directly to the object it's looking at (ie it doesn't like being inside a [p ]. I might be wrong - I'll try again).
@davide - I had some issues my self with the solution proposed, but I got around using this ; i created a subpatch and "hacked" the menu inputs.
The issue is due to High Sierra’s usage of the new APFS file format. We are aware of the issue and will be fixing it in a future update.