Thank you!

The important thing in all the changes was that we still have an option to have several of them if needed (e.g. for multi-screen setups).

s.meter –> ServerMeter
s.freqscope -> FreqScope
s.scope –> Stethoscope

But we have no ServerTreeView. This would be good.
Otherwise, we have no way to have multiple plotTree for one server if we need it.

@telephon
Thank you for your comments. This is a good idea!
I have added the feature you mentioned and the corresponding help documentation.
Will this be enough? Please let me know if I should revise the added methods and documentation or add more methods.

I think what you want is the behaviour of making a new window like ServerMeter and Stethoscope. See the Comment below.

ServerTreeView.new(s)
ServerTreeView(s)
ServerTreeView(s, Rect(300, 600, 300, 600)) // // arguments: server, bounds
ServerTreeView(s, Rect(300, 600, 300, 600), 1) // arguments: server, bounds, interval

Comment

• ServerMeter and Stethoscope make always a new window:

  ServerMeter.new(s, 4, 2)
  // Evaluating this code twice will display two separate ServerMeter windows.
  

  Stethoscope.new 
  // Evaluating this code twice will display two separate Stethoscope windows.
  

• FreqScope makes only one window:

  FreqScope.new(400, 200, 0, server: s)
  // Evaluating this code twice will display only one FreqScope window.
  

PDFs of rendered help file:

• ServerTreeView _ SuperCollider 3.14.0-dev Help _ with default css.pdf

• ServerTreeView _ SuperCollider 3.14.0-dev Help with custom css with bg.pdf

• ServerTreeView _ SuperCollider 3.14.0-dev Help with custom css without bg.pdf

One more idea, to make multiple views even more useful: instead of passing the argument server, you could call it target. Then, the view could monitor any group in the node tree.

Within the code, you can then call asTarget to get the group, and asTarget.server to get the server.

E.g.

g = Group.new(s);

g.asTarget // the group itself
g.asTarget.server // the server

// server asTarget returns the default group 
s.asTarget
// maybe, for passing a server, we want to get the parent
group = if(target.isKindOf(Server)) { s.defaultGroup.parent } { target.asTarget };

// then you could also write
ServerNodeTree.new; // monitors the default server and the full tree
ServerNodeTree.new(42); // monitors group 42

Ndef(\x, { SinOsc.ar(Rand(200, 800)) * 0.1 });
Ndef(\x).fadeTime = 3;
Tdef(\x, { loop { 1.wait; Ndef(\x).send } }).play;
ServerNodeTree.new(Ndef(\x));

etc.

@telephon
Could you see my comments to the following two comments of yours?

• add 'bounds' arg to .plotTree; make .plotTree a single instance window; add ServerTreeView class #6294 (comment)
• add 'bounds' arg to .plotTree; make .plotTree a single instance window; add ServerTreeView class #6294 (comment)

One more idea, to make multiple views even more useful: instead of passing the argument server, you could call it target. Then, the view could monitor any group in the node tree.

Within the code, you can then call asTarget to get the group, and asTarget.server to get the server.

g = Group.new(s);

g.asTarget // the group itself
g.asTarget.server // the server

// server asTarget returns the default group 
s.asTarget
// maybe, for passing a server, we want to get the parent
group = if(target.isKindOf(Server)) { s.defaultGroup.parent } { target.asTarget };

// then you could also write
ServerNodeTree.new; // monitors the default server and the full tree
ServerNodeTree.new(42); // monitors group 42

Ndef(\x, { SinOsc.ar(Rand(200, 800)) * 0.1 });
Ndef(\x).fadeTime = 3;
Tdef(\x, { loop { 1.wait; Ndef(\x).send } }).play;
ServerNodeTree.new(Ndef(\x));

It is also a great idea. But what do you mean by this?

• Create a new class ServerNodeTree? (I think this may be what you want)
• Implement this idea in this PR?

Thank you for your review!

move the whole class definition to a separate file. "ServerPlusGui" implies that these are extensions only

Please let me know the name of the new file and where it is located. What I think is ServerTreeView.sc in the same folder as ServerPlusGui.sc. Is my thinking correct?

for now, maybe let's drop the feature of passing a parent? This can be added later. Let's just make a new window always and just pass the bounds. The current way of handling the parent is brittle. Or do you see a reason that we need that right now?

Do you mean the parent argument in ServerTreeView.new and ServerTreeView.makeWindow? They come from .plotTreeView:

Following your recommendation, I have moved some parts of .plotTreeView to ServerTreeView.new and ServerTreeView.makeWindow, and the parent argument has also been copied. Can you explain the brittleness of the parent handling? I will make it more robust.

the updater thing is still not correct, this may have been wrong already in the code you copied from the server, I am not sure. The updater is supposed to be a Routine, resulting from the fork, but currently it is just a function. So updateFunc.stop never works! Line 162 should be updater = fork { ... without the extra function brackets.

Um... anyway, `.stop' has worked (and sorry for not taking a closer look at the part nor writing it by myself!):

• The following video is the test with the commit about which you have written your most recent comment:
  https://www.dropbox.com/scl/fi/rmcueze5fyyu7h4v53em8/plotTree-and-ServerTreeView-20240519.mov?rlkey=29rqlocz534jwjh2kyajxdiwf&dl=0
  watch from 0:27

• Line 162 should be updater = fork { ... without the extra function brackets. Then, still the stopping on cmdPeriod needs to be fixed.

  Done! The following video is the test with the commit I uploaded after your most recent comment:
  https://www.dropbox.com/scl/fi/3jt2da0ifo76co9ogw3by/plotTree-and-ServerTreeView-2024-05-20-at-23.06.37.mov?rlkey=y75lra5wgvr3rr3onxf3wusxi&dl=0

Sorry for not coming back to this, I was busy with outher things. Will continue later, if this is ok.

@telephon

Thank you for your review!

move the whole class definition to a separate file. "ServerPlusGui" implies that these are extensions only
Please let me know the name of the new file and where it is located. What I think is ServerTreeView.sc in the same folder as >ServerPlusGui.sc. Is my thinking correct?

for now, maybe let's drop the feature of passing a parent? This can be added later. Let's just make a new window always and just pass the bounds. The current way of handling the parent is brittle. Or do you see a reason that we need that right now?

I have split ServerTreeView from ServerPlusGui.sc and created ServerTreeView.sc in the same folder.

I have moved adding bound argument to plotTree here. It was originally in #6282. I hope this will speed up the review process for both PRs.

This is the current status of this PR:

• Demo video
• Server _ SuperCollider 3.14.0-dev Help.pdf
• ServerTreeView _ SuperCollider 3.14.0-dev Help.pdf

@telephon

The else branch in https://github.com/prko/supercollider/blob/503e541399fcab8c688d67b1ecd2a029d7f6c5fe/SCClassLibrary/Common/GUI/PlusGUI/Control/ServerPlusGUI.sc#L371C4-L373C41 should be left out, perhaps? We don't want to enforce the limit if someone has consciously resized the view?

(from: #6294 (comment))

I have removed that else part within the braces:

{
			bounds = bounds ? this.plotTreeWindow.bounds;
			bounds = bounds.minSize(395@386);  // `395@386` was Size(395, 386) in the previous commit.
			plotTreeWindow.bounds_(bounds).front;
		};

However, the bounds argument now no longer functions correctly:

• Code example:

  s.plotTree; //<------ This works!
  
  s.plotTree(2, Rect(200, 200, 100, 200)); //<------ This does not works!
  
  s.plotTree;  //<------ This does not works!

• The corresponding part in the help documentation (Server.plotTree):
  

Given this (demo video), I am considering the best course of action:

• Should I remove the bounds argument and the corresponding reference to .plotTree in the Server help file?
• Or would it be preferable to restore the removed portion so that the code functions as expected once again?
• Would you like to confirm whether you meant only removing the following part?

  bounds = bounds.minSize(395@386);  // `395@386` was `Size(395, 386)` in the previous commit.

  If the issue is primarily caused by enforcing a minimum size, then removing just this line might be a solution while maintaining functionality....?

I would appreciate your insight on this matter.

Now, bounds argument works again, but it does not change the size even the size is smaller than 395@386.

sorry, it's been a while. I think this would be the right way to do it:

plotTree { |interval=0.5, bounds|
	
	if(plotTreeWindow.isNil) {
		bounds = bounds ?? { Rect(128, 64, 400, 400) };
		bounds = bounds.minSize(395@386);
		plotTreeWindow = Window(name.asString ++ " Node Tree", bounds, scroll:true);
		plotTreeWindow.onClose = { plotTreeWindow = nil };
		this.plotTreeView(interval, plotTreeWindow, { defer { plotTreeWindow.close } });
	} {
		if(bounds.notNil) { 
			bounds = bounds.minSize(395@386);
			plotTreeWindow.bounds_(bounds) 
		};
	};
	
	plotTreeWindow.front;
}

What do you think?

Yes, it is good, Thanks!

The new structure is good. Trying this, @prko I found that we have lost a few things in this new system which should be added in.

The node ids for groups are not visible anymore, and also the nesting structure. Would you like to help by adding it back in?

Thank you for bringing this to my attention, and I sincerely apologise for any inconvenience I caused.

I believe I have identified the issue and resolved it in #6834.

I have also attached a demonstration video for your reference.

Please do let me know if there is anything else that requires further refinement or updates.