I'm sorry I don't read the full thread, English is not my natural language and it's a bit technical…
Nevertheless I'd like to note that even in written languages the return to caller process at low level is coded by giving the called method an address to store the result in and then the caller can read it.

Pseudo assembly code

MAIN:
give me address to store N bytes
push this address to the return register
call the method
METHOD:
do stuff
get the address from the return register
write N bytes at this address
:END 
read N bytes at the address
do stuff with this result

The full code is unfoldable as a control flow.
The N bytes can be a pointer to an address the method allocates so the return data size can be set by the method.

The easiest way to simulate this in puredata is to create a memory address as [value] do for float. The caller can then give the address to the method with an argument or a message.
As data structures are pointer-accessible they can certainly help to create such a feature.

@lucassilveira You are using a multicast address...... With multicast the listener has to join the group.... so you need to tell [udpreceive~] to listen to that address range...... [udpreceive~ 3000 2 239.255.255.250]
Open [pd multicast] in the [udpsend~] help file. You will see that you can also specify that it will multicast on only the Wi-Fi or only the Ethernet connection from your computer, and set the "Time To Live" TTL to limit how far the packets will propagate on the network.
When you receive on the same computer you are already in the multicast group as the datagrams have been looped back by the OS (usually). All ports on the host are available for UDP without a connection, unlike TCP where a return connection is necessary and could be refused by the OS...

With a broadcast address the stream is broadcast everywhere, even to the internet, so insecure, and it will flood the network...... but then you do not need to specify a "listen" address for [udpreceive~] .... just the port is enough because every machine on the network will have the port open and will be receiving.
You only need multicast if you will have multiple receivers, but it will not flood your network as it sends only to receivers that join the group.... https://ipfabric.io/blog/troubleshooting-multicast-traffic-flows/
Broadcast will also be received at multiple end points, but if you will only have one receiver then sending directly to that receivers IP address will work....... and is better, for the reasons above.

I certainly needed to play around with the buffer size for [udpreceive~] to get reliable streaming over wi-fi.
Here are a send and a receive patch that work sending from my computer to a Raspberry Pi over wi-fi.
Obviously the IP addresses will be incorrect for you, but it might help.....
stream.zip
There are 3 possible [connect( messages in the send patch..... by computer name, by IP address, and a broadcast address 255.255.255.255.
David.

@60hz said:

It works for me, but you certainly need to refresh the [number 15( message AFTER create the [pd boid] subpatches creation.

Also, here is a better version using [clone] object that has been part of puredata and makes the design more convienient.

(Note that boids Gem examples need [poltocar] object fom cyclone to work well)

boids2d_clone_Gem_example.zip

Hi, your patch works fine, the boids move correctly, but when I increase their number for example from 15 to 115, also doing the "refresh after..." as you said, the boids increase but stay still, they don't move.
Now, when I open your patch, I get these errors:

--------------------------------------------------------------------
:: Cyclone 0.6-1; Released june 8th 2022
:: License: BSD-3-Clause (aka Revised BSD License)
:: Copyright © 2003-2021 - Krzysztof Czaja, Hans-Christoph Steiner,
:: Fred Jan Kraan, Alexandre Porres, Derek Kwan, Matt Barber
:: and others.
:: -----------------------------------------------------------------
:: Cyclone 0.6-1 needs at least Pd 0.52-0
             (you have 0.52-1, you're good!)
:: Loading the cyclone library did the following:
::   - A) Loaded the non alphanumeric objects, which are:
:: [!-], [!-~], [!/], [!/~], [!=~], [%~], [+=~], [<=~], [<~],
:: [==~], [>=~] and [>~]
::   - B) Added /home/a/Pd/externals/cyclone
:: to Pd's path so the other objects can be loaded too
:: but use [declare -path cyclone] to guarantee search priority
:: in the patch
--------------------------------------------------------------------

opened alsa MIDI client 130 in:1 out:1
declare: Gem: unknown declaration
 canvas.top
... couldn't create
 canvas.top
... couldn't create
 canvas.top
... couldn't create
 canvas.top
... couldn't create
 canvas.top
... couldn't create
 canvas.top
... couldn't create
 canvas.top
... couldn't create
 canvas.top
... couldn't create
 canvas.top
... couldn't create
 canvas.top
... couldn't create
 canvas.top
... couldn't create
 canvas.top
... couldn't create
 canvas.top
... couldn't create
 canvas.top
... couldn't create
 canvas.top
... couldn't create
boids2d 2005-2006 a.sier / jasch    1995-2003 eric l. singer   Jan  1 2023 13:49:25

These are my startup paths:

** [poltocar]** object appears to be in place:

a@a:~$ cd /home/a/Pd/externals/cyclone
a@a:~/Pd/externals/cyclone$ ls
[CUT]          

poltocar.d_fat           
poltocar~.d_fat          
poltocar-help.pd        
poltocar~-help.pd        
poltocar.l_amd64        
poltocar~.l_amd64        
poltocar.l_arm           
poltocar~.l_arm        
poltocar.l_i386         
poltocar~.l_i386         
poltocar.m_amd64        
poltocar~.m_amd64        
poltocar.m_i386          
poltocar~.m_i386        
           
[CUT]

Something is probably missing or i am doing something wrong.

Bye,
a.

@Dizzy-Dizzy Yes, @alexandros means connect them with an Ethernet cable. You will not be able to connect another computer though.... the 2 rpi's will just talk to each other.

You should set the rpi's to use static ip addresses anyway..... and they must be different..!
The home/etc/dhcpcd.conf files should look something like this....... dhcpcd.conf ..... which is set to use wifi and to fall back to Ethernet.... so the fallback should be commented out for your setup..... unless of course you are connecting them to the router with Ethernet cables...... in which case eth0 should be set as primary.

It will help if you post your Pd patches for the 2 rpi's and their home/etc/dhcpcd.conf files and their home/etc/wpa_supplicant/wpa_supplicant.conf files.
Zip them all up in a zip folder and upload them to this thread.

The router should not be connected to the internet..... so the NAT redirection can be turned off.
You can protect access to the router by MAC addresses (the Mac addresses of any device you want to use should be added to the table in the router) to try as far as possible to stop anyone else connecting to the wifi.
The ip addresses of the rpi's should be outside the range of the dhcp server of the router....... but the router dhcp server can be turned off anyway.

You want to be certain that the message passes between the rpi's so you should use TCP and not UDP for netsend/netrecieve.
Also there has been a discussion on the pdList about [netsend -u] dropping the socket so it is best avoided until fixed.
You could add a "fix" mechanism to your patch that makes sure the connection is good before playing anything and doing a disconnect + connect if it gets no reply.

David.

Howdy all,

I just found this and want to respond from my perspective as someone who has spent by now a good amount of time (paid & unpaid) working on the Pure Data source code itself.

I'm just writing for myself and don't speak for Miller or anyone else.

Mac looks good

The antialiasing on macOS is provided by the system and utilized by Tk. It's essentially "free" and you can enable or disable it on the canvas. This is by design as I believe Apple pushed antialiasing at the system level starting with Mac OS X 1.

There are even some platform-specific settings to control the underlying CoreGraphics settings which I think Hans tried but had issues with: https://github.com/pure-data/pure-data/blob/master/tcl/apple_events.tcl#L16. As I recall, I actually disabled the font antialiasing as people complained that the canvas fonts on mac were "too fuzzy" while Linux was "nice and crisp."

In addition, the last few versions of Pd have had support for "Retina" high resolution displays enabled and the macOS compositor does a nice job of handling the point to pixel scaling for you, for free, in the background. Again, Tk simply uses the system for this and you can enable/disable via various app bundle plist settings and/or app defaults keys.

This is why the macOS screenshots look so good: antialiasing is on and it's likely the rendering is at double the resolution of the Linux screenshot.

IMO a fair comparison is: normal screen size in Linux vs normal screen size in Mac.

Nope. See above.

It could also just be Apple holding back a bit of the driver code from the open source community to make certain linux/BSD never gets quite as nice as OSX on their hardware, they seem to like to play such games, that one key bit of code that is not free and you must license from them if you want it and they only license it out in high volume and at high cost.

Nah. Apple simply invested in antialiasing via its accelerated compositor when OS X was released. I doubt there are patents or licensing on common antialiasing algorithms which go back to the 60s or even earlier.

tkpath exists, why not use it?

Last I checked, tkpath is long dead. Sure, it has a website and screenshots (uhh Mac OS X 10.2 anyone?) but the latest (and only?) Sourceforge download is dated 2005. I do see a mirror repo on Github but it is archived and the last commit was 5 years ago.

And I did check on this, in fact I spent about a day (unpaid) seeing if I could update the tkpath mac implementation to move away from the ATSU (Apple Type Support) APIs which were not available in 64 bit. In the end, I ran out of energy and stopped as it would be too much work, too many details, and likely to not be maintained reliably by probably anyone.

It makes sense to help out a thriving project but much harder to justify propping something up that is barely active beyond "it still works" on a couple of platforms.

Why aren't the fonts all the same yet?!

I also despise how linux/windows has 'bold' for default

I honestly don't really care about this... but I resisted because I know so many people do and are used to it already. We could clearly and easily make the change but then we have to deal with all the pushback. If you went to the Pd list and got an overwhelming consensus and Miller was fine with it, then ok, that would make sense. As it was, "I think it should be this way because it doesn't make sense to me" was not enough of a carrot for me to personally make and support the change.

Maybe my problem is that I feel a responsibility for making what seems like a quick and easy change to others?

And this view is after having put an in ordinate amount of time just getting (almost) the same font on all platforms, including writing and debugging a custom C Tcl extension just to load arbitrary TTF files on Windows.

Why don't we add abz, 123 to Pd? xyzzy already has it?!

What I've learned is that it's much easier to write new code than it is to maintain it. This is especially true for cross platform projects where you have to figure out platform intricacies and edge cases even when mediated by a common interface like Tk. It's true for any non-native wrapper like QT, WXWidgets, web browsers, etc.

Actually, I am pretty happy that Pd's only core dependencies a Tcl/Tk, PortAudio, and PortMidi as it greatly lowers the amount of vectors for bitrot. That being said, I just spent about 2 hours fixing the help browser for mac after trying Miller's latest 0.52-0test2 build. The end result is 4 lines of code.

For a software community to thrive over the long haul, it needs to attract new users. If new users get turned off by an outdated surface presentation, then it's harder to retain new users.

Yes, this is correct, but first we have to keep the damn thing working at all. I think most people agree with you, including me when I was teaching with Pd.

I've observed, at times, when someone points out a deficiency in Pd, the Pd community's response often downplays, or denies, or gets defensive about the deficiency. (Not always, but often enough for me to mention it.) I'm seeing that trend again here. Pd is all about lines, and the lines don't look good -- and some of the responses are "this is not important" or (oid) "I like the fact that it never changed." That's... thoroughly baffling to me.

I read this as "community" = "active developers." It's true, some people tend to poo poo the same reoccurring ideas but this is largely out of years of hearing discussions and decisions and treatises on the list or the forum or facebook or whatever but nothing more. In the end, code talks, even better, a working technical implementation that is honed with input from people who will most likely end up maintaining it, without probably understanding it completely at first.

This was very hard back on Sourceforge as people had to submit patches(!) to the bug tracker. Thanks to moving development to Github and the improvement of tools and community, I'm happy to see the new engagement over the last 5-10 years. This was one of the pushes for me to help overhaul the build system to make it possible and easy for people to build Pd itself, then they are much more likely to help contribute as opposed to waiting for binary builds and unleashing an unmanageable flood of bug reports and feature requests on the mailing list.

I know it's not going to change anytime soon, because the current options are a/ wait for Tcl/Tk to catch up with modern rendering or b/ burn Pd developer cycles implementing something that Tcl/Tk will(?) eventually implement or c/ rip the guts out of the GUI and rewrite the whole thing using a modern graphics framework like Qt. None of those is good (well, c might be a viable investment in the future -- SuperCollider, around 2010-2011, ripped out the Cocoa GUIs and went to Qt, and the benefits have been massive -- but I know the developer resources aren't there for Pd to dump Tcl/Tk).

A couple of points:

1. Your point (c) already happened... you can use Purr Data (or the new Pd-L2ork etc). The GUI is implemented in Node/Electron/JS (I'm not sure of the details). Is it tracking Pd vanilla releases?... well that's a different issue.

2. As for updating Tk, it's probably not likely to happen as advanced graphics are not their focus. I could be wrong about this.

I agree that updating the GUI itself is the better solution for the long run. I also agree that it's a big undertaking when the current implementation is essentially still working fine after over 20 years, especially since Miller's stated goal was for 50 year project support, ie. pieces composed in the late 90s should work in 2040. This is one reason why we don't just "switch over to QT or Juce so the lines can look like Max." At this point, Pd is aesthetically more Max than Max, at least judging by looking at the original Ircam Max documentation in an archive closet at work.

A way forward: libpd?

I my view, the best way forward is to build upon Jonathan Wilke's work in Purr Data for abstracting the GUI communication. He essentially replaced the raw Tcl commands with abstracted drawing commands such as "draw rectangle here of this color and thickness" or "open this window and put it here."

For those that don't know, "Pd" is actually two processes, similar to SuperCollider, where the "core" manages the audio, patch dsp/msg graph, and most of the canvas interaction event handling (mouse, key). The GUI is a separate process which communicates with the core over a localhost loopback networking connection. The GUI is basically just opening windows, showing settings, and forwarding interaction events to the core. When you open the audio preferences dialog, the core sends the current settings to the GUI, the GUI then sends everything back to the core after you make your changes and close the dialog. The same for working on a patch canvas: your mouse and key events are forwarded to the core, then drawing commands are sent back like "draw object outline here, draw osc~ text here inside. etc."

So basically, the core has almost all of the GUI's logic while the GUI just does the chrome like scroll bars and windows. This means it could be trivial to port the GUI to other toolkits or frameworks as compared to rewriting an overly interconnected monolithic application (trust me, I know...).

Basically, if we take Jonathan's approach, I feel adding a GUI communication abstraction layer to libpd would allow for making custom GUIs much easier. You basically just have to respond to the drawing and windowing commands and forward the input events.

Ideally, then each fork could use the same Pd core internally and implement their own GUIs or platform specific versions such as a pure Cocoa macOS Pd. There is some other re-organization that would be needed in the C core, but we've already ported a number of improvements from extended and Pd-L2ork, so it is indeed possible.

Also note: the libpd C sources are now part of the pure-data repo as of a couple months ago...

Discouraging Initiative?!

But there's a big difference between "we know it's a problem but can't do much about it" vs "it's not a serious problem." The former may invite new developers to take some initiative. The latter discourages initiative. A healthy open source software community should really be careful about the latter.

IMO Pd is healthier now than it has been as long as I've know it (2006). We have so many updates and improvements over every release the last few years, with many contributions by people in this thread. Thank you! THAT is how we make the project sustainable and work toward finding solutions for deep issues and aesthetic issues and usage issues and all of that.

We've managed to integrate a great many changes from Pd-Extended into vanilla and open up/decentralize the externals and in a collaborative manner. For this I am also grateful when I install an external for a project.

At this point, I encourage more people to pitch in. If you work at a university or institution, consider sponsoring some student work on specific issues which volunteering developers could help supervise, organize a Pd conference or developer meetup (this are super useful!), or consider some sort of paid residency or focused project for artists using Pd. A good amount of my own work on Pd and libpd has been sponsored in many of these ways and has helped encourage me to continue.

This is likely to be more positive toward the community as a whole than banging back and forth on the list or the forum. Besides, I'd rather see cool projects made with Pd than keep talking about working on Pd.

That being said, I know everyone here wants to see the project continue and improve and it will. We are still largely opening up the development and figuring how to support/maintain it. As with any such project, this is an ongoing process.

Out

Ok, that was long and rambly and it's way past my bed time.

Good night all.

Hello there, this seemed an interesting patch, so i unzipped it on a folder and tried to open it but got an unusable display and a string of errors on console, something like this (its not all of it);

list fromsymbol
... couldn't create
list tosymbol: unknown function
list tosymbol
... couldn't create
pdcontrol
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
clone 1 0 3 0 (canvas->outlet) connection failed
clone 1 1 8 0 (canvas->list split) connection failed
else/receiver
... couldn't create
else/receiver
... couldn't create
text search $1
... couldn't create
text set $1
... couldn't create
text search $1
... couldn't create
text get $1
... couldn't create
text size $1
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
text delete $1
... couldn't create
text_replace.pd 31 0 6 0 (canvas->select) connection failed
text_replace.pd 31 1 34 0 (canvas->trigger) connection failed
text define $0-guithru
... couldn't create
text size
... couldn't create
text get
... couldn't create
else/loadbanger -init
... couldn't create
else/receiver
... couldn't create
else/dollsym 1
... couldn't create
else/dollsym 2
... couldn't create
text define -k $0-controls
... couldn't create
array: no method for 'set'
else/args
... couldn't create
else/break -
... couldn't create
list fromsymbol: unknown function
list fromsymbol
... couldn't create
list tosymbol: unknown function
list tosymbol
... couldn't create
pdcontrol
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
clone 1 0 3 0 (canvas->outlet) connection failed
clone 1 1 8 0 (canvas->list split) connection failed
else/receiver
... couldn't create
else/receiver
... couldn't create
text search $1
... couldn't create
text set $1
... couldn't create
text search $1
... couldn't create
text get $1
... couldn't create
text size $1
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
text delete $1
... couldn't create
text_replace.pd 31 0 6 0 (canvas->select) connection failed
text_replace.pd 31 1 34 0 (canvas->trigger) connection failed
text define $0-guithru
... couldn't create
text size
... couldn't create
text get
... couldn't create
else/loadbanger -init
... couldn't create
else/receiver
... couldn't create
else/dollsym 1
... couldn't create
else/dollsym 2
... couldn't create
text define -k $0-controls
... couldn't create
array: no method for 'set'
else/click
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
q 8 0 11 0 (canvas->outlet) connection failed
q 8 1 5 0 (canvas->+~) connection failed
q 8 2 12 1 (canvas->canvas) connection failed
else/args
... couldn't create
else/break -
... couldn't create
list fromsymbol: unknown function
list fromsymbol
... couldn't create
list tosymbol: unknown function
list tosymbol
... couldn't create
pdcontrol
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
clone 1 0 3 0 (canvas->outlet) connection failed
clone 1 1 8 0 (canvas->list split) connection failed
else/receiver
... couldn't create
else/receiver
... couldn't create
text search $1
... couldn't create
text set $1
... couldn't create
text search $1
... couldn't create
text get $1
... couldn't create
text size $1
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
text delete $1
... couldn't create
text_replace.pd 31 0 6 0 (canvas->select) connection failed
text_replace.pd 31 1 34 0 (canvas->trigger) connection failed
text define $0-guithru
... couldn't create
text size
... couldn't create
text get
... couldn't create
else/loadbanger -init
... couldn't create
else/receiver
... couldn't create
else/dollsym 1
... couldn't create
else/dollsym 2
... couldn't create
text define -k $0-controls
... couldn't create
array: no method for 'set'
else/click
... couldn't create
text define -k $0-controls
... couldn't create
array: no method for 'set'
else/args
... couldn't create
text define -k $0-controls
... couldn't create
array: no method for 'set'
else/args
... couldn't create
else/loadbanger -init
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
mode 14 0 3 0 (canvas->clip) connection failed
mode 14 1 4 0 (canvas->wrap) connection failed
mode 14 2 6 0 (canvas->abs) connection failed
mode 14 3 15 0 (canvas->moses) connection failed
else/args
... couldn't create
else/break -
... couldn't create
list fromsymbol: unknown function
list fromsymbol
... couldn't create
list tosymbol: unknown function
list tosymbol
... couldn't create
pdcontrol
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
clone 1 0 3 0 (canvas->outlet) connection failed
clone 1 1 8 0 (canvas->list split) connection failed
else/receiver
... couldn't create
else/receiver
... couldn't create
text search $1
... couldn't create
text set $1
... couldn't create
text search $1
... couldn't create
text get $1
... couldn't create
text size $1
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
text delete $1
... couldn't create
text_replace.pd 31 0 6 0 (canvas->select) connection failed
text_replace.pd 31 1 34 0 (canvas->trigger) connection failed
text define $0-guithru
... couldn't create
text size
... couldn't create
text get
... couldn't create
else/loadbanger -init
... couldn't create
else/receiver
... couldn't create
else/dollsym 1
... couldn't create
else/dollsym 2
... couldn't create
text define -k $0-controls
... couldn't create
array: no method for 'set'
else/click
... couldn't create
else/break -
... couldn't create
list fromsymbol: unknown function
list fromsymbol
... couldn't create
list tosymbol: unknown function
list tosymbol
... couldn't create
pdcontrol
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
clone 1 0 3 0 (canvas->outlet) connection failed
clone 1 1 8 0 (canvas->list split) connection failed
else/receiver
... couldn't create
else/receiver
... couldn't create
text search $1
... couldn't create
text set $1
... couldn't create
text search $1
... couldn't create
text get $1
... couldn't create
text size $1
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
text delete $1
... couldn't create
text_replace.pd 31 0 6 0 (canvas->select) connection failed
text_replace.pd 31 1 34 0 (canvas->trigger) connection failed
text define $0-guithru
... couldn't create
text size
... couldn't create
text get
... couldn't create
else/loadbanger -init
... couldn't create
else/receiver
... couldn't create
else/dollsym 1
... couldn't create
else/dollsym 2
... couldn't create
count.pd 15 0 8 0 (canvas->+) connection failed
count.pd 15 1 14 0 (canvas->-) connection failed
else/args
... couldn't create
else/loadbanger -init
... couldn't create
display 60 0 29 0 (canvas->message) connection failed
display 60 1 31 0 (canvas->select) connection failed
display 60 2 32 0 (canvas->message) connection failed
display 60 3 31 0 (canvas->select) connection failed

Any ideas ? cheers

@RayManiac It will not be "localhost".
Localhost means "on the same computer".

You will need to know the IP address of the computer you are sending to and then connect with a message like [connect 198.168.1.23 1000( although as @ddw_music says ports are reserved by so many applications that you really should use a port above 8000.

So [connect 192.168.1.23 8499( .......for example.
And [netreceive] set to receive on port 8499.

You really should set the IP address for the remote computer to "static" and not rely on DHCP.
Next time it joins the network it might be given a different address by the DHCP and then your connection will of course fail.
Go to the network settings on the remote computer interface (wireless or Ethernet depending on what you are using) and set a static address. Look at your router web page and see what range of addresses DHCP will assign. Usually it is 192.168.1.50 to 192.168.1.100.
So as to be sure of no conflict set the remote computer to an address outside the range.... 192.168.1.110 for example.

Only ever change the last of the four numbers though or you will be setting an address outside the subnet of the router.
David.

@oscarsantis
NetPd could be a solution if you have a local server running.
But if you don't?

When connecting on a local network there is no problem because security is relaxed for communications on your private network.
For connections to the outside world though, your firewall and your router settings are involved.
For UDP and TCP there are small differences.

UDP is a "one way" protocol. Data is sent without any confirmation that it has arrived correctly.
For OSC that is usually fine as there is usually a flow of messages (as a fader is moved for example) and if one message is dropped it does not matter much.

TCP waits for a confirmation message to be returned, and so it is a "two way" protocol.
The data is always correct, but timing can suffer when data has to be resent.

(((A remote computer address is not something like 192.168.1 35 (a reserved private network address).
It will be something like 133.92.158.230......... the address set by the internet service provider (ISP) for your router.
That works because there are never any direct incoming communications unless you are running a server. That is another can of worms though.
Any incoming connection has been set up by your computer (browser, email etc.) which has told the remote sever how to get back in touch....... and opened the ports to allow it to do so.
See below.......)))

Your firewall will need to allow Pd to send data over the public network..... so check your firewall settings.
It is usually possible to restrict the port range so as to increase security.
But sending is not dangerous. It is incoming data that the router protects you from.

Your router will need to be set to allow an incoming connection for the port that you are using to receive from the remote computer.
Look for "port forwarding" on your router web page. Usually there is some help on the page.
You need to "forward" the port on your computer that the remote computer will be trying to connect to.
You have to set the port and the local IP address of your computer....... so you should fix (static address) the local IP address of your computer and not rely on DHCP because if the address changes it will not be found.

The remote computer cannot use your local IP address..... it will just look for it on its own local network.
It needs to send to the port........ at the web IP address of your router...... set by your ISP.
There are browser tools that will tell you your web IP address....... just a google search "what is my IP" will probably do that.
You might need to tell your ISP that you want your IP fixed..... another can of worms.

All of that is going to apply to the remote computer and its router too.
And of course you need to know the web IP address of the remote router (again...... set by its ISP) so as to send to that address and not the local IP address of the remote computer.
David.

Not sure if I should even bother sharing this thread started to get over my head real quick when the rgb tcl talk started. This process does not use rgb messages.

But originally thought i had some things to share so i spent a few minutes writing this so im going to share it anyways. LMAO

This patch will update the canvas color when a index for the canvas is given.

CanvasRealTimeColorChange.pd

I should mention I have this setup to be used for multiple items. This is how i am using the patch. i have a [bng] underneath a canvas to keep it hidden we will call this my "songitem" This will make the canvas act as a [bng] just make sure the [bng] has the same dimensions as the canvas. So when a [bng] is pressed the canvas color will change to the active color. Then when any other button is pressed it will then become the "active" color and the previous canvas will return to the "default" color.

So if you had a canvas with the send and recieve symbols set as $1-Canvas-send $1-Canvas-recv you can easily feed the index of the canvas by replacing {r selsongitem}
with a inlet and feed whatever index you desired.

Its usage is highlighted in the screenshot.

Near the bottom of the patch you will find the object [symbol $1-songitem-recv]
change $1-songitem-recv to the proper recv symbol for your canvas.

If anything I hope this patch sparks some ideas for new people to pd. I'm only a year in and I think I'm developing a bald spot. lol i kid. And for the vets please pick this apart i need to learn what to do and what not to Ive been focusing on the order of operations as of late.

Enjoy

Okay ;that's what I suspected you were doing. It is possible to use the MTP serial directly with linux and the mtpav driver, though this requires a machine with true hardware parallel port access (USB adapters won't cut it) and is limited to MIDI output only as the driver is a hack that was never finished. I used to run mine that way with a second USB MIDI interface connected to one or more of the MTP's unused routed MIDI outputs (there is, BTW still no way to connect the MTP USB version directly to a Linux system as it doesn't use a standard USB MIDI driver)

As far as the kernel is concerned, I've only ever used lowlatency or RT kernels for MIDI stuff. I don't know how a generic kernel would affect this problem but it's probably best avoided as they are not specifically built for multimedia.

Now read closely as this is where it becomes stupidly complicated.

First, make sure that the problem is internal to Pd. Your interfaces are probably not the issue (since Pd is only seeing the UM-1 driver I don't think the MTP even figures in here). However, the chosen MIDI API can get in the way, specifically in the case of the unfinished JACK MIDI. JACK MIDI presently can only pass SYSEX as short realtime messages. SYSEX data dumps will disappear if sent into the current JACK MIDI system. ALSA works OK. OSS probably too, but I have not tried it.

If that stuff is ruled out and you are still getting problems, it probably has to do with a set of longstanding bugs/oversights in the Pd MIDI stack that can affect the input, output, or both.

On the output side there is a sysex transmission bug which affects all versions of Pd Vanilla before 0.48. The patch that fixed Vanilla had already been applied to L20rk/PurrData for some time (years, I think). The output bug did not completely disable SYSEX output. What it did was to miss-format SYSEX in a way that can't be understood by most modern midi applications, including the standard USB MIDI driver software (SYSEX output from Pd is ignored and the driver/interface will not transmit anything). You would not notice this bug with a computer connected directly to an MTP because the MAC and Linux MTP drivers are programmed to pass raw unformatted MIDI.

If this is the problem and you have to use a pre-0.48 version of Vanilla it can be patched. See:

https://sourceforge.net/p/pure-data/bugs/1272/

On the MIDI input side of Pd we have 2 common problems. One is the (annoyingly unfinished but nevertheless implemented) input to output timestamping buffer that's supposed to provide sample-accurate MIDI at the output (if it was finished). This can be minimized with the proper startup flags (for a MIDI-only instance of Pd, -rt -noaudio -audiobuf 1 -sleepgrain 0.5 works for me) or completely defeated with a source code tweak to the s_midi.c file. This may not be the source of your particular problem as it usually only affects the time it takes to pass messages from input to output, but is worth mentioning as it can be very annoying regardless.

With SYSEX dumps it is more likely that the problem lies with the MIDI queue size. This is very common and I experienced it myself when trying to dump memory from a Korg Electribe Ea-1.. The current version of Pd limits the queue to a size of 512 (even worse it used to be 20) and any input larger than that will get truncated w/no error warning. There is not yet any way to change this with startup flags or user settings. This can only be "fixed" by a different tweak to s_midi.c and recompiling the app.

The attached text files are derived from the Pd-list and will show the specific mods that need to be made to s_midi.c.

pd_midi_io_timing_buffer_mod

pd_midi_input_quere_mod