so that is 2 “good” news this morning. Mine is that the OS discrepency of transientslice is here since at least 2 years, so I can go forward and release with the warnings that it is a bug in progress (for the eager reader, see Bug: *transientslice do not give the same results across OSes · Issue #289 · flucoma/flucoma-core · GitHub )
1 Like
So this is still happening.
Haven’t narrowed it down, but it kind of looks like the loading window goes away before actually loading anything. Almost like it’s being cancelled/cleared when I hit “open” instead of actually disappearing in the same way.
I’ll try and isolate it happening (visually), but it happened to me a bunch this morning.
Sorry to hear that - it might be a cycling max9 thing, so try to do something like I did above (a script that instantiate and load and check) and you might catch it?
I can send a debug version to see if we have a crash (the optimiser removes the manual sanity checks in the code)
Nothing is crashing, so don’t know if a debug version will change much.
I’ll try doing stuff in Max8 to see if I can replicate.
that’s the point - a debug version would crash instead of just going about doing the job 
that is the beauty of ‘asserts’ in the code - they crash on purpose when a condition the developer has left there is not met.
Ah right. yeah happy to try that out if that’s useful.
is it only with the dialog? I.e. does it also break if you supply a path / filename to the read message?
in all cases, here is a compile in Debug - if you get funny behaviour this one might crash with useful information.
fluid.libmanipulation.mxo.zip (5.4 MB)
In the middle of a bunch of patching/testing so will try the debug version shortly, but here’s a video of it happening:
I’ve noticed that I mainly get it when dragging files onto the file opener (rather than navigating with it) and critically, when it does not load, when dragging the file onto the window the “open” button is not highlighted, so it somehow selects a “path” but not an actual “item”, then bails.
You can see this when I load the file a second time, the “open” button turns blue and that time it actually works.
I’ve tried recreating this with vanilla objects (e.g. coll) and can’t get it to happen.
Does fluid.dataset~ call for files in a specific way or something?
edit:
As mentioned above, it seems to only happen with the read message followed by dragging a file onto the finder dialog.
ok the release is parked until I’m back online in January. in the meantime, some people might push to nightlies so roadtest that branch please, as usual. I’ll resume the releasing tasks on or around the 5th.
This isn’t signed and none of the terminal messages I found on the c74 article seemed to make it want to work sadly.
do you have codesign available in your terminal?
if so, try
codesign --force --deep -s - <path to externals folder>/fluid.*
I think what happened here is that you’ve got a build that’s been signed locally, but that means it will only run locally. The above will re-sign it so it’s ‘local’ to you.
1 Like
Ok, that works for the signing.
I’ll see if I can get it to happen again today (initial tests don’t seem trigger anything weird).
I guess there’s three possibilities:
- behaves exactly as before, so we’re none the wiser
- behaves as desired instead (i.e. consistently correct), so that whatever is happening is an artefact of build optimisation (which still means it’s my fault, just have to work out why)
- causes a crash because an
assertis triggered in the debug build, in which case – if we’re lucky – looking at the crash report will tell us something.
As far as the interaction with the dialog and search path go, I’ve tried to do it ‘properly’ according to Cycling’s API and examples. But it did give me trouble in the first place, so it’s not impossible that some small change between 8-9 has borked it.
1 Like
Well, the good news is that it still happens with the debug build (and does not crash).
The bad news is that it still happens with the debug build.
Ah well. None the wiser it is. I’ll download 9 and see if I can reproduce
No luck as yet. Might have to send you a special build with the read function peppered with diagnostic messages to see if we can narrow down where it screws up.
1 Like
ok I’m continuing the release process without the fix-in-progress - I hope we can release 1.0.8 now-ish and 1.0.9 soon-ish after (famous last words)