@pmh1d15 OSC is an IP network protocol. You will need Ethernet or Wi-Fi on the Teensy to "talk" OSC...... unless it is possible to get the Teensy to make its USB connector behave like a network port?...... maybe dangerous for future programming requirements?
At the moment it is behaving as a TTY port...... which is logical given that it is its only com port.

Either give it a network port......... https://forum.pjrc.com/threads/40238-Teensy-3-2-with-WIZ820io-and-OSC ......or convert your messages within PD from OSC to TTY data and use the USB connection.

However, looking at your OP link it seems that is exactly what is happening in "pumpsn17".
The patch [slipserial.pd] is doing the conversion to the teensy datastream.
So it is using the tty port and you should have a working system.....

Is [slipserial.pd] looking through the USB port to the pins on the Teensy...... is any voltage appearing on Teensy "S0".

More info here......
https://github.com/CNMAT/OSC
David.

Hi there,

Thanks for taking the time. I am getting a little bit frustrated here, so I guess it’s best to ask the community:

How do I get MrPeach to work on 0.47.1? I am using a Raspberry Pi 3 (running Linux version 4.9.20-v7+) and Pure Data 0.47.1.

I installed mrpeach using the “find externals” functionality. Of course I edited the path to “/home/pi/pd-externals” and created a “mrpeach” entry in the startup preferences.

Some background information: I want my Python code to “communicate” with pd but actually I do not care how they do this. OSC-Messages seem to be the easiest solution.
Well, seemed. I am a total beginner to pd

Help much appreciated

Daniel

By the way here is the log:

tried ./osc/routeOSC.l_arm and failed
tried ./osc/routeOSC.pd_linux and failed
tried ./osc/routeOSC/routeOSC.l_arm and failed
tried ./osc/routeOSC/routeOSC.pd_linux and failed
tried ./osc/routeOSC.pd and failed
tried ./osc/routeOSC.pat and failed
tried ./osc/routeOSC/osc/routeOSC.pd and failed
tried /home/pi/pd-externals/osc/routeOSC.l_arm and failed
tried /home/pi/pd-externals/osc/routeOSC.pd_linux and succeeded
tried ./mrpeach.l_arm and failed
tried ./mrpeach.pd_linux and failed
tried ./mrpeach/mrpeach.l_arm and failed
tried ./mrpeach/mrpeach.pd_linux and failed
tried ./mrpeach.pd and failed
tried ./mrpeach.pat and failed
tried ./mrpeach/mrpeach.pd and failed
tried /home/pi/pd-externals/mrpeach.l_arm and failed
tried /home/pi/pd-externals/mrpeach.pd_linux and failed
tried /home/pi/pd-externals/mrpeach/mrpeach.l_arm and failed
tried /home/pi/pd-externals/mrpeach/mrpeach.pd_linux and failed
tried /home/pi/pd-externals/mrpeach.pd and failed
tried /home/pi/pd-externals/mrpeach.pat and failed
tried /home/pi/pd-externals/mrpeach/mrpeach.pd and failed
mrpeach: can't load library

Youd patch used only a UDP connection, no OSC format in messages sent. Even though you typed an OSC-style address in a message, that's not an OSC format. OSC format is bytes that are not so human-readable. You need to incorporate the native OSC objects that come with vanilla, [oscformat] and [oscparse].
Here's a screenshot that does what you probably want (note that the OSC address in [oscformat] can omit the forward slashes, but since this is a standard OSC-style address, I kept them there):

Hi all,

I've used PD for audio for years, but this is the first time I've tried to use Gem. This is a new Windows 10 machine, as far as I can tell I've installed PD itself OK - I'm having no problems with any audio patches.

However - I've tried to use Gem it's not working - giving me gemwin ... couldn't create errors:

I've added the library to startup as per the Gem Readme, I've reinstalled both PD and Gem, and I've tried following all the help other people have had with this - but no luck.

Help
!

Hi all,,

I'm trying to do a simple talk-through using libpd with android studio.

adc~ -> *~ 0.5 -> dac~

However, I do not have an android phone, so I'm using an Android Studio emulator (Nexus 4, api 23).
I can't get any input from my laptop microphone (or from my earphones built-in microphone when I try that).
Is there something I'm missing?
I know when using Record_Audio directly in Android studio, you need to add permission.
<uses-permission android:name="android.permission.RECORD_AUDIO"/>
Is my issue something along these lines?
Or is it a limitation with using emulators?
I've read many questions on forums about it, but not many are recent and there seems to be many conflicting answers also.

All the best

Mark

There is actually several options here

• either you are a developper so you can directly use libpd as an audio engine, and use the api to send or receive data from your patch to/from you favorite language (c# c++ java etc.) you can then create your ui in this programming language. Plasma sound uses a mix of android specific code and the processing-for-android drawing api. With this method you need to use something like eclipse or android studio but you can create binary signed apps that you can upload to the android store. (it works great, I've published several apps with this combination).

• either you want to stick with pd :
  1- pddroidparty will run your patch in a specific android app emulating the pd gui with a few additions (touch surface etc.), the sources from Chris target android only. But Pd-party by danomatika will target ios soon (now beta I think).
  2- mobmuplat is also a very neat project, where you can do probably a little more with the graphics. android and ios.
  3- sceneplayer on android is also a way to read patchs on android, it provides a way to display/hide and move images too. It target android, the ios version rjdj is sadly long lost.
  4- ppp mentionned before, will help you publish app using pd as a wysiwyg editor in the same way of pddroidparty, but you'll end up with a signed binary ready to distribute. It also packs a midi clock shared via wifi to sync several apps with one another.

I think it sums up all the options here.

So back to data-structures : data-structures are in libpd, but none of the projects above supports them to my knowledge, you can't display or interact with them. If you program you can probably access them through libpd, draw/manipulate them in the programming language of your choice.

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

Just a report back. I've finally succeeded in getting my app to function stand-alone and now have it available in the Android Market. The free version is available on the Android Market here: What Comes Around Free. Here are the steps I followed to get it working for me.

After installing Ubuntu on a spare computer (along with the rpl command as detailed before), I managed to get the scripts to run, but still couldn't get the "ant install" to function as expected.

I went back to the Windows 7 PC and tried the Eclipse route again. This time I laid the proper groundwork and resolved a lot of errors by importing everything as per Peter Brinkmann's instructions on the Pd Everywhere forum.

"[...] make sure that you&#8217;ve cloned pd-for-android and its dependencies like this:
git clone git://gitorious.org/pdlib/pd-for-android.git
cd pd-for-android
git submodule init
git submodule update
Now you need to import btmidi/BluetoothMidi and pd-for-android/PdCore/jni/libpd into Eclipse (make sure to use
File -> Import&#8230; -> General -> Existing project&#8230;). Now you can import PdCore. If you see error messages, those are probably due to bugs in Eclipse, and you should be able to sort them out by refreshing and cleaning everything once or twice. (This is the annoying part&#8230;)"

I had to fix additional Eclipse errors on my system by setting the Java Compiler Compliance Level to 1.6 for each of the imported projects.

Next I tried to import the project I created by running the scripts in Linux into Eclipse on the Windows machine, but it seems as if one of the scripts deletes the Eclipse project. I went back and imported the originally downloaded PdDroidParty project from the MySynthesizer folder. The project imports under the title PatchSelector. Again, I set Java Compiler Compliance Level to 1.6 (right-click PatchSelector in the Package Explorer - it's under Java Compiler). I also had complaints until I set the Project Build Target to Android 2.2 (right-click PatchSelector in the Package Explorer - it's under Android).

This left me with 9 final errors related to the SVGParser. I resolved this by right-clicking PatchSelector in the Package Explorer and going to Build Path/Configure Build Path/Add JARs and selecting svg-android.jar under PatchSelector/libs in my workspace directory. I remember having to restart Eclipse a couple of times to get rid of spurious errors (!)

Next I renamed PatchSelector to my own title (in my case WhatComesAround) by right-clicking in the Package Explorer and choosing Refactor/Rename.

I copied across files that were created when I ran the Linux scrips, notably:
* patch.zip (res/raw folder) - this zip contains a folder called "patch", itself containing your pd patch as a droidparty_main.pd file, as well as a file titled VERSION-169 (in my case) - it doesn't seem to have an extension and simply contains the text 169
* I placed my splash.svg in the same folder (res/raw)
* my icon.png in the folder res/drawable
* the same icon.png in bin/res/drawable
* in the res/values folder, an patch.xml and strings.xml

Next I set about renaming files and occurrences within files with my own names - one of the Linux scripts does this, but I did it by hand on the Windows machine using Windows Grep (http://www.wingrep.com/) to search for all instances, and changing names inside Eclipse. I replaced all occurrences of PdDroidParty with my own name (WhatComesAround), a single instance of PdDroid Party with What Comes Around, as well as any mention of MySynthesizer (again with WhatComesAround).

After testing in the emulator I exported signed .apk's from Eclipse - one for a free and one for a paid version.

So, tonight have sussed 2 way comms from TouchOSC on my iPad to CubaseSX3, and thought I'd share this for those who were struggling with getting their DAW to talk back to the TouchOSC App. These patches translate OSC to MIDI, and MIDI back to OSC.

Basically, when talking back to OSC your patch needs to use:

[ctrlin midictrllr# midichan] > [/127] > [send /osc/controller $1] > [sendOSC] > [connect the.ipa.ddr.ess port]

So, in PD:

[ctrlin 30 1] listens to MIDI Controller 30 on MIDI Channel 1, and gets a value between 0 & 127. This value is divided by 127, as TouchOSC expects a value between 0 & 1. We then specify the OSC controller to send it to and the result of the maths ($1), and send the complete OSC packet to the specified IPAddress and Port.

This can be seen in LogicPad.vst-2-osc.pd

All files can be found in http://www.minimotoscene.co.uk/touchosc/TouchOSC.zip (24Mb)

This archive contains:

MidiYoke (configure via Windows > Start > Control Panel)
PD-Extended
touchosc-default-layouts (just incase you don't have LogicPad)
Cubase SX3 GenericRemote XML file (to import).
Cubase SX3 project file.
2x pd files... osc-2-vst, and vst-2-osc. Open both together.

In PD > Midi settings, set it's Midi Input and Midi Output to different channels (eg: Output to 3, Input to 2). In Cubase > Device Settings > Generic Remote, set Input to 3, and output to 2.

Only PAGE ONE of the LogicPad TouchOSC layout has been done in the vst-2-osc file.
Am working on the rest and will update once complete.

As the layout was designed for Logic, some functions don't work as expected, but most do, or have been remapped to do something else. Will have a look at those once I've gotten the rest of the PD patch completed.

Patches possibly not done in most efficient method... sorry. This is a case of function over form, but if anyone wants to tweak and share a more efficient way of doing it then that would be appreciated!

Hope this helps some of you...

I don't have a clear enough picture of how your setup is configured to determine where the problem might be, so I will ask a bunch of questions...

1) Midi mapping problem
Touch OSC on the iPad is configured and communicating with PD on windows, yes?
Are you using mrpeach OSC objects in PD?
Did you also install Midi Yoke as well as Midi OX?
Is there another midi controller that could be overriding the midi sent from PD to Tracktor?
Are you using Midi OX to watch the midi traffic to Tracktor in realtime?

I don't use Touch OSC (using MRMR) but you mentioned that the PD patch is being generated? Can you post the patch that it's generating?

2) Midi Feedback
It sounds like you want the communication to be bidirectional, this is not as simple as midi feedback. Remember Touch OSC communicates using OSC and Tracktor accepts and sends Midi. So what you have to do is have Tracktor output the midi back to PD and have PD send the OSC to Touch OSC to update the sliders.

I would seriously consider building your PD patch by hand and not using the generator. You'll learn more that way and will be able to customize it better to your needs.