PD plotter zoom road test - community interface change question

Dear PD users

I have implemented the alt-click-drag zoom in, with shift-click to zoom out to the previous x-y-range declared.

I can pass on binaries if that helps someone help me test it before I merge.

I have 2 questions:

  • at the moment, the zoom will take absolute values and range, and put the smalles at the bottom left. x-y-range accept any range (80 to 20 for instance, so going ‘backwards’) but that won’t work for a zoom. I have not implemented the zoom to respect this. So if one has the x from 80 to 20 (reverse) and alt-click-drag 60 to 40, it will now be 40 to 60. I know, dumb. I need to improve it to either a) support the negative ranges or b) change the x-y-range message so it is low valule bottom left. I tend to think that (a) is better and more versatile, and I can implement it now, but am I just doing work for nothing?

  • at the moment, if someone enter x-y-range (or alt-click-drag) a range of 0, it defaults back to 1, which again is dumb. Is anyone against me changing it to a very small value - this might be more intuitive. but what would that be? 0.00001? do you folks use smaller range than this?

(even if a Max-user, @balintlaczko’s wisdom would be appreciated here)
(@marco.donnarumma and @JorgeBlank and @rodrigo.constanzo (no gui for you I think so skip if needs be) let me know your opinion please.

ok for the 0 range (question 2) I either throw an error (which is not fun) or set it to FLT_EPSILON (which is 0.0000001192) or both.

Can you pass on a binary for Linux so I can test?


I’ll compile them and post them here later tonight, thanks for your help!

1 Like

Ok slight problem in the train today… very good for tomorrow’s gig… I cannot share my computer screen but the laptop is now all glitchy… I’ll compile tomorrow with an external screen once I’ve solved the gig issue :slight_smile:

Thanks for your patience

No worries, whenever you can. I hope you can fix your problem on time.

fluid.plotter.dll.zip (71.2 KB)

fluid.plotter.pd_linux.zip (15.1 KB)

fluid.plotter.pd_darwin.zip (14.1 KB)

Updated help for all:
fluid.plotter-help.pd (13.6 KB)


I’m very noobish on Pd, but could it be that this pd_darwin is not for arm? It can open the abstraction but not the external. Have no Windows on me at the moment.

I must have forgotten to do it fat. Later this pm I’m back in front of the computer and I can recompile it

1 Like

ok here goes the FAT mac, with FLT_EPSILON for the smallest distance instead of 0.

Let me know how it works. I will be slow to respond in the next 2 weeks though, as I need my bi-annual-digital-detox. I’m still online for a few hours.

fluid.plotter.pd_darwin.zip (22.9 KB)

1 Like

Great, thanks, this one works! I’ll just write down my notes here, and you decided what’s important.

Tiny plotters in help

First of all, the new external breaks the help patch (that I assume was made with the abstraction) because it creates very tiny plotters (as if you omitted size arguments) like this:

But it is all good once I say fluid.plotter 200 200:

It woooorks!

The zooming in/out works, I did manage to bust it once, but I think it might have just be me not realizing the behavior I’ll describe below. Since I understand it, I couldn’t break it.

Zoom out upon Shift+Drag

One behavior that might be a bit confusing (it confused me) is that the zoom out action is not Shift+Click but Shift+Drag. Until I realized that I thought several times that the zoom out somehow didn’t trigger. But once I got it’s actually Shift+Drag, it was all good. If it stays like this, it would be important to leave a comment in the help patch about it.

Edges are not wiped

When you soom in and out a lot, there is an accumulating “dirt” from the parts of points that were historically outside of the canvas.
Somehow it’s possible to draw there but impossible to clear. This can perhaps become a bit distracting with larger datasets. Does not directly affect the functionality, it’s just a small drawing problem.

No zoom rect

This is just a feature request: it would be great to draw a zoom rectangle while selecting the zoom area, similar to the sibling objects in Max.

Your 1st Question

Personally, I think that the reversable range is a bit weird in the first place, and I wouldn’t allow it (lol). For me it confuses the meaning of the range message: a range of area from the grocery store to my apartment should mean the same as the range of area from my apartment to the grocery store (if these are considered top-left and bottom-right corners). To imply a mapping flip by changing the order of points might be a useful hack in some cases, but it is not something I would rely on or expect to have. I would expect flipping the ranges to be a responsibility of another step in the workflow before we plot the data. But I understand if people protest and want the feature, this is just my taste/opinion.

Coincidentally I discovered the same bug now in fluid.jit.plotter, whooooops! Seems like I never thought of testing for this. I’ll fix it in the way you fix yours: either disallow flipped ranges or preserve the flip upon zoom – you decide. (I am anyway in debt of a more painful bugfix regarding plotter position in presentation mode not being decoupled from patching mode, but psst).

Your 2nd Question

I think the clipping to a very small number is totally reasonable here.

Keep up the fantastic work and thanks.


@tremblap that’s awesome!
right now im in production mode for a gig in a few weeks and I’ll wait after that that to test pd on linux. Thank you!

1 Like

thanks for the report!

yes, I gave default values of 10 10 to help users engage with the new modulatable size. Maybe I should put 300 300 by default in the code so it gets transparently replaced? what is your opinion?

it should be shift-click… it is here on MacOS Intel.

yep. I tried to cut the objects that were on the boundaries… that was also true of the previous version (abstraction based) and since the Pd community is trying to move beyond tk I think I’ll park this for now.

and also this… although if I find the courage I might try to implement it.

me too - but hey, i want the toolset to allow divergent usages.

did you check the behaviour on the native fluid.plotter? We should also check in SC and decide and be consistent…

thanks again for your help on all of this.


1 Like

If the abstraction used 300x300 then I think keeping that would be a good idea in the hope of making the change seamless.

Embarrassing, but I don’t know what happened. Now I opened it to double-check and now it is indeed Shift+Click. Unless I’m insane it really was Shift+Drag last time I tried, I spent some time specifically testing for this to verify. (Any Pd bug/behavior I’m unaware of?..) ((or maybe I am insane))

Can’t speak for SC at the moment, but in Max, fluid.plotter produces the same behavior, i.e. range 0.5 0.8 != range 0.8 0.5.

1 Like

thanks for this. So @tedmoore and @weefuzzy (and @jamesbradbury ?) did a better job in SC/Max than us in Jitter and Pd - the range can be inversed and the zoom respects that.

I think we should stick to that. people will have (good) reasons to do backwards scales.

You fix jitter, I fix Pd?

1 Like

Sorry, I was not clear, both fluid.plotter and fluid.jit.plotter respect the backward scaling…

…but when having an inverted range set (like range 1 0) and zooming in, only fluid.plotter preserves the flip, fluid.jit.plotter does not. :frowning:

Just to clear the name of @jamesbradbury. I’ll fix the fluid.jit.plotter to preserve flipped ranges!

that is what I meant when I said they behaved well :slight_smile:

1 Like

Fixed fluid.jit.plotter, PR is coming soon!


and here is the pd version, fat, with a selection rectangle just to thank @balintlaczko :slight_smile:
fluid.plotter.pd_darwin.zip (23.3 KB)

1 Like

:eyes: ill be waiting in the splash zone :slight_smile: