Can we push forward with this approach then and then merge it? I would hate to have all this other juicy stuff being worked on get merged into a release and for this great contribution to not make it. I can lead the PR if you’d like to offload.
2 Likes
It will be merged when I have time to do the PR. it won’t happen before the next release which won’t happen for a certain time anyway - loads of plates in the air and new features.
What can be offloaded when we release is the QC on all CCEs if you want to help 
There are still questions of naming and interfaces that need addressing on GitHub - @balintlaczko has been fantastic and patient with me and my thoroughness - and it is a fantastic PR and addition so don’t worry it’ll be in for sure in the next release.
There has been under the hood (in all wrappers) some significant changes that I hope people are trying on the nightlies. that is what will trigger the next release (when I’m done with SC and it is tested) and this will deffo be part of it (alongside a lot of @MattS6464 work on typo and clarity) but most probably not with the new 6 objects (one of which is in public test now, 5 more coming)…
3 Likes
Wow, that sounds quite busy, I had no idea! No hurry with the PR, I addressed your comments there, @tremblap, mostly just lobbying for keeping refer.
…and while you are busy with other things I plan to add another mousing mode, the “pan-by-dragging” which I often sorely miss with large datasets, having to zoom-jump out and draw a rectangle at almost the same place quite often… It might take some time to figure out an efficient-enough way, so if you guys want to go ahead with merging, that’s fine, I can open another PR for that later.
1 Like
just keep pushing on that PR until I merge - if you add features now I can check them - I am likely to check that later next week
1 Like
Ooh very exciting!
Any info on what they may be?
Also hopefully there’s still some bug fixing going on as I have two coding ideas stalled because they ran into bugs that are impossible or super clunky to code around (1, 2).
the problem is that I even hesitate to say a number imagine if I give a list, and one gets removed…
Bug fixing is not a mega priority if they don’t crash - especially when they are about comfort more than actual bugs, and controversial
In all case, you should see more stuff soon, the team is working hard.
thanks for your enthusiasm
1 Like
Just curious of the category of stuff being added, as even if they aren’t added now, that means they may be added in the future (and/or inspire better coders than me to help chip in).
The couple I listed there aren’t so comfort related. I don’t think fluid.bufampslice~ is working as it should be, and will always miss the first onset when used, and doesn’t work properly when using a different @startframe / @numframes.
The buffer weights in fluid.bufstats~ can be coded around but requires a massive amount of plumbing to do so programmatically, since you need to manually check/resize/move/copy/crop everything going to it.
Added the new panning mode now (using Shift + drag), soon will update the help + reference too
4 Likes
now merged into the main branch - available on the nightlies for the world to test
thanks to @balintlaczko for the amazing work!
2 Likes
ok I spoke too soon - I have to fix the Apple code signature dance on GitHub. I’ll report soon
ok fixed. now online
1 Like
Just ran into some mega speed issues with the native fluid.plotter so definitely see the benefit of using this!
(loaded up something with 50k points and it’s as slow as molasses)
I haven’t kept up with all the updates here and on github but does the jit version of the plotter let you feed in two dicts for class/cluster coloring? (I see some diff colors above, but not sure how/what that is).
Yes, it works with dicts too (the old interface), but I seriously recommend using it with the refer message, because it is much faster. Take a look at the fluid.jit.plotter help from the nightly release, or here for convenience:
If you are curious about the speed gains you can check out the (new) last tab in the help for fluid.plotter:
Note that the right-side refer is at the moment (sadly) just an alias for dict and it is similarly slow. So if you dump in the labelset for 1M points, it is gonna hang… But on the left side, refer actually uses reference and avoids the (costly & slow) dictionary rendering.
1 Like
Hehe yeah. I assumed that it would play nice with such a modest corpus size…
The rest of it looks really good actually.
Since this is for distribution (as in, SP-Tools), I’ll wait until this is pushed to the live version before changing things over. Besides that I’m frozen added new features into the current update and this would enable cool/new things anyways…