Hi guys, so I manage to get rid of the "output snd_pcm_delay failed" error by running pd with Jack. It doesn't do anything for the CPU, still got my four cores running at 50%. I did some profiling on groovebox 2 and my first my frist version of the "fork" I was working on and I notcied that I didn't get any vfprintf calls, so the problem doesn't come from neither martin Birkmann patch or my first tweaks on it, but only from the implementation of pd~. Since the vfprintf isn't due to the alsa error message, it must be something else. It's not the synth of the patch or the mixer and fx that works well somewhere else. Then the only thing that are remains in this audio processing patch is the following : an object that permits me to get all the value that come from my GUI patch via netsend/netreceive and another object which take the value received via netsend to then them with a message to the pd~ object.

My netsend/netreceive object seems to have worked fine until now I didn't notice any CPU issues when using it. The other object maybe the source of the problem, thoough it's strange because the value that I send from the GUI are sent properly to the audio processing patch. So I'don't know what to do. Should I pack an archive of my code and put it here so you could have a better idea of whats going on ?

@toddak [netsend] and [netreceive] still work pretty much as they did in Extended, just the parameters have changed in Vanilla I think for udp tcp etc. formatting.
OSC messaging is a bit more difficult in Vanilla especialy because of a problem sending a float as part of the message header. The float arrives as a symbol and so cannot be routed simply.
Here are [netsend] and [netreceive] tests and an OSC patch that solves the float problem.......
It seems you are not using the OSC though.
Make sure the send is to a fixed IP address for the other computer, and use [list prepend] instead of [prepend] for Vanilla.
vanilla osc.zip
Upload the patch if you are still having problems.
David.

Can OSC-formatted message be send via TCP/IP in MobMuPlat ?

I'm encountering reliability issues with OSC messages in MobMuPlat. They works well for dynamic values, but sometimes a command to set a static parameter gets missed that is critical to my use case.

In the PdWrapper patch that simulates the internal of the mobile version on the desktop, this should be rather easy to do: add parameter 1 to the netreceive and netsend objects.
(as e.g. here: http://write.flossmanuals.net/pure-data/send-and-receive/ )

Can netreceive and netsend be changed to use TCP/IP in the mobile version of MobMuPlat as well?

( This was asked in the puredata forum once, but I can't find a reply to it: )
https://lists.puredata.info/pipermail/pd-list/2017-10/120631.html

Thanks, Frank

@Jona Good to see it working!
Yes, generally netsends and netreceives have matched ports (one port only).
For comms with verification of receipt (tcp) it is vital.
But for udp you can "broadcast"...... much like streaming internet radio.

So you could have all your [netreceive] objects as [netreceive 3001 1] and broadcast to your router the [netsend]
So, on my network the primary router address is 192.168.1.1
That is the address that will serve up its web-page. Often referred to as the "gateway".
Its broadcast address will be 192.168.1.255
255 is reserved specifically for this purpose so......
[connect 192.168.1.255 3001( will set [netsend 3001 1] to broadcast to any/all copies of [netreceive] listening on port 3001 on any computer on the local network.
If that is what you want?
David.

@bamboomusic As I understand PdDroidParty it is for running a Pd patch on an android device.
You will need it to send OSC messages over the network to control a patch on your computer that deals with the midi.
Look to use [netsend -u -b] and [oscformat] on the Android patch (if they are included in the list of vanilla objects that will work with PdDroidParty)....... and [netreceive -u -b] and [oscparse] on your computer.
Then use the incoming OSC messages to control the midi objects on your computer.
You can just use [netsend] and [netreceive] and work with lists.... but OSC messages are more human readable.
The really simple solution is to buy a copy of the "TouchOSC" app for Android. Your Android interface will be much prettier and easier to build. It can send OSC and midi messages and has some ready-built templates for many DAWs. Once purchased (I think it is about $5-$6) you can put it on all your Android devices.......... https://hexler.net/software/touchosc-android
David.

don't know where that coma is coming from as it is not part of the original message.

here is a simplified version. oscform.pd

i am at this point using packOSC with netsend
and comparing it to oscformat with netsend

and trying to figure out how the message is being formatted differently by those two objects.

The actual patch is sending tuio messages to another source. (part of which you helped me with a while ago.)

but i am also using netreceive and oscparse to try to gauge what the differences are.

for some reason when sending with oscformat the message that arrives in oscparse keeps the / slashes but not when sent from packOSC.

netreceive-oscparse from packOSC-netsend
print: list tuio 2Dcur source localhost
print: list tuio 2Dcur alive 2
print: list tuio 2Dcur set 3 0.145 0.227 -5 -5 -16.8504
print: list tuio 2Dcur fseq 6

netreceive-oscparse from oscformat-netsend
print: list /tuio/2Dcur source localhost
print: list /tuio/2Dcur alive 2
print: list /tuio/2Dcur set 3 0.745 0.807 -5 -5 -16.8504
print: list /tuio/2Dcur fseq 6

Hi,
i have some problems with the netsend~ and netreceive~ objects from Remu. I'm using pd extended 0.43.4

I build two patches (client and server) for voice communication with several abstraction using dollar signs etc..
The first patch (client) records audio on 8 channels with the [adc~] object after pushing a Press-to-talk button (PTT) and sends this signal with [netsend~] to the second patch (server). This second patch checks some conditions and sends the signal to other clients. The client receives the signal and sends it to a [dac~] object.
In the beginning of this project I connected everytime I pressed the PTT and disconnected when I released the PTT. Pressing the PTT and connecting caused often errors from [netsend~]:

• (Tcl) Invalid Command Name " " while executing; with different commands inside the "". Sometimes it was a part of the IP-Adress, the port, parts of other words like "ted" from connected or something different
• Sometimes I got the Tcl error: bad option " itemconpdtk_text_set": must be addtag,bbox,bind,canvasx,canvasy,cget,..... while executing

The results of this errors where a frozen GUI (number boxes and Sliders didn't change) or pd crashed.

• (Tcl) missing close brace while executing. After this errror I had to kill Pd because nothing worked anymore...

I couldn't find the reason for the errors so I changed the patches. Now [netsend~] connects directly when the patch opens. But sometimes the "invalid command name" error appears anyway and the GUI freezes, so I had to restart the patch.

Another problem is an error from the [netreceive~] object while sending an audio signal over the network:

• recv data: message too long (10040) or recv tag: message too long (10040)
  it is independent of the chosen format or blocksize. Everytime it happens the sound interrupts. It's not that bad, but sometimes there comes a block of errors and the sound interrupts for a hole second or more, which is disturbing.

So I hope someone understands what i wrote and maybe someone had similar problems.

Tanks for helping.

@Greener said:

Hello @offtandiscord

I made this for my RP3 and never had this problem, maybe try looking at it or using it, it uses 5 GPIOS and send bangs, but you can make it to send a complex message

Netsend-Example.py
Netreceive-example.pd

Hope it helps :D
Greener

How would you make it for receiving messages from puredata in python? I use the same function as you to send messages from python to puredata, but I'm having issues for making the pdreceive function in python.

Hello @offtandiscord

I made this for my RP3 and never had this problem, maybe try looking at it or using it, it uses 5 GPIOS and send bangs, but you can make it to send a complex message

Netsend-Example.py
Netreceive-example.pd

Hope it helps :D
Greener

@pooopsi Just addressing the questions that I can reply to without delving deep into the patch........
Anything can be put into a sub-patch without problems..... it is just like having windows between rooms, all in the same house. Abstractions are like having a stock of jam jars in the larder, but the arguments are labels that say....... this one is raspberry flavour....... etc.
Yes you could make [timer_set] a sub-patch instead of an abstraction, but you cannot use arguments in that case. You would have to replace the $1 and $2 in every copy of the sub-patch with the current arguments for the abstraction...... a bad idea I think..... it's a backward move.

Yes, I think you could leave out all the libraries that you don't need..... and the doc folder.
Pd (in windows) does not need to be installed.... it can be portable...... maybe other OS's too but I don't know.
It is possible to lock patches as well...... they still work but cannot be "clicked".

You will need to learn about OSC messaging, or [netsend] and [netreceive]......... and [netsend~] and [netreceive~] for passing messages and audio between people. A bit of network understanding would help too..... wifi... security.... all of that.
David.