NdefMixer errors on simple array setup

Questions
1

Judging by the scarcity of mentions here, I’m guessing hardly anyone actually uses NdefMixer, the gui that’s supposed be “Ndef gui central”, but still I didn’t expect it to die so easily:

Ndef(\one, { arg amp = 0.3, freq1 = 333; amp * SinOsc.ar(freq1) });
Ndef(\two, { arg amp = 0.3, freq2 = 777; amp * SinOsc.ar(freq2) });

Ndef(\themix, Ndef(\one))
Ndef(\themix)[1] = Ndef(\two)

If you mix Ndefs like this, the plain Ndef(\themix).edit isn’t very useful, because none of the “sub-ndefs” show up, i.e. you have a Ndef with zero parameters or “routes” shown.

So I thought that rather than opening each of Ndef(\one).edit etc., or put them in a custom view myself, the panelized version of all Ndefs might be useful for something simple as the above, so I tried:

NdefMixer(s)

In that I can click on the “ed” button for one the “sub-ndefs” and it opens up its details on the right, which is nice and promising, but it also throws an error an becomes unresponsive at the same time, meaning that further clicks on other “ed” buttons do absolutely nothing.

-> a NdefMixer
ERROR: Message 'asSpec' not understood.
Perhaps you misspelled 'addSpec', or meant to call 'asSpec' on another receiver?
RECEIVER:
Instance of NodeProxy {    (0000018291AACDB8, gc=0C, fmt=00, flg=00, set=04)

Any ideas how to fix that?

Or can someone suggest a more useable alternative approach that doesn’t involve coding my own gui? And by this I mean still using multiple Ndefs. It did occur to me to pull everything into one Ndef with \mix roles, which with the addition of my own index-based control name mangler makes it possible to have the kitchen sink in one Ndef with no param name conflicts whatsoever, but there are usability limits to that approach. (For instance, Ndef loves to restart the whole array on xset xfades. And the more obvious cognitive one is that one has to deal with slot numbers instead of names if everything goes in one Ndef.) Basically, I’m asking if there’s a useable multi-ndef gui in existence or if I’m missing some basic tweaks in my approach to NdefMixer.

2

This is not producing any errors for me:

(
Ndef.clear;

NdefMixer(s);

Ndef(\one, { arg amp = 0.3, freq1 = 333; amp * SinOsc.ar(freq1) }).play;
Ndef(\two, { arg amp = 0.3, freq2 = 777; amp * SinOsc.ar(freq2) }).play;
)

Clicking “ed” on either Ndef does not throw any errors. Can you post the code that produces this error?

1 Like
3

Yeah, I’m getting errors just with that. I guess some extension problem. I’ll try to disable all extensions and run that again.

Yeah, with zero extensions or quarks, your example does work with no errors on “ed”, and in fact so does my original one.

(
Ndef.clear;
Ndef(\one, { arg amp = 0.3, freq1 = 333; amp * SinOsc.ar(freq1) });
Ndef(\two, { arg amp = 0.3, freq2 = 777; amp * SinOsc.ar(freq2) });

Ndef(\mix, Ndef(\one));
Ndef(\mix)[1] = Ndef(\two);

NdefMixer(s);
)

The question now is which extension was causing this error to pop only on NdefMixer. I suspected it might have been the JITLibExtensions quark since it changes the ParamGui… but it’s not that one. I’ve enabled just the JITLibExtensions quark and it’s still not causing any errors. I’m suspecting my own hacky extensions at this point.

I actually found it. It was a one-line bug in my last extension that touched Symbol. Forgot an .asSymbol conversion… argh.

The problem is a bit obscure in that NdefMixer for some reason continuously, meaning in a loop like 10 times/second tries to convert NodeProxy.nil(localhost, nil) (yes, that string) to a NamedControl! I have no idea why it’s doing that. It seems like a silent bug, until you insert something in the loop. Merely a NdefGui doesn’t try anything like that.

I also suspect how that seemingly crazy stuff happens. NdefMixer is probably switching to a ProxySpace, and in that environment, every environment variable is defined!!! Not to nil as usual, but as a NodeProxy.nil(localhost, nil) object. Duh. I’m guessing that unlike NdefGui which only cares about one Ndef that it was told about, NdefMixer is continuously monitoring ProxySpace for changes or some such. Basically that happens as

	checkUpdate { // ...
		this.proxyspace.use {
// every symbol returns an non-nil key this environment

I’m still not clear why it continuously attempts those conversions to NamedControls though. I think the latter issue is caused because NdefMixer is invoking NdefGui or methods while still in ProxySpace and NdefGui tries to access controls in the space for Ndefs. I’m pretty sure that’s what happens because NdefMixer sometimes flickers when you click “ed” and displays something like this in the space on the right:

image

That odd control only lasts for a few frames though, and then gets deleted from screen.

I got a backtrace where the ControlName (not NamedControl gets created). It’s indeed NdefGui that creates it. It goes like this:

NdefParamGui:getState
NodeProxy:getKeysValues
NodeProxy:controlKeysValues
ProxyNodeMap:controlNames
Dictionary:keysValuesDo
Dictionary:keysValuesArrayDo
< FunctionDef in Method ProxyNodeMap:controlNames >
Meta_ControlName:new

I suppose it’s a valid use since ControlName is not an actual Control, just a “struct” that encapsulates some different data. My Symbol.mangle extension code was getting these calls with the mangler “function” set to NodeProxy.nil(localhost, nil) due to being in proxyspace thanks to NdefMixer.checkUpdate. I guess I need to check for that.