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):

I'm on Linux and using JACK too and changing the settings SHOULDN'T haven't an effect on audible frequency, particularly with the oscillators. In fact, it seems like Pd ignores any sample rate I try to set and just takes JACK's sample rate (but perhaps this is changeable with command line parameters). Anyways, I'm not hearing any difference in audible frequency from my own tests, as should be the case.

Anyways, [osc~] uses a lookup table for the sinusoid, meaning there's a cosine wave that's precalculated in Pd's guts and [osc~] searches for the value of cosine it needs with this table (with some interpolation as needed if it wants something in between stored values). A higher sampling rate just means that [osc~] looks up values more often, 48k times a second versus 44.1k times a second. [osc~ 440] in 44.1k and 48k is still going to be 440 Hz, no matter what the sampling rate. Now if you try to play a sound file encoded at 44.1k at 48k, well, that's going to sound different because it's not meant to be read through that fast so everything is going to sound higher-pitched than normal. It's exactly like playing a 33 1/3 RPM at 45 RPM.

You don't really need to worry about different sample rates when using stuff like [osc~] or even [readsf~] at least in terms of audible frequencies, Pd takes care of that. Now when you're indexing into an array with [tabread4~] to play sounds, well, then you need to take sample rates into consideration.

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

@rjp9: My setup basically is the following:
I have an Allen&Heath Xone4D mixer, which has an built in audio interface and some MIDI controllers. The mixer also sends a clock signal to sync up all decks and the Rhythmboy/QuNeo. The Xone is the main mixer, and the midi controllers control the first two decks in Traktor, which are normal decks to play tracks like usual.
The other two decks are set up as remix decks, which each offer 4 columns with 16 cells each (so 2 * 4 * 16 = 128 cells total), which can play one-shots or loops. These are controlled by the Rhythmboy.
My goal is to not only play normal tracks in Traktor, but to enhance them with my own samples and drums, and even do some live remixing by playing/looping non-electronic tracks on the first two decks and backing them up with my own drum loops from the QuNeo/Rhythmboy, to give my DJ sets a special touch that not everyone offers.

The Xone is the new component in this setup, until now I did all mixing in Traktor (on 2 normal decks) with my QuNeo. Now that I have this new mixer, which has enough buttons/faders etc. to render the QuNeo useless, I still want to use the QuNeo in my setup in some way. This is why I looked for step sequencers for the QuNeo and found the Rhythmboy. And the rest of the story happened more or less here.

I hope this answers your question...

Have you looked at my modifications to the rhythmboy? What do you think? Sorry for not commenting, I hope you still get what does what...

Bye, Spatz

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.

Hey,
plz save this as a *.pd file:

#N canvas 283 218 450 300 10;
#X obj 150 162 print~ a;
#X obj 211 162 print~ b;
#X obj 110 130 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144
-1 -1;
#X obj 211 138 +~;
#X obj 150 94 osc~ 440;
#X obj 211 94 osc~ 440;
#X obj 271 94 osc~ 440;
#X connect 2 0 1 0;
#X connect 2 0 0 0;
#X connect 3 0 1 0;
#X connect 4 0 0 0;
#X connect 5 0 3 0;
#X connect 6 0 3 1;

It should show a simple patch with 3 [osc~], 1 [+~] and 2 [print~ a/b] to analyze the whole thing. Each [osc~] is the start of an audio-line/ -path!!
(The order in which you connect the [Bng]-button to the [print~]'s is unimportant since all data (from data-objects) is computed before, or rather between, each audio-cycle.)
Now to get this clear:

1. Delete & recreate the most left [osc~] "A". Hit the bang-button. Watch the console, it first should read "a: ..." then "b: ..."
2. now do the same with the second [osc~] "B" in the middle... Hit bang & watch the console: first "a: ..." then "b: ..."
3. and once more: del & recreate the third [osc~] "C" and so on. Now the console should read first "b: ..." then "a: ..." !

to "1)": the last (most recent) [osc~] created is "A", so the audio-path, lets call it "pA", is run at first. So [print~ a] is processed first, then [print~ b].

to "2)": last [osc~] is "B". Now we have an order from first (oldest) to last (most recent) [osc~] : C,A,B !!
So now fist "B" & "pB" then "A" & "pA" then "C" & "pC" is processed. But "pB" ends at the [+~], because the [+~] waits for the 2nd input ("C") until it can put out something. Since "C" still comes after "A" you again get printed first "a: ..." then "b: ..." in the console!

to "3)": last [osc~] is "C", so the order is like "A,B,C". So at first "C" & "pC" is processed, then "B" & "pB", this makes [+~] put out a signal to [print~ b]. Then "A" & "pA" is processed and the [print~ a] as well. -> first "b: ..." then "a: ..."

This works for "cables" too. Just connect one single [osc~ ] to both (or more) [print~]'s. Hit bang and watch the console, then change the order you connect the [osc~] to the [print~]'s..

That's why the example works if you just recreate the 1st object in an audio-path to make it being processed at first. And that's why I'd like to have some numbers (according to the order of creation) at the objects and cables to determine the order of processing.
But anyways, I hope this helps.
And plz comment if there is something wrong.

WinXP Pro SP3
Pd version 0.42-5
17-Jan-07 version of PortMidi

hey everyone,

I've been working with PD vanilla 0.42-5 - PortMidi midiout last night, trying to figure out why it wouldn't work with my AKAI MPD 24 properly. Here's what I found:

Patch (as attached:)

240, 71, 0, 104, 49, 0, 11, 8, 0, 0, 72, 97, 108, 108, 111, 32, 32, 32, 247
|
midiout

And to check the results, i used: midiout -> Midiyoke -> MidiOX (all latest versions)

Problem

The message I sent (which was a valid MPD 24 SysEx message, double-checked several times from MidiOX directly) was DEC

240, 71, 0, 104, 49, 0, 11, 8, 0, 0, 72, 97, 108, 108, 111, 32, 32, 32, 247

and should convert have converted to HEX

F0 47 00 68 31 00 0B 08 00 00 48 61 6C 6C 6F 20 20 20 F7

instead, it comes out HEX

F0 47 00 68 31 00 02 08 00 00 52 61 6C 6C 1B 20 20 20 F7

• with 3 wrong HEX pairs.

What happens

I looked a bit at the first number, DEC 11 that should come out HEX 0B but comes out HEX 02

here's how it behaves in reverse engineering:

when i send DEC 0, 1, 2 or 3, it comes out HEX 0
when i send DEC 4, 5 6 or 7, it comes out HEX 1

see table:

DEC .. DEC -> HEX

00 .. 03 -> 00
04 .. 07 -> 01
08 .. 11 -> 02
12 .. 15 -> 03
16 .. 19 -> 04
20 .. 23 -> 05
24 .. 27 -> 06
28 .. 31 -> 07
32 .. 35 -> 08
36 .. 39 -> 09
40 .. 43 -> 0A
44 .. -> 0B

etc.

When you look at the BIN, it becomes obvious what's happening:

DEC (BIN) .. DEC (BIN) -> HEX (BIN)

00 ( 0) .. 03 ( 11) -> 00 ( 0)
04 ( 100) .. 07 ( 111) -> 01 ( 1)
08 ( 1000) .. 11 ( 1011) -> 02 ( 10)
12 ( 1100) .. 15 ( 1111) -> 03 ( 11)
16 (10000) .. 19 (10011) -> 04 ( 100)
20 (10100) .. 23 (10111) -> 05 ( 101)

.. two bits at the end are truncated.

It wouldn't surprise me if we found them somewhere in the other 'wrong numbers' ofthe original message.

When I manipulate the numbers to come out correctly in MidiOX, my MPD 24 will happily accept the sysex and execute it so the probelm is definitely not MidiOx or Midiyoke.

Questions

1. can anyone confirm this?
2. is anyone currently maintaining PortMidi, so this could maybe get fixed?

thanks
groovelastig

http://www.pdpatchrepo.info/hurleur/sysex-conversion_vanilla.pd

I think I have the same problem, on the Mac OSX 10.5.2. I downloaded the source tarball off sourceforge (0.39-3), went to the oscx directory, did ./configure with no problem I noticed, and then make. With make I got this output:

June -d, 2008 @ 01:39:42AM: ~/Documents/projects/boogiepants/Pd-0.39.3-extended/externals/OSCx
[jstoner@erzulie]> make
cd libOSC && make
cc -c -g -O2 -DUNIX -Wall -Wimplicit -Wunused -Wmissing-prototypes -O3  -I../libOSC -I../../pd/src -I../../../pd/src -I../src -I../libOSC -I../../pd/src -I../../../pd/src -I../src  OSC-client.c
OSC-client.c: In function ‘CheckTypeTag’:
OSC-client.c:341: warning: implicit declaration of function ‘printf’
OSC-client.c:341: warning: incompatible implicit declaration of built-in function ‘printf’
ar srv libOSC.a OSC-client.o
ar: creating archive libOSC.a
a - OSC-client.o
rm -f OSC-client.o
cc -c -g -O2 -DUNIX -Wall -Wimplicit -Wunused -Wmissing-prototypes -O3  -I../libOSC -I../../pd/src -I../../../pd/src -I../src -I../libOSC -I../../pd/src -I../../../pd/src -I../src  OSC-timetag.c
ar srv libOSC.a OSC-timetag.o
a - OSC-timetag.o
rm -f OSC-timetag.o
cd src && make
cc -g -O2 -DUNIX -Wall -Wimplicit -Wunused -Wmissing-prototypes -O3  -I../libOSC -I../../pd/src -I../../../pd/src -I../src -I../libOSC -I../../pd/src -I../../../pd/src -I../src -c -o sendOSC.o sendOSC.c
cc -g -O2 -DUNIX -Wall -Wimplicit -Wunused -Wmissing-prototypes -O3  -I../libOSC -I../../pd/src -I../../../pd/src -I../src -I../libOSC -I../../pd/src -I../../../pd/src -I../src -c -o htmsocket.o htmsocket.c
cc -g -O2 -DUNIX -Wall -Wimplicit -Wunused -Wmissing-prototypes -O3  -I../libOSC -I../../pd/src -I../../../pd/src -I../src -I../libOSC -I../../pd/src -I../../../pd/src -I../src -c -o OSC-system-dependent.o OSC-system-dependent.c
OSC-system-dependent.c: In function ‘fatal_error’:
OSC-system-dependent.c:65: warning: implicit declaration of function ‘exit’
OSC-system-dependent.c:65: warning: incompatible implicit declaration of built-in function ‘exit’
cc -bundle -bundle_loader ../../../pd/bin/pd -flat_namespace  -o sendOSC.pd_darwin sendOSC.o htmsocket.o OSC-system-dependent.o -lc -lm ../libOSC/libOSC.a
ld: file not found: ../../../pd/bin/pd
collect2: ld returned 1 exit status
make[1]: *** [sendOSC.pd_darwin] Error 1
make: *** [all] Error 2

any ideas?

/Applications/Pd-extended.app/Contents/Resources/Scripts/../extra/OSC/OSC.pd_darwin: dlopen(/Applications/Pd-extended.app/Contents/Resources/Scripts/../extra/OSC/OSC.pd_darwin, 10): no suitable image found. Did find:
/Applications/Pd-extended.app/Contents/Resources/Scripts/../extra/OSC/OSC.pd_darwin: mach-o, but wrong architecture
OSC: can't load library

this is what i obtain...