I'm just trying to set up a basic patch to test a network connection between a Raspberry pi 2b (running wheezy), and a Macbook pro.

They're both connected to the same network (generated by the RPI), but I can't seem to get messages to flow. I'm using the iemnet objects, but I can't seem to install the mrpeach externals on the rpi. From what I understand, udpsend and udpreceive should work fine without them, is this correct?

I'm using port 9001. In terms of the IP address should I use 'inet' address or the 'Bcast' address?

And last question (for now), udpsend seems to need a message to connect, does udpreceive need a similar message or is it always listening?

@toddak Hello,
If you install........ pd-extended_043.4~extended1-1.deb .........then you will have Martin Peach objects available. Put [import mrpeach] in your patch, and I know that [udpreceive~] will work.
I use it with [dumpOSC xxxx] from the extra/oscx library to control some patches on my Pi from my phone.
You need to use the inet address of the Pi to send directly to the Pi.
The [udpsend] object needs to know the ip address and the port to send to, but the [udpreceive] object just needs to be told which port to open, as it is "part of" it's host's (the Pi) address.
To send stuff back..... a [udpsend] object on the Pi needs your MacBook's ip.
David

@whale-av
Hello David, thanks for the reply.

By the looks of things I only have PD0.43.2, and potentially not extended. To install it on the rpi I just used 'sudo apt-get install puredata'.

Having a look around now, I've found some code here to show how to get PD043.3 extended on the rpi (http://puredata.info/downloads/pd-extended-0-43-3-on-raspberry-pi-raspbian-wheezy-armhf).

How did you get 043.4? Sorry, pretty new to the RPI... and does it work on wheezy?

@toddak Sorry, I don't remember, but here is a link that works.......... (for the deb file).......(http://en.osdn.jp/projects/sfnet_pure-data/downloads/pd-extended/0.43.4/pd-extended_0.43.4~extended1-1~raspbian_wheezy_armhf.deb/
and another that probably does.....
sourceforge.net/projects/pure-data/files/pd-extended/0.43.4/
And then put it on your pi, and from a terminal window type (or copy this) and press enter.......

sudo dpkg -i pd-extended_0.43.4~extended1-1~raspbian_wheezy_armhf.deb

Unless you have a different one and you must change the name.........
You will need to be in the directory where you put the package (probably your desktop?)......
so in terminal you will need to get there first using ls (for "list" to see the contents of the current directory) and cd (to change directory).............
It works for me under wheezy, but my Pi is a B and so not the same architecture. The deb files for them are bit by bit identical though........ it should work......
David.

You could also update your image to Jessie since it's available since September and install Pd. You'll get Pd-0.46-2 which has native OSC objects, [oscformat] and [oscparse].

@whale-av - it looks like there might be an issue, There seems to be some errors during install, and then PD won't open:

pi@raspberrypi ~/Desktop $ sudo dpkg -i pd-extended_0.43.4~extended1-1~raspbian_wheezy_armhf.deb
(Reading database ... 86594 files and directories currently installed.)
Preparing to replace pd-extended 0.43.4~extended1-1~raspbian (using pd-extended_0.43.4~extended1-1~raspbian_wheezy_armhf.deb) ...
Unpacking replacement pd-extended ...
dpkg: dependency problems prevent configuration of pd-extended:
pd-extended depends on libftgl2 (>= 2.1.3~rc5); however:
Package libftgl2 is not installed.
pd-extended depends on libgsl0ldbl (>= 1.9); however:
Package libgsl0ldbl is not installed.
pd-extended depends on libquicktime2 (>= 2:1.2.2); however:
Package libquicktime2:armhf is not installed.
pd-extended depends on ttf-dejavu; however:
Package ttf-dejavu is not installed.
pd-extended depends on pulseaudio-utils; however:
Package pulseaudio-utils is not installed.

dpkg: error processing pd-extended (--install):
dependency problems - leaving unconfigured
Processing triggers for shared-mime-info ...
Processing triggers for menu ...
Processing triggers for man-db ...
Processing triggers for desktop-file-utils ...
Processing triggers for hicolor-icon-theme ...
Errors were encountered while processing:
pd-extended

Does anyone know if 0.43.3 has the mrpeach externals?

@ alexandros - I was having issues with Jessie and some of the screens I was running, so would prefer to stick with Wheezy at the moment if possible. But if there is no other work around I might have to go that way!

@toddak to fix the missing dependancies run this in terminal.............
sudo apt-get update
(and then)
sudo apt-get upgrade -f

In fact you should do all of these from time to time....... (not the bits in brackets)
sudo apt-get update
sudo apt-get upgrade
sudo apt-get upgrade -f (fix missing dependencies)
sudo rpi-update (firmware and kernel)

It is most likely that you need pulse audio for Pd to run....... I think that it is essential....
and maybe the dejavu fonts (uncertain)........ and so the command above should solve your problem and Pd should then run....

ALSO...... if it will still not run once the missing dependancies have been installed you should check that you are running an armhf system:...........

Run this command in terminal:

readelf -A /proc/self/exe | grep Tag_ABI_VFP_args

If the Tag_ABI_VFP_args tag is found, then you're running on an armhf system. If nothing is returned, then it's armel. To show you an example, here's what happens on a Raspberry Pi running the Raspbian distribution:

pi@raspberrypi:~$ readelf -A /proc/self/exe | grep Tag_ABI_VFP_args
Tag_ABI_VFP_args: VFP registers

This indicates an armhf distro, which in fact is what Raspbian is. On the original, soft-float Debian Wheezy distribution, here's what happens:

pi@raspberrypi:~$ readelf -A /proc/self/exe | grep Tag_ABI_VFP_args

Nothing returned indicates that the kernel is armel.

David.

You can also download the latest vanilla from Miller's website and compile it yourself. I've done it on an Pi running Wheezy and it worked super fine.

@whale-av - Just a quick update.
I'm familiar with the update/upgrade process, but not the other ones including upgrade-f.

But I ran the first step suggestion, update and upgrade-f, and it seemed to install fine. So I tried to restart before testing PD...

But my whole rpi doesn't work now. I'm running it with one of their 7" touch screens, but it just stops its booting up procedure at a point, and has only a flashing underscore style cursor in the top left hand of the screen.

I can type and press enter, but no commands are recognised. At this stage I'll re-boot the card with Wheezy, but prior to installing PD I'll do the update/upgrade and rpi-update and see if that helps!

@whale-av
I tired that secondary code, and nothing was returned. So this means I have armel? And what exactly does that mean I have to do?

@alexandros - Does Vanilla have the mrpeach externals working?
And does it matter if I have the Armel kernal?

@toddak Ouch.... I am very surprised that you have an armel distribution..... to make best use properly of your newer Pi I expected that you had the armhf Hard Float raspian distribution installed......
https://www.raspbian.org/RaspbianFAQ#How_much_of_Debian_wheezy_armhf_does_Raspbian_support.3F
Armel is being dropped..... so it is best to change if you can.
Upgrade just uprades your existing packages......... the -f switch tries to fix broken dependancies but should not change anything unless it is a complete working fix. It doesn't upgrade to a new distribution.
http://linux.die.net/man/8/apt-get
So I don't know why your system failed to reboot.
I don't think Vanilla has the MrPeach objects.........
The armel will not be supported much if at all in the future distributions.......
David.

@whale-av
So, the reason I was running Wheezy was due to an old screen (which I no longer use), and because I finally got it to work as a wireless router in that version (which took me weeks).

Will my life be easier if I just bit the bullet and start using Jessie? I'm not a purest, it was just a practical decision.

I'm just debating whether or not to search for other version of wheezy or not...

@toddak You can still run wheezy, but as armhf......
I am tempted to try to find a way to send you an image of my Pi... (raspian wheezy armhf)
It has a working Pd extended and a working Vnc so I just link up to it with my laptop when necessary and the rest of the time it just sits there doing its stuff.
But it's not set up as a router...... it is sitting on the existing network, and its slightly different hardware.
What do you want to do with your Pi?
David.

@whale-av - I thought I could still run Wheezy, but none of them seem to specify if they are armhf or not, so I felt it would be pretty hit and miss trying to figure out which is the right one.

That's really nice of you, but to be honest even just a link to a version of Raspbian Wheezy that is known to be armhf would be a great help.

Long story short, I have four pi's with 7" touch displays. There the interface for a portable multichannel sound system I'm constructing (I'm an artist, currently mainly working with sound). They'll be running PD, and I need the wifi network so that I can send OSC to each invidual speaker via an ipad.

If there's no particular reason, why still use Wheezy? Jessie is the current stable Debian image, so why not use that?
Vanilla doesn't include mrpeach, but if you have 0.46 vanilla it has its own built in objects for OSC, as I've already wrote, [oscformat] and [oscparse].

@toddak Ah!......... so I am sorry toddak, but I have a lot of questions......

So you still want to use the touch screens, and as you have a few Pi's you have backup cards so you have managed to get back to where you were before the update disaster? I hope so as that would make me feel much better!

You do not really want to use netsend and netreceive but in fact OSC objects (so you don't need MrPeach....... and a later vanilla will be ok as Alexandros suggested)? However, extended has many useful objects!

You are using an extra Pi as a router and you want to use [netsend] and [netreceive] on that?
I would think you would be better off with a dedicated router. I just bought another wrt54 on ebay for 99 uk pence.

Are you planning to stream audio to these 4 Pi's (in which case you will need extended) or are you just sending osc messages from them, or just receiving osc messages so as to start/stop playback?
I have not managed to make audio streaming to a Pi work reliably yet without occasional dropouts, and the sound will not work well at all unless you give Pd root privileges............. so remember.... for later...
sudo chmod 4755 /usr/bin/pd-extended
For audio on a Pi it should be run headless, so you should drop your touch screens in that case.

If you are using the Pi's with touch screens just to send osc messages you would be better off with some £40 android 7" tablets running TouchOSC (one licence for all of the android devices you own).
If they are receiving Osc to control their local playback then why do they have touch screens. Is it the touch screens that would not work with Jessie, or some other screen?

Jessie is not very different from Wheezy (it is not a huge update) but it is exclusively armhf. If the touch screens are needed and will not work with Jessie then you are stuck with the current wheezy that you have installed.

If you need to stay with armel then on one of your working Pi,s (armel) you should try this http://puredata.info/downloads/pd-extended-rpi version of extended and install pulse audio and the fonts (manually or with an apt-get) first. A lot of information you can find from here http://puredata.info/docs/raspberry-pi/?searchterm=raspberry
But if you have Rpi B2 (or anything other that an A or a Zero) you should really be running an armhf distribution.

David.

@whale-av
No problem for all the questions, I have been working in solitude on this project with a lot of unknowns, so a lot of trial and error (previously have only used max/msp in laptop sound installations and performance scenarios).

Actually, no back up cards, but I did use the one that I hadn't completely set up yet, so getting it back to where it was isn't that hard. And to be honest i"m used to re-setting these things, its been quite a steep learning curve with lots not working.

The manual I found for puredata (http://en.flossmanuals.net/pure-data/network-data/send-and-receive/) was suggesting the netsend / netreceive objects, so I just took that for granted. At the moment, in its simplest form I would just like the same bang to be sent to all rpi's simultaneously, to that playback start could be synchronised. I assume for this to happen they could all just listen on the same port, and receive the same bang?

I was planning on one of the four rpi as being the router as well as an interface. Is this a bad idea? To be honest getting one to be a router was a huge battle, so if i could just use a router that would be easier. Conveniently those router's you suggested run off 12v, and my system runs of that, so it would be easy to put in the mix. Would the signal be stronger/reach further using a router as opposed to an rpi?

No, not planning on streaming audio. My thought process was that this might be a headache, and take up a bit of CPU. But in all honest its not needed for the project. The main forms of playback would literally be a mono file loaded into a PD patch with synchronised playback, or a PD patch as instrument (ie, sampler/synth type of interface) loaded onto each pi. In either case, they would be controlled via OSC. The instrument version might have been controlled by different ipads/OSC devices.

Too late, have already bought the screens. Part of this decision process was that there is so much that could go wrong in this scenario, that with a touch screen added I could easily trouble shoot in the field. Also, for the instrument patch, the instrument could just be on the screen which would be great.

The original touchscreens, small 2" ish ones, wouldn't work with Jessie, that's the short answer. However, what I wanted to do was to be able to access the HDMI out in order to mirror the screen, so that I could actually see what I was programming. I didn't know when purchasing them that the HDMI out is disabled once they are installed, and its a headache to get them output both to screen and HDMI out. So the 7" screens I figured would easily allow me to program the device in my studio without the need for extra monitors, and could easily be used in the field.

So, I'm pretty sure i can now change to Jessie, as the 7" screens seem easier to work with. The only thing that wouldn't work is the tutorial I have for turning a RPI into a router. But, if that will make things complicated (which if I'm reading between the lines, it might?), then I think powering an external router might be an easier option.

I think Armel in the long run will cause headaches, it does make sense to stay with the newer version, and I think switching to Jessie at this point in time would make sense.

Epic reply. Thoughts welcome!!

@whale-av PS if I'm not using [udpsend] and [udpreceive], how do I send/receive the OSC over a network?

@toddak That's a good resume...... as the Germans would say...... al ist clar....

I would recommend a separate router because it will be much easier to set up.
If for any reason it doesn't work you can borrow a spare almost immediately anywhere in the world.
Many of them (like the Linksys wrt54 series) have two aerials (diversity, more likely to get the message) and you can even plug in better aerials if you wish.
You can place it centrally to your performance space, doubling the possible size of the space.
You will be giving the Pi that you had planned to be the router less work.
Also, it might be easier to set up security so that your audience do not access your network during the show.

Yes, it's a big shame about the screens. It's a lot easier (especially when you set up for a performance) to VNC / network / putty (for windows) into them from your laptop..... and easier setting up at home as well. You can even do a remote reboot before a show if you are feeling a bit uncertain.
With vnc you can have all four of your Pi desktops on your laptop screen for control and monitoring. I would recommend setting up a vnc on them anyway for the day when you cannot get through the audience to adjust a Pi. You will need to use the X11 desktop or you will see a different desktop on your laptop from the one on your touch screen, which can be very confusing.
Through a network share you can copy/paste your patches between your laptop and the Pi's.
Through a remote terminal you can reboot / change your config files etc.

Yes, I see no reason not to switch to Jessie. Then I would put Pd-extended on the Pi's even though the extended project is not likely to evolve. There is just more stuff to play with without building externals.

OSC is great for what you want to do, so as Alexandros said, Vanilla will be ok now that osc has been added..........
For them all to receive at the same time you could broadcast to the network so they all receive the same message, or send to each Pi individually. For your current project broadcast is fine...... but if you might develop a more complex system (very likely I think) it is best to talk to them individually from the start through their individual ip addresses.

Osc messages are sent over udp, not tcp, so the sender has no idea whether the message has been received. I have never had a problem starting tracks, even on my system where there can be up to 64 musicians all adjusting their monitoring at the same time (a huge flood of osc messages). If you ever find that a Pi does not play you could set your patch to send the message two of three times in a row. The difference in start time (between Pi's) would still be less that the delays in the room that you will hear depending upon where you are sitting (with the same track on every Pi.).

I don't know the osc objects in vanilla.
In extended the easy objects for osc are...........
To receive......... [dumpOSC xxxx] where xxxx is the port number.
To send............... [packOSC] feeding it's output to [udpsend]

So with extended you would be using [udpsend].......
David.

@whale-av
Incidentally I jumped on ebay and fount a WRT54GL going for AU$10 with 5 minutes to go, and grabbed it just in case. Seems rather serendipitous.

It does make sense to do it that way, and the bonus of adding extra aerials is also a good thing. Shall look forward to trying that, although for the moment I'll test it as a part of one of the packs (I only have four 12v sources at the moment, but they're pretty reasonable).

I never thought of using VNC, off to find some software shortly. Seems like an obvious answer but incredibly useful! What do you use?

Glad you agree on the Jessie front, always good to run these things past someone, the same with OSC (but I think I will set up individual routing for the message so each pi gets a different bang technically speaking, might be useful later on I think).

Thanks for all your help, off to try Jessie!