OSC messages Viewing

Questions
1

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

Thank you!

2

this might help

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

i had used it myself some time ago

3

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!!!

4

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.

5

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

6

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. ???

7

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
8

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.

9

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

10

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:

11

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…

12

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