Tdef binding to GUI EZSlider

Questions
1

Hi, everyone! I have a total GUI noob question for you. I’ve created a simple GUI to control a synth and I would like to be able to control the sliders with a Tdef. Is this at all possible? Here is a rough sketch of how I set up the GUI Window.

var numSliders= 4;
var sliders, labels, controls, actions, init;

w = Window.new("test", Rect(128, 64, 400, 500)).front;

labels = ["freq", "amp", "pan", "width"];

controls = ...

actions = ...

init = ...

sliders = numSliders.collect{|i|
	EZSlider.new(w, 390@30, labels[i], controls[labels[i].asSymbol], {|sl| actions[labels[i].asSymbol].(sl.value)}, init[i], true)
		.setColors(sliderBackground: Color.rand);
};

What I want is to be able to do something like this:

Tdef(\groove, {
    loop{
        sliders[0] = rrand(1, 10);
        1.wait;
}
}).play

Obviously in this example, “sliders” are inaccessible due to the scope of the code block’s variables, but even if I used Environment (~) variables, it doesn’t seem to bind. Any suggestions?

2

One methodology is to simplify first. What if, instead of an array of 4 sliders, you have a variable with only one slider?

Switching to an environment variable, currently your Tdef does this: ~mySlider = newValue.

What you wanted to do was: access the GUI object from storage, and change the value of the GUI object (value_ method or its equivalent syntax .value =).

But, without the array reference, it should be more clear to see that what you’re doing is replacing the GUI object in storage.

So it should be ~sliders[0].value = rrand(1, 10).

But really it needs to be defer { ~sliders[0].value = rrand(1, 10) } – a very common error, “Operation cannot be called from this process”.

Last: If you’re using the GUI to transmit data somewhere else with musical timing, that’s not recommended because GUI objects’ timing cannot be guaranteed. Better to have the GUI reflect the state without being the sole traffic control.

hjh

3

Hi, thanks for the response. This helped a bunch. What I’m doing is very much unmusical (in the traditional sense), so I’m not worried about precise timing. I’m mostly concerned with having a hands-off approach to my music and being to monitor what’s happening in real-time.

4

Ok :+1:

I mentioned it because it’s one of my pet topics. A common progression goes like this:

  1. I’ve got a synth and I can change its parameters in code.

  2. Now I want to change parameters using a GUI object, so I’ve got the synth and a GUI object whose action function sets the synth control.

  3. Now I want to change parameters in code and see the change in the GUI, so, couldn’t I just use the GUI object’s action to do both? (But here, the timing compromise becomes apparent.)

A more accurate object model at this point is that there’s a parameter that affects two outputs: audio (via the synth) and visual (GUI). By having an object to handle the parameter value (Model), and attaching the GUI and synth (“Views”) to that, then several problems disappear. SC tutorials, however, often treat parameter values add something incidental and not worth modeling as an object, so that mental leap is harder to make. In any case, you might not need that just yet, but eventually you might.

hjh