Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add poll-like that to Ugens #6

Open
capital-G opened this issue Jul 4, 2022 · 2 comments · May be fixed by #7
Open

Add poll-like that to Ugens #6

capital-G opened this issue Jul 4, 2022 · 2 comments · May be fixed by #7
Assignees
Labels
enhancement New feature or request

Comments

@capital-G
Copy link
Member

Is it possible to use SinOsc.ar(200).that(....) on any Ugen within a SynthDef? I really enjoy using LFO values in visualisations etc. via That.identity but having this directly available would be great as in such a case I would not have to create multiple sub-busses/Ndefs.

Could this be implemented by wrapping the Ugen with a SendReply which is setup according to the That specification?
A first sketch could look like SinOsc.ar.that(callback: {|r| myVisualOSC.sendMsg("/foo", r)}, trigger: {|in| in>0.5}).

@capital-G capital-G added the enhancement New feature or request label Jul 4, 2022
@capital-G capital-G self-assigned this Jul 4, 2022
@telephon
Copy link
Contributor

telephon commented Jul 5, 2022

Since from one UGen/SynthDef you can make many Units/Synths this is a little tricky from an administrative point of view. But there is an example of how this could work in the Sequencer quark: https://github.com/supercollider-quarks/Sequencer

@capital-G
Copy link
Member Author

capital-G commented Aug 27, 2022

Thanks for the hint, I wrote a first draft today which finally allows to use sclang code/callbacks on the server side in an easy manner :)

uGen.sc

+ UGen {
	that { | callback, trigger |
		var oscAddress = "/that/ugen/%".format(UniqueID.next);

		callback = callback ? {};
		trigger = trigger ? Impulse.kr(10.0);
		SendReply.perform(
			UGen.methodSelectorForRate(trigger.rate),
			trigger, // trig
			oscAddress, // cmdName
			this, // values
		);

		OSCdef(key: oscAddress, func:  { |msg|
			var nodeId, replyId, values;
			#nodeId, replyId ... values = msg[1..];
			callback.(values, nodeId);
		}, path: oscAddress).fix;
	}
}

Usage

Ndefs

(
Ndef(\foo, {
	var sigA = SinOsc.ar(0.1).that({|r, nodeId| ["foo", r, nodeId].postln});
	var sigB = LFSaw.ar(0.1).that({|r, nodeId| ["bar", r, nodeId].postln});
	[sigA, sigB];
}).play;
)

prints

-> Ndef('foo')
[ foo, [ 1.3084325473756e-05 ], 1011 ]
[ bar, [ 4.1666667129903e-06 ], 1011 ]
[ foo, [ 0.062776602804661 ], 1011 ]
[ bar, [ 0.020004166290164 ], 1011 ]
[ foo, [ 0.12529258430004 ], 1011 ]
[ bar, [ 0.040004167705774 ], 1011 ]
[ foo, [ 0.18731451034546 ], 1011 ]
[ bar, [ 0.060004167258739 ], 1011 ]
[ foo, [ 0.24859784543514 ], 1011 ]
[ bar, [ 0.080004170536995 ], 1011 ]

Updating the callback is possible by re-evaluating the Ndef.

SynthDefs

(
SynthDef(\foobar, {|out|
	var sig = (SinOsc.ar(\freq.kr(2.0))).that({|r, n| [n, r].postln});
	sig * EnvGen.kr(Env.perc, doneAction: Done.freeSelf);
	Out.ar(out, sig);
}).add;
)

(
{
	a = Synth(\foobar);
	2.0.wait;
	b = Synth(\foobar);
}.fork;
)

prints

-> a Routine
[ 1017, [ 0.00026179203996435 ] ]
[ 1017, [ 0.95112657546997 ] ]
[ 1017, [ 0.58762991428375 ] ]
[ 1017, [ -0.5879123210907 ] ]
[ 1017, [ -0.95101869106293 ] ]
[ 1017, [ 8.7271851953119e-05 ] ]
[ 1017, [ 0.95107263326645 ] ]
[ 1017, [ 0.58777111768723 ] ]
[ 1017, [ -0.58777111768723 ] ]
[ 1017, [ -0.95107263326645 ] ]
[ 1017, [ -8.7248394265771e-05 ] ]
start #2
[ 1018, [ 0.00026179203996435 ] ]
[ 1018, [ 0.95112657546997 ] ]
[ 1018, [ 0.58762991428375 ] ]
[ 1018, [ -0.5879123210907 ] ]
[ 1018, [ -0.95101869106293 ] ]
[ 1018, [ 8.7271851953119e-05 ] ]
[ 1018, [ 0.95107263326645 ] ]
[ 1018, [ 0.58777111768723 ] ]
[ 1018, [ -0.58777111768723 ] ]
[ 1018, [ -0.95107263326645 ] ]
[ 1018, [ -8.7248394265771e-05 ] ]

Do you think this should be included to the lib?
In this case the updating procedure should be improved as I think it generates lots of abandoned OSCdefs right now on updating.

@capital-G capital-G linked a pull request Aug 27, 2022 that will close this issue
@capital-G capital-G linked a pull request Aug 27, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants