How to specify the size and location of a plot window?

Questions
1

Hi - when I call “plot” it puts the window offscreen so I need to alt tab and then move my mouse to view it. This happens even if I set the “bounds” value. It’s likely an issue with my window manager, but other GUI windows show up fine.

Is there a way I can call plot and specify both the monitor and the window’s absolute location ? It’s a useful tool, but it’s a pain for me to use right now.

2

I had an error when trying it too, using implicit arguments :

{ SinOsc.ar( 440 ) }.plot( "Window", Rect( 200, 600, 500, 1000 ) );

which outputs : ERROR: Message ‘asTarget’ not understood. . The name isn’t correct either.

But forcing the argument symbol works for me :

{ SinOsc.ar( 440 ) }.plot( bounds: Rect( 200, 600, 500, 1000 ) );

But name still doesn’t work :

{ SinOsc.ar( 440 ) }.plot( name: "Window", bounds: Rect( 200, 600, 500, 1000 ) );
3

Not pretty, but you can access the parent (Window) of Plotter:

{ SinOsc.ar( 440 ) }.plot( bounds: Rect( 200, 600, 500, 1000 ) ).parent.name_("Window");
1 Like
4

Have a look here: Function | SuperCollider 3.12.2 Help

Function:plot has no argument for the window title! (Thus, it simply isn’t supported to set the window title directly in this context – you have a mistaken expectation here. You could use Sam’s suggestion to access the Plotter instance’s window and set the name after the fact.)

The first argument is expected to be a duration to plot – a number. If you give a string in a place where a number is expected, errors would be unsurprising.

The keyword argument for bounds does give the Rect to the correct input – that’s fine :+1:

hjh

1 Like
5

:+1:
This is why I dislike having the same name for different methods…

6

Thanks! It looks like the 0,0 coordinate is OFF THE SCREEN for some reason and not the upper left-hand spot of the left most monitor.

That’s really strange, but I can work with it. I’ll likely write a helper function to put the window in my preferred location so I never need to think about this again. tyvm.

7

This is an interesting digression: Is it OK, or not, for different implementations of the same method name to have very different signatures?

In many, many cases, we don’t mind at all. Both of these have the same method selector (ar), but it would be nonsense to require all UGens to have the same arguments.

SinOsc.ar(freq, phase, mul, add)
RLPF.ar(in, freq, rq, mul, add)

In the case of plot, it’s also interesting to me that you have a clear expectation that name should be front and center for all implementations – whereas I think I’ve never used that parameter at all! Based on my usage pattern, I could just as easily propose that name should either not be there at all, or be the last parameter.

The class library itself doesn’t do much to break the tie:

(
~hasName = List.new;
~noName = List.new;

Class.allClasses.do { |class|
	class.methods.do { |method|
		if(method.name == \plot and: {
			method.filenameSymbol.asString.contains("quark").not
		}) {
			if(method.argNames.tryPerform(\at, 1) == \name) {
				~hasName.add(method)
			} {
				~noName.add(method)
			}
		}
	};
};

"Plot methods with 'name' at the front:".postln;
~hasName.do { |method, i|
	method.postln;
};

"\nPlot methods without 'name' at the front:".postln;
~noName.do { |method, i|
	method.postln;
};
""
)

Plot methods with 'name' at the front:
ArrayedCollection:plot
Buffer:plot
Image:plot
Wavetable:plot

Plot methods without 'name' at the front:
BBlockerProgram:plot (this is in sc3-plugins, so let's exclude it)
Bus:plot
BusPlug:plot
Env:plot (nb: This one has 'name', but not at the front :-? )
Function:plot

The survey of main-library plot methods turns up:

  • name as leading parameter: 4
  • No name parameter: 3
  • name but later in the parameter list: 1

Bus, BusPlug and Function plot all extract a short segment of a signal that will continue into the future – so the amount of time to plot is a crucial parameter, so it makes sense to put it up front. (IMO if it were { SinOsc.ar }.plot("SinOsc", 0.01), that would strike me funny – this would force the user either to type a string they don’t care about, or use a keyword argument, just to get to the really critical value = inconvenience.)

I can agree that this is a bit of a rough edge, though it hasn’t been a major annoyance historically. I guess the takeaway, when method arguments aren’t as you expect, might be to check the help or IDE method completion. (In another thread lately, I called into question my own tendency to think, “Something confused me, therefore it’s badly designed” – the second does not always follow from the first.)

hjh