Open porres opened 5 months ago
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?)
range would actually be similar to zoom I guess, but we'd be able to set range for the 3 dimensions
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.
nlines and nsamples dont really work like in scope~
i wouldn't know what to do.
not sure either
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.
or maybe for a side by side comparison, these are exaggerated values - better use nsamples 16, nlines 256
or so. :)
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?
So you have a ring buffer, hmmm, nice
Scope freezes gui and is very bad, not sure how to improve it
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'.
- better use nsamples 16, nlines 256 or so for what?
for comparing behaviors of the two
more like '8 256', btw, list input should set both values in scope3d~ as well
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?
Hey, only left inlet should take control messages, anyway, updated the first comment with the things still being discussed...
I really feel weird about it wasting space like this
also, should th grid be like in scope?
range should just be regular amplitude range... not range for each dimension!
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).
@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?
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?
I don't know about rotation, is there a discrepancy?
I don't know about rotation, is there a discrepancy?
seems rotatex and rotatey must be swapped, right?
so, one last thing, how do you feel about a 'range' message instead of zoom?
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.
zoom seems useful to keep, range for each dimension seems overkill
range for each dimension seems overkill
but you can go for it I guess,
we'd also have to do it for [scope~]
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:
xrange
and yrange
to scope~
(these names are adapted from slider2d
and i think, they fit quite well)range
option in scope3d~
completely, since it's not really predictable for anyone what it would dozoom
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 allrotatex
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)rotatey
to vrotate
for the same reasonrotate
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?)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 frequenciesclip
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
hey, let's get back to this! There are still like 3 tasks to go, huh?
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?
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
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?
So, this doesn't work
in compiled objects, the $0 is saved escaped and not expanded, then it expands at creation
I remember @timothyschoen did work this out at one point, but we're not using it in [circle]
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.
reboot of https://github.com/porres/pd-else/issues/2041