Hello everyone.
I'm very new to pd. Sorry if the following problem it's a stupid one.

I'm receiving in pd some data from a net sniffing app, through a python script.
I'm using udpreceive and unpackOSC for this.

An example of the data strings received is something like

/aaa 1234 345.4657 192.165.2.104 -> 192.165.2.156
/aaa 1234 345.4645 192.165.2.107 -> 192.165.2.156

Using routeOSC /aaa I'm able to filter the first part.

Now I would like to filter the data received only in the form of: 192.165.2.107 -> 192.165.2.156, filtering out all data before the ip addresses, in order to send the new string to Max (set on another machine with udpreceive object).

I'm a really novice to the platform, sorry.

Thank you all for my (maybe) silly question.

@endorak Hi, if you want to send the rest of the messages according to their initial element(s), you can use [route 1234 ...] with as many arguments as you need, or if you just want to trim the first n elements of the incoming lists you could use [list split].

@endorak sort of like this:

Thank you for the help.

After obtained the right part of the message (192.165.2.104 -> 192.165.2.156, for example) I would like to send via udp to another machine with Max.

I've used now an udpreceive object in the same patch in localhost only for test.
When I send that part to the udpsend, udpreceive print "0 0 0"

And if I try to send to udpsend only an Ip, like 192.165.2.104, the console say "udpsend: no method for '192.165.2.104'".

ALso if I try to send via udp the first segment of the original message (1234 345.4567), udpreceive print "210 123".

I don't understand how to send that messages in the right way.

@endorak I'm not sure as I have never used udpsend, but by looking at the help file maybe you could try adding the object [list prepend send] after [list trim] and see if that works.

Not working.
Now it receives some 0s.
No idea where the problem is, because even with simple data (as the firsts 2 numbers of the message) it doesn't work as expected.

@endorak i also never used this, but in this tutorial they use packOSC first before they send the messages: http://write.flossmanuals.net/pure-data/osc/

@endorak This will get the message you want ( 192.168.3.234 -> 192.164.3.466 ) through in OSC format. It's the easiest way and Max should receive it (I hope) in a useful format......maybe.pd
It looks like you are using extended..... let us know if you need a vanilla solution.
David.

You don't need the set message, or the trigger....... but it shows the message you are sending. It can be simpler if you wish..........just this.........

The /aaa is dropped..... it is seen as a definition of the parts that follow as a "list".
So the parts of the list...... "1234" "123.457" etc. can be copied into the message using $1 $2 $3 etc.
You don't want $1 or $2.......... the bits you are looking for are $3 $4 $5.... and those variables are replaced by the data arriving at the message inlet and sent on to the [packOSC] object, with a message header (it could be /woof ... or /whatever. It identifies the message for the osc receiver just like the /aaa did coming from your Python script.
The [packOSC] object sends a string of integers....... that [netsend] understands.

@endorak here it works like this:

thank you all!

@whale-av yes, the OSC is the easiest solution, you're right. In Max I can operate with it without problems. I don't have mrpeach, but I'm using iemnet, that I think is pretty the same. Thank you!

@weightless I think this is the easiest one for my needs. the [symbol] object is the key and I can use also the object [list] to send as much as I want. Thank you!

You are really efficient in helping people!

Hello guys,

I'm having another issues to ask you.

Why the message on the right (in OSC syntax) is not recognized by [list split] and so it isn't sent by the [udpsend] object?

The same message, translated by the [unpackOSC] and routed by the [routeOSC /oscar], printed in the console and then copied and sent through the [list split] object works like a charm.

I'm becoming crazy....

messageTEST.pd

@endorak it seems as what is coming from routeOSC is actually a symbol, not a list, but it lacks the pure data identifier "symbol". A quick fix:

[routeOSC /oscar]
|
[symbol]            <- This adds the identifier
|
[symbol2list]       <- This converts it to a list
|
[list split 2]

symbol2list (short s2l) is from the zexy library.

Thank you @ingox, seems to work now!!