NRT limitations on M1?

Hello all,

encountering this error on multiple occasions while working in NRT:

nextOSCPacket 0
nextOSCPacket 0
nextOSCPacket 0
nextOSCPacket 0
nextOSCPacket 20
*** ERROR: SynthDef test not found
FAILURE IN SERVER /s_new SynthDef not found
nextOSCPacket 20
nextOSCPacket 20

Increasing memory size etc doesn’t seem to make a difference. Is there any option that would allow NRT to handle this? Since one of NRT’s advantages is handling processes that exceed realtime capacity i’d assume there must be a way…
This happens when SynthDefs exceed a certain size/complexity, but only happens to me since im working on a M1 mac, while they worked flawlessly in an older system before.


For large SynthDefs, it’s safer to write them to disk and load them with d_load. The NRT Guide recommends d_recv but if that isn’t working, d_load is a valid fallback.


hi james,
thanks for the suggestion!
as im working with a Patterns.asScore in NRT may i ask in which parts of the following example
d_load would have to be applied? the synthdefs are then most probably not saved with .store?


fork{{ |index|

	var options =**20).maxNodes_(8192).numAudioBusChannels_(800).numBuffers_(800).numWireBufs_(800);

	var server = Server(\nrt, NetAddr.localAddr, options);

	var dur=20;

	var n=1;

	var sr=48000;

	var array=Array.rand(1400,1,100.0), //increasing array size produces error in SynthDef. using integer arrays larger size possible

	def = ((


			SynthDef(\test, {|amp|





		p= (Pspawner({|sp|


				{	~sbuf=(1.collect{ |index| ( ( type: \allocRead, path: Platform.resourceDir +/+ "sounds/a11wlk01.wav").yield)});


					\instrument, \test,


					\bufA,  Pfunc { |ev| ev[\sbuf]},

					\addAction, \addToTail,




		({|i| p.add([0.0, [\b_alloc, (2*8)+(i),4*sr,1]]);}););

		({|i| p.add([0.0, [\b_alloc, (3*8)+(i),4*sr,1]]);}););

		({|i| p.add([0.0, [\b_alloc, (4*8)+(i),4*sr,1]]);}););

		({|i| p.add([0.0, [\b_alloc, (5*8)+(i),8*sr,1]]);}););




			sampleRate: sr,

			headerFormat: "WAV",

			sampleFormat: "int24",

			options: o,

			duration: dur




i might be mistaken, but substituting .store by .writeDefFile seems to avoid the problem!

ohh… .store should do it.

I guess I’d have to suspect a default-path issue – if sclang is writing to one location and the server is reading from another. Perhaps related to app translocation. I’m not certain that’s the exact issue but I’d probably look there first.