Group .set() doesn't work

Questions
1

Hello everyone,
this will be a very stupid question, but I’m a bit tired of not getting it right.
Why if I use the group .set() method to trigger an envelope it doesn’t work, but if I trigger the same envelope for each synth it works?
Here’s a very stupid ex:

~testbus = Bus.audio(s, 1);
~reverb = Bus.audio(s, 1);

SynthDef(\test, {
	var in;
	in = In.ar(~testbus, 1);
	Out.ar(0, in);
}).add;

SynthDef(\rev,{arg t_gate = 0;
	var sig, genEnv;
	sig = In.ar(~reverb);
	sig = GVerb.ar(sig, 100, 2, 0.9, drylevel:0.8);
	sig = Mix.ar(sig);
	genEnv = EnvGen.ar(Env([0,1,1,0],[1,2,1]),t_gate);
	Out.ar(~testbus, sig * genEnv);
}).add;

SynthDef(\sinosc,{arg out = ~ffdbus, t_gate = 0;
	var sig, genEnv;
	sig = SinOsc.ar();
	genEnv = EnvGen.ar(Env([0,1,1,0],[1,2,1]),t_gate);
	Out.ar(~ffdbus, sig * genEnv);
}).add;


// =========== doesn't works
a = Group.new;
Synth(\test);
Synth(\rev, target: a);
Synth(\sinosc, target: a);
a.set(\t_gate, 1);


// =========== works
Synth(\test);
Synth(\rev, [\t_gate ,1]);
Synth(\sinosc, [\t_gate,1]);

Beside that, I think I had it right, but then I changed some lines and now it seems I can’t make it work anymore :sweat_smile:
Thank you so much

2

The trigger works :slight_smile: It’s just the signal flow that is wrong :slight_smile: :slight_smile: :slight_smile: :slight_smile:

  1. we miss ~ffdbus in your example. I guess the idea is to send sines to ~reverb?
  2. synths’ order of execution is wrong. You can check it by printing the node tree (ctrl+t). You can make it work just by setting target:a to your Synth(\test).

Maybe it was just a “typo”, but I’ll explain anyway:

When you create group a, it gets placed after the default group. Then you create your \test synth, and it gets placed in the default group. When you create all other synths, they get placed in the right order, but in group a, which is after the default group.
So, Synth(\test) is not anymore the last of the chain, but actually the first because it’s in the default group which is before your group a. Thus, Synth(\test) doesn’t get any sound from ~testbus, because sound is generated later in the chain.
You can see this situation by printing the node tree (ctrl+t):

NODE TREE Group 0
   1 group
      1009 test // see that test is first, and part of group 1
      1008 group // this is group a
         1011 sinosc // all other synths are here in the right order
         1010 rev

if you do Synth(\test,target:a) instead:

// =========== now it works
a = Group.new;
Synth(\test,target:a);
Synth(\rev, target: a);
Synth(\sinosc, target: a);
a.set(\t_gate, 1);

// ctrl+t prints this
NODE TREE Group 0
   1 group
      1012 group
         1015 sinosc
         1014 rev
         1013 test

Now everything is in the right order, sound flows from sinosc to test, and you also hear triggers working properly :slight_smile:

EXTRA TIP: you can scope ~testbus to see that sound is actually happening there, even with the wrong signal flow. That would be a proof that group triggering works.

~testbus.scope;
a.set(\t_gate,1);
1 Like
3

The explanation is close, but not exactly right.

“When you create group a, it gets placed inside the default group, at the head”… a/ there’s no point of having a default group if synths go outside of it by default and b/ the default addAction is \addToHead.

“Then you create your \test synth, and it gets placed at the head of the default group,” so it’s the new head. The order is now:

  • default group
    • test
    • a

“When you create all other synths, they get placed in group a, which is after ‘test’,” and they are put in at the head, one by one… so the last one to be added (sinosc) is the final head of a and the synths appear in reverse order of creation:

  • default group
    • test
    • a
      • sinosc
      • rev

The reason why is that it’s a common use case to add an effect synth first, and sources for it later – which would not work if the default add action were to add to tail.

Elgiano’s solution will work: by adding \test into the group first, it will end up at the tail. Or, if you want test to come after group a, then it should be Synth(\test, target: a, addAction: \addAfter).

Btw save your synths in variables! Don’t just leave them free-standing. (You’ll thank me later.)

hjh

2 Likes
4

Thank you for your wonderful answers!
However, I need the Synth \test not to be in the Group, if I wanted I know I could add it, but this is just a simple example. I need \test outside the Group and always running.

Yes, I changed the example patch so many times in order to be clearer to post here that I miss it, but that was definetly not the issue :smile:

It’s still an order of Synths error tho, the correct order to instantiate the Synths is the following:

Synth(\test);
a = Group.new;
Synth(\rev, target: a);
Synth(\sinosc, target: a);
a.set(\t_gate, 1);

Silly me, too much work and I was too tired to notice… I had it right in the previous patch!! :sweat_smile:
Thank you for providing more inside and point me to ~testbus.scope!

As I said, this was a very stupid example just to show the “problem” here :slight_smile: I know I can have Synths in variables, but that just not was the case :smiley:
Thank you!

1 Like
5

http://doc.sccode.org/Guides/Order-of-execution.html

All of the addActions are documented here. Briefly, they are “head” and “tail” (put into the target group, at the start or end respectively) and “before” and “after” (just like it says, before/after the target node but not inside).

So if you need \test outside the group and after it, use \addAfter.

hjh

1 Like
6

Of course, addActions can prevent execution order errors in a very useful way :grin: