Resizing FreqScope?

It seems that running something like,600) only resizes the main view and not the spectrum view.

Screenshot 2021-08-03 090612

I’m running windows 10, if that’s part of the issue.

Screen shots from different times, but both while running the following code which I think should get frequencies all the way up as in the smaller, default sized scope.

var x, tempo;
x = { arg freq=440;, 0.2, 1/freq, 0.1, mul: 0.2)}.play;
tempo = 60/112;
Task({loop{x.set(\freq, rrand(35,75).midicps); [tempo*0.25, tempo*0.5, tempo*0.75].choose.wait}}).play;

If no one answers make it in an issue on github.

It auto-generates a template for you to plug in, very straightforward.

Sure thing, I set up an account. I’ll wait a few days.

If someone could test on Mac and/or Linux I can include that in the issue.

1 Like

It turns out FreqScope exists as / within a complex ,

…and this is what occurs on my end, when running initial example 'FreqScopeView':

ok, thanks! I don’t understand the source code well enough to point out the line, but it seems like the FreqScopeView isn’t properly resized into the FreqScope.

I’ll submit the issue tomorrow in case someone is willing to test on a non-Windows OS before that.

Yeah, the FreqScope that we have doesn’t resize.
It needs a rewrite :slight_smile:
I have a work-in-progress implementation which - among other things - does resize.
Try at your own risk:

1 Like

I don’t think it’s an issue… I believe it simply to be a behavior attribute determined by it’s current and specific implementation.

Currently, the implementation is grounded in a relationship between FreqScope and FreqScopeView

Ideally, one would abstract this relationship in the class source… and while the scope and it’s visual container may still be separate object ‘under the hood’… this abstraction would be kept private to it’s lowel level implementation, and it’s higher level usage would simply instantiate both of them into one unified FrequencyScope… while maintaining the alignment values of all graphical by defining their resize function to be performed in unison.

And ideally this unique behavior would fall perfectly into place with the Qt graphics library implemented in SC class inheritance tree.

If you take a look at the .sc class files, they are drenched in complexity… it’s very impressive.

I would explore both of these classes a little bit more… maybe revive this thread in the future with an elegant script that resolve the ? in the premise… or show us a few moves… it seems like a challenge and a learning experience…

Or at least, wait for confirmation that this is a bug or should be an issue.

Edit: Hey @MarcinP

FreqScope says:

Window("Freq Analyzer", rect.resizeBy(pad[0] + pad[1] + 4, pad[2] + pad[3] + 4),

false belongs to the resizable parameter.

That is, in the current implementation, it isn’t supposed to be possible to change the window size at all.

In Linux, grabbing the right border and dragging simply moves the window, but does not resize.

So it looks like the Windows window manager does not respect resizable and just allows the user to change the size anyway. (I’m not sure about Mac.)

So that would make this a valid feature request, for a resizable freqscope.

But I think we can’t call it a bug, because our code already tries to prevent the condition. The fact that a component outside of our control doesn’t play nicely with that doesn’t make it our bug.


I was trying to resize with, 800) or similar. My expectation from the help doc was that the width and height argument would change the size of all elements of the window.

The resize: false flag does work on Windows! It can’t be click-and-drag resized. That’s not a concern.

Still not sure if this is a feature request or bug :stuck_out_tongue:

Oddly, this seems to work:

// max partial = 20 kHz
// do not play this loudly
a = {, 200, 0.02).dup }.play;

v = FreqScope(800, 600);  // top partial is shown below 1.75 kHz (?)

v.scope.scope.xZoom = 1;  // seems correct, by eyeballing

// let's try another resolution
v = FreqScope(600, 500);
v.scope.scope.xZoom = 1;  // hm, zoom = 1 seems OK here too

FreqScope includes the line scope.xZoom_((scope.bufSize*0.25) / width); so it may be that this calculation is incorrect. I’m unclear, for instance, why it’s dividing by width – apparently zooming out for larger windows…?

But I tried three different widths (800x600, 600x500, 200x150), and for all of them, xZoom = 1 appeared to be correct. It’s possible that this calculation is vestigial, then – maybe we needed it for the older version of frequency scope, but the Qt version might not need it at all.


ok thanks! I’m not great at reading the source stuff, but that’s the line I wondered about. It looked like it made sense, but I didn’t think to try to set the xZoom manually! duh.

I’m thinking I will file this as a bug then.

I have the related problem that FreqScopeView.scope.xZoom is ignored, if the current view width is below a certain minimum (around 600, I think) but works if the width is larger.


For me, it takes effect at some smaller sizes, but indeed, xZoom is ignored at, say, 200 wide. I didn’t “high-low” binary search it so I don’t know where the limit is.

Interesting bug – I couldn’t find any clipping limits on xZoom in our source code. No idea.


Is there some sort of buffer somewhere, that the scope draws from?

Just a shot in the dark…