add currentSettingsAsCompileString

[LFSaw]

I often find myself in the situation that I'd like to save only the specific settings for a NodeProxy.
This method (extracted from NodeProxy:asCode, src) returns the current settings as a compileString, ready to be used further.

I am unsure about the (quite clunky) name, feedback welcome.

Here is a testcase:

(
Ndef(\testMeSettings, {|amp = 0.1, fFreq = 100, fRq = 0.1|
	RLPF.ar(WhiteNoise.ar(amp, AmpComp.kr(fFreq)), fFreq, fRq)!2
})
)

Ndef(\testMeSettings).play
Ndef(\testMeSettings).set(\fFreq, exprand(100, 4000), \fRq, rrand(0.01, 2))


Ndef(\testMeSettings).currentSettingsAsCompileString;
// -> Ndef('testMeSettings').set('fFreq', 551.13632443201, 'fRq', 0.46147141933441);

[telephon]

I wonder if this whole thing of using a = is so practical (in general and also here). We could also:

• return .set(...) for anonymous proxies, or
• pass in a default name that is added

Is it useful to pass in the environment?
In the case where envir is nil, the envir.use is redundant:

envir = envir ? currentEnvironment;
nameStr = envir.use { this.asCompileString };

So if you have a use case, that would be good.

[LFSaw]

Thanks for looking into this!

my usecase is as above.

That said, I am happy to streamline the function, however, I also have to say that I do not fully understand the inner workings of NodeProxy enough to see what the envir is used for in this case, so I do not understand why it might need to be passed in here.
My approach in "writing" this function was merely to provide some functionality (namely exposing the current state of a NodeProxy) for people to use further and independent of the monolithic approach of NodeProxy:asCode.

[LFSaw]

maybe @adcxyz wants to add his ideas?

[adcxyz]

Yes nodeProxy.asCode is too monolithic.

The main thing that is needed across its parts is accessStr,
and duplicating that to a new method seems inelegant.
Those first few lines of NodeProxy.asCode could be a separate method accessStr,

then currentSettingsAsCompileString (or maybe settingsCS ?) could be

+ NodeProxy
	settingsCS { |accessStr| 
		accessStr = accessStr ? this.accessStr;
		this.nodeMap.asCode(accessStr);
	}
// default use 
Ndef(\testMeSettings).settingsCS;
// custom name
x.settingsCS("x");

[LFSaw]

Teaching classes, I again and again stumble over the demand to quickly and programmatically access the current state of an Ndef (NodeProxy) in order to (a) reproduce it e.g. as a preset or (b) us it as a basis for (hand-crafted) derivations.
This was my original intention with this PR.
Since I seem to be the only one stumbling over this, do I miss a better way of doing this?

My original test case (above) is pretty much summing up what I'd love to have...

An intermediate step would be to be able to save presets and recall, manipulate programmatically, or postcs them.

I know that there is ProxyPreset, however, the documentation is based on Tdef and not very intuitive... Also, when I try to use it, I run into all kinds of issues with the preset crossfade that is not behaving the way I'd expect it... (e.g. it resets the crossfade slider and its target values when saving a new preset). It does, however, provide a list of all parameters per preset in a file; maybe the behavior I am describing above could be derived from there?

[telephon]

I am very much in favour of bringing source code and object as close together as possible.

Sorry for having left this lying around. I was unsure if I should really keep this "a = " in the standard library.

We have three cases:

1. free standing NodeProxy
2. NodeProxy in a ProxySpace
3. Ndef (which is also in a ProxySpace)

It would be good to resolve these more clearly. But for now, we can go along the lines of what is there, we can refactor later.

[telephon]

just a few minor things.

[telephon]

Calling it accessString reads better, and we know that it is not a stream.

[telephon]

why not "a ="?

[telephon]

you can drop the semicolon if you like.

[telephon]

settingsAsCompileString would be better. Settings are always current, just like any object.

[adcxyz]

For consistency, I would propose settingsAsCode.
on N/P/Tdefs, asCompileString only posts the access string,
while asCode fully reconstructs the object.

Also for consistency, PatternProxy should have a settingsAsCode method.

And all asCode and settingsAsCode methods should allow passing in an accessString
that overrides the auto-generated (or guessed) ones, since users might know better.
I can try that here, or in a different PR.

2c, adc

[LFSaw]

please try :)

[adcxyz]

will do!
Until this is finalized, you could do:

Ndef(\x, { LFSaw.ar(\freq.kr) }).set(\freq, 123);
Ndef(\x).nodeMap.asCode(Ndef(\x), true); 

[LFSaw]

hello, so wow; I was not aware of ProxyNodeMap:asCode, somehow...

so would

+ NodeProxy {
	settingsAsCode{|namestring, dropOut = true| 
		namestring = namestring ?? {this.asCompileString};
		^this.nodeMap.asCode(namestring, dropOut); 
}

do the trick?