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

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.

I'm looking for a timeline-based software where:

• I can draw (and ideally, record) multichannel automation,
• said automation can then be sent out as OSC data,
• its playback position (and ideally, speed) can be controlled by OSC, MTC or in some other programmable way.

From this page: http://www.ardour.org/osc_control
I see Ardour can be controlled by OSC, and I suppose it can handle automation, but I can't find any mention of whether it can send out OSC data.

IanniX always looked too artsy to me, so if anyone has experimented with it, I'd like to know if it's possible to be precise to a degree where I want it to eg linearly output values from 0.1 to 0.569 over 0.6 seconds?

Anyone familiar with AlgoScore or 'Timeline OSC Sequencer'? I just found these while writing this post - shame on me

BTW, I posted in this section because this is I/O stuff, and I need it to control arduino, video etc, although that's not obvious from the post.... If there is a more appropriate section, please move it at will.

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.

Can I manage 1000 osc with pd ? Is it possible for a computer to run 1000 osc in the same time ?
Can I ask pd to create 1000 osc, to connect each of them with an amplifier whose value will be assign by an algorithm giving a different value for each amplifier ?
For the creation of the osc, can I create an algorithm who will, according to some information I give it (the frequency of each osc must be a multiple of 5, frequency between 100 and 1000), create each osc ? Can I do the same kind of thing for the enveloppe ?

Reaper is brilliant, but it costs a little (if you want it to, you can actually use the free version for quite a long time). There's Audacity as well, that's not as powerful as one would like it to be perhaps.

Me and my band actually do our mastering in Reaper. Its mixer is awesome and the routing matrix is the bomb!

edit: there's no limitations to the free version as far as I know. the only thing being you have to buy it if you want a commercial license. (I think. I'll actually go and check that out and do another edit)

edit2: "Download the full, uncrippled, unexpiring evaluation version of REAPER, and give it a test drive. If it suits you, you'll need a license.

Please see the purchase page for pricing and licensing details."

http://www.reaper.fm/download.php
http://www.reaper.fm/purchase.php

that's all greek to me, sorry.....
maybe an example makes it more clear what i mean:

i have two osc~ objects, the first one, with a frequency of (say...) 120 hz, the second one with a frequency of 155 hz. now i want the first one to be phase synced by the second one, in effect the second osc~ should be forced to reset ist phase 120 times per second. i know, this will cause aliasing, but this is what i'm looking for.
my pd skills are not so good, i have some experience with reaktor, but there, the syncable osc's have an audio input for resets and a phase input where you can set the phase the osc should be set to in case of phase reset.
that's what i'm searching for. someone's got an idea?

okay, i think it should be possible to find out, when a wave decreases like that:

[osc~] <------this is the sync osc
| |
[z~] /
| /
[ -~ ]

but i need to convert the output of the [-~] into a very accurate controlsignal for further processing. since unsig~/snapshot~ allows maximal processing rate of 1000 hz (i think i read something like this...) it's not accurate enough. there's no solution for that?

Total noob to Pd and here to find solutions to get MRMR to send message to Resolume via some kind of patch with Pd.

I think it is a matter of changing the message out of MRMR to a message address that Resolume accepts.

How to go about it with Pd is something I need and don't know how to. I know it is possible, as I see there are patches for OSC to midi. I have tried it OSC to Midi but I want OSC to OSC.

Could someone create a patch for me? I would trully appreciate it.

I don't have the skills to learn and develop at the same time. I am one of those guys that learn faster if I have a working product I can try and understand each module, than trying to build something I have no clue in how it works.

Maybe a simple MRMR osc message parsed to Resolume OSC address would be very useful.

Thanks

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?