scope3d~

[porres]

reboot of https://github.com/porres/pd-else/issues/2041

• [ ] add 'range' message to set display range (could probably replace 'zoom')
• [x] the dimensions, whatever they are, should match the range, so you can stretch it like it is with [oscope~]
• [ ] escape dollar signs for builtin receive name
• [ ] clip mode

[ben-wes]

rate is fixed.

don't really know how to better explain perspective. but here's a possibly better generated explanation: "Adjusting the perspective setting is like changing the 'depth feel' of the scene. Increasing it makes objects appear more dramatically different in size based on their distance, enhancing the 3D effect. Decreasing it makes the scene look flatter, as if you're moving towards a more 2D appearance."

the intended range behaviour is not yet completely clear to me: would it be a stretched scene by default then if you choose a dimension where width != height? (meaning: the "range" would match the dimensions by default?)

[porres]

range would actually be similar to zoom I guess, but we'd be able to set range for the 3 dimensions

[ben-wes]

should the range then restrict the space for the visuals? i'm not sure i understand ... can't really imagine how this should behave. for 2d, it's obvious - but for a 3d view that you can rotate, i don't see the obvious behaviour. especially for the z-range i wouldn't know what to do.

[porres]

nlines and nsamples dont really work like in scope~

[porres]

i wouldn't know what to do.

not sure either

[ben-wes]

nlines and nsamples dont really work like in scope~

yes. i compared a bit more as well now. nlines is the same, i assume. but nsamples is not really clear to me. and it also looks like the drawing behaviour of scope~ is different in general. without really checking the code, it looks like it's not working with a ring buffer, but instead collects all samples based on the nlines/nsamples for every frame. that's why it's updating so slowly with higher settings like nsamples 256, nlines 256 (it obviously waits for 256*256 = 65536 samples then and updates only every 65536/samplerate seconds). i modestly prefer scope3d~'s behaviour there, haha.

btw, i just noticed that scope~ with these high settings is quite heavily slowing down the gui responsiveness, too ... but the cpu meter is not reflecting this.

[ben-wes]

or maybe for a side by side comparison, these are exaggerated values - better use nsamples 16, nlines 256 or so. :)

[porres]

• better use nsamples 16, nlines 256 or so for what?

[porres]

In scope you have a number of lines and then a number of samples per line. Isn't it clear? How is it for scope3d?

[porres]

So you have a ring buffer, hmmm, nice

[porres]

Scope freezes gui and is very bad, not sure how to improve it

[ben-wes]

In scope you have a number of lines and then a number of samples per line. Isn't it clear? How is it for scope3d?

it's quite exactly this. the only issue is that 'samples per line' to me is not a precise information. the lines are connected. so if a line has 2 samples, the second sample will be the first of the next line? to me, it's more logical to think in points that are sampled, which then get connected with lines. and these points can either be written for all samples or for each nth sample (every second, third, etc.). but it's ok anyway... the current solution will just draw every sample of the incoming signal for 'nsamples 2'.

[ben-wes]

• better use nsamples 16, nlines 256 or so for what?

for comparing behaviors of the two

[porres]

more like '8 256', btw, list input should set both values in scope3d~ as well

[porres]

but default in scope3d~ is 'nsamples 8, nlines 512', but setting it also with '8 256' it doesn't look different... anyway, I'm testing things now and it seems both settings are actually in fact the same... both do the same and look the same now... wtf?

[porres]

compare.pd.zip

[porres]

Hey, only left inlet should take control messages, anyway, updated the first comment with the things still being discussed...

[porres]

I really feel weird about it wasting space like this

[porres]

also, should th grid be like in scope?

[porres]

range should just be regular amplitude range... not range for each dimension!

[ben-wes]

i changed the way that the display is filled in my current branch. it looks ok if you don't rotate:

... but to me, it feels really weird when rotating then:

... if the empty space is the problem, i could also change the behaviour and scale to the max(width, height).

[ben-wes]

@porres can you check whether the behaviour of the rotation parameters seems right to you?

currently, rotationx rotates around the x axis (and imho, in the wrong direction). it might not be logical - but in a way, i feel like a horizontal and vertical rotation (similar to the mouse-dragging) might be more logical?

[porres]

i changed the way that the display is filled in my current branch. it looks ok if you don't rotate

can you send a PR so I can test?

[porres]

I don't know about rotation, is there a discrepancy?

[porres]

I don't know about rotation, is there a discrepancy?

seems rotatex and rotatey must be swapped, right?

[porres]

so, one last thing, how do you feel about a 'range' message instead of zoom?

[ben-wes]

to me it's not obvious how to adapt this. it's also not really logical for oscope~ ... the range setting there is useful for the single-input behavior since then you can set the min/max values that you want to display on the vertical scale. but with 2 inputs, you set min/max for both axis which to me is a bit restrictive.

but of course we can make the behavior for scope3d~ similar and have a range <min> <max> setting that applies to all 3 axis. so range -0.5 0.5 would be similar to the current zoom 2. feels a bit like complicating things - but we can do that change (or keep zoom as an alternative option).

what really bothers me a bit is the fact that with the non-proportional scaling and a range that applies to all axis, you can never get a proportional 3d display in the case of width != height.

[porres]

zoom seems useful to keep, range for each dimension seems overkill

[porres]

range for each dimension seems overkill

but you can go for it I guess,

we'd also have to do it for [scope~]

[ben-wes]

keeping the discussion here since those PR comments will be lost in time ...

if i could redesign scope~ and scope3d~, i'd do the following:

• add a xrange and yrange to scope~ (these names are adapted from slider2d and i think, they fit quite well)
• omit the range option in scope3d~ completely, since it's not really predictable for anyone what it would do
• just keep zoom instead ... this doesn't match the behaviour of scope~ obviously, but we shouldn't try to imitate scope~ - a 3d display is something different after all
• don't do non-proportional scaling in 3d since it creates weird skewed effects and perspectives
• rename rotatex to hrotate since it's now horizontal rotation and not a rotation around the x-axis anymore (thinking of hradio and hslider here concerning the h/v-prefix)
• rename rotatey to vrotate for the same reason
• rotate can then be documented accordingly (first value will change the azimuth and second the elevation ... those would be good names instead of hrotate and vrotate as well btw - but would users understand them better if they're not familiar with spherical coordinates?)
• set nsamples default of scope to 8. imho, it's updating way too slow with the current default and doesn't display things well with higher frequencies
• add clip state to scope3d~ ... that's certainly what i'll try next now! :)

... let me know if that stuff sounds reasonable to you.

EDIT: adding to this: i also assume that more people can understand a framerate in fps rather than in ms intervals

[porres]

hey, let's get back to this! There are still like 3 tasks to go, huh?

[ben-wes]

ah! I remember now. problem is: I'm still not sure I can solve the dollarsign issue since that's a requirement for pdlua. the clip is included, but performs very badly. and range is still not clear to me in a 3d context. I assume that scope~ can't be changed much for compatibility reasons. but did you check my comments above?

[porres]

I'm still not sure I can solve the dollarsign issue since that's a requirement for pdlua.

@timothyschoen , you solved $0 expansion, right?

did you check my comments above?

no :)

I assume that scope~ can't be changed

we can do whatever

so, first things first, $0 expansion, I'm still landing back here and taking care of other stuff, but tomorrow and this weekend I'm busy doing live sountracks, so next week is when I'm back in for good

[ben-wes]

solved $0 expansion, right?

just to quickly add here: what we'd need in this case is that the 'dollargs' only get expanded internally when the object is initialized, but not not when it's saved?

[porres]

So, this doesn't work

in compiled objects, the $0 is saved escaped and not expanded, then it expands at creation

[porres]

I remember @timothyschoen did work this out at one point, but we're not using it in [circle]

[ben-wes]

in compiled objects, the $0 is saved escaped and not expanded, then it expands at creation

yep, that's still missing imho. and I should have mentioned this version to set it via message, too (where the message obviously needs to escape the dollar sign). I only had the creation argument in mind here.