OSC messages Viewing

Is there a way to see excactly what is sent to the server when submitting a patch of code? The OSC message?

Thank you!

this might help

https://swiki.hfbk-hamburg.de/MusicTechnology/710

i had used it myself some time ago

Looks promising, but errored out for me: “Message ‘didBecomeKey’ not understood.”

I was imagining that I could use wireshark to see the messages sent to the server via OSC/UDP on loopback 127.0.0.1 , but doesn’t seem to work that way. There’s gotta be a way!!!

Send one to pure data and get it to write to it’s console, and send the other normally. Maybe the osc formatting is wrong.

You can delete all the Document stuff in that class and keep only the console postln.

Here’s my modified version:

DebugNetAddr : NetAddr {
	var <doc, <>active = true;
	var <>list;
	var funcs, <>dumpAll = true;

	sendRaw { arg rawArray;
		if(active) { this.dump(nil, rawArray) };
		super.sendRaw(rawArray);
	}
	sendMsg { arg ... args;
		if(active) { this.dump(nil, [args]) };
		super.sendMsg(*args);
	}
	sendBundle { arg time ... args;
		if(active) { this.dump(time, args) };
		super.sendBundle(time, *args);
	}
	dump { arg time, args;
		var str, docStr, beats, beatsThisThread;
		if(dumpAll) {
			if(#['/status', '/quit'].includes(args.tryPerform(\at, 0).tryPerform(\at, 0).asSymbol))
			{ ^this };

			// should get the beats outside the { }.defer block
			beats = SystemClock.beats;
			beatsThisThread = thisThread.clock.tryPerform(\beats);
			if(list.notNil) {
				list.add([beats, beatsThisThread, args])
			} {
				defer {
					str = "latency %\tSysClock logical time %\tthisThread's logical time %\n"
					.format(time, beats, beatsThisThread);
					args.do { arg msg;
						str = str ++ Char.tab;
						msg = msg.collect { arg el;
							if(el.isKindOf(RawArray) and: { el.size > 32 })
							{ "data[" + el.size + "]" } { el };
						};
						str = str ++ msg.asCompileString ++ Char.nl;
					};
					str.postln;

					doc !? { doc.selectedString_(str ++ Char.nl) }
				};
			};
		};
		args.do { |msg| funcs.value(msg, time) };
	}
	makeDocument {
		if(thisProcess.platform.ideName == "scqt") {
			try {
				doc = Document(this.asCompileString)
				.onClose_({ doc = nil; active = false });
			} { |err|
				err.reportError;
				doc = nil;
			}
		} {
			doc = nil
		};
	}

	addFunc { |func|
		funcs = funcs.addFunc(func);
	}
	removeFunc { |func|
		funcs.removeFunc(func);
	}
	== { |that|
		^addr == that.addr and: { port == that.port }
	}
}

“scapp” – that is ancient :wink:I could delete even more but I haven’t. EDIT: Updated for SC-IDE. The behavior in the old Cocoa app was to open a document window for the message log at the moment a message got sent out. The new behavior in this version is simpler, I think: If you want a Document, call .makeDocument on your own; if you don’t, then don’t do anything extra, and the messages will just be posted.

hjh

Hmm. I’m not getting that error anymore but maybe I’m missing something. I save that .sc file to the extensions directory then recompile class library.

Then boot server

Then do:

n = DebugNetAddr("127.0.0.1", 57120);
n.active = true;

Then I imagine that anything I do like:

x = Synth(\default);
x.set(\freq, 200);

would show me the OSC message that’s sent to the server, but I just get typical output. ???

OK, so, n is a DebugNetAddr.

But the server only sends messages to its own .addr. It isn’t going to go looking around in random variables for recently-created NetAddr-like things (notably because you could be using a NetAddr instance to communicate with other software – it would be wrong to assume that a new NetAddr is meant for the server).

You have to assign it to the server’s variable.

~saveAddr = s.addr;
~debugAddr = DebugNetAddr("127.0.0.1", 57110);

s.addr = ~debugAddr;  // on

// later...
s.addr = ~saveAddr;  // off

Also note that 57120 is the language port – if you’re using this to debug server messages, then it should be the server port 57110.

Also I’m going to edit the earlier post to update for SC-IDE.

hjh

1 Like

Calling s.dumpOSC(1) will also cause the server to print messages it receives. Arguments 2 and 3 will print it in a different format. IIRC the only thing it doesn’t print is /status messages.

This is true, and can be more convenient. I sometimes use DebugNetAddr anyway when I need to check the timing of outgoing messages – the class prints human-readable beat values while dumpOSC prints raw OSC timestamp values (not intelligible to me anyway).

hjh

Oh you guys are so awesome. I really appreciate it. This is what I was looking for. I do see and understand what you mean now and your example helps me make sense.

Now I have a synthdef playing and it gives me a bunch of these:

latency 0.3	SysClock logical time 102.4204094	thisThread's logical time 100.5097136
[ 9, 'plucking', 1143, 0, 1, 'out', 108, 'amp', 0.4, 'freq', 98.220440090532, 'decay', 1, 'coef', 0.6 ]

The first is the timestanp that the message is RECEIVED by the server, correct? And everything in [] brackets is an array that is the actual data that’s sent to the UGEN graph on the server? So technically, if I was to use any program, and send a message with that exact array over OSC to that port, it should produce the same result?

My end goal is to just understand the client/server better on a lower level. I feel like it could help me visuallize what I want better. I’ve been really focused on syntax of sclang and it gets frusterating (not that I dont like sclang, I do). SO I was going to maybe try something arbitrary that I use on a daily basis, like Powershell, to send an OSC message to scsynth…just to make a sound. :slight_smile:

I will say that for some reason when using the DebugNetAddr I am unable to usde ctrl+period to stop SC. it gives:

ERROR: Message ‘nodeID’ not understood.
RECEIVER:
nil

It works otherwise. Not that anyone should care as this is super old code anyways…

No – see the Server Timing helpfile.

Yes (except the part I scratched out, that’s not right) – see the Server Command Reference helpfile.

Can’t reproduce that here – you must have something else in your setup that’s interfering. (DebugNetAddr doesn’t call nodeID directly anywhere.)

hjh