@ReLLiK Ah!.... thank you for the info.
David.

@ReLLiK That browser problem is 10 years ago now......

@raynovich The simple way is to buy a second-hand router....... a Linksys WRT54 series can be found for about €10...... just for your project.
Then set the router with an SSID name, wireless security etc.
Then as you connect your phones and your computer choose to set static addresses. That will be remembered by the phones and the computer so that when they connect to this router in the future they will always have the same IP address.
Set them to "connect automatically".
So when you go out to a show and turn on the router all the devices will connect exactly as they did the last time.

Without multicast you will need to set each mobmuplat app to send to a different port (but always the same IP). In [computer_control] you will need a [netreceive] for each of those ports....... and a [netsend] for each phone IP (but always the same port)....
I hope that makes sense.

David.

@raynovich And then wrong again.
I am hoping to find a way around the crazy Mobmuplat internal comms........ but in the meantime here is a working solution....... control.zip

Put control.mmp and control.pd into the mobmuplat folder on your phone.
computer_control.pd runs on your computer.
Set mobmuplat to send to your computer Wi-Fi IP address.
Set computer_control.pd to send to your phone's IP address.

I cannot find any vanilla objects that will talk multicast address...... you would be stuck with 32-bit extended (mrpeach required) if you want to use that.
This with extended will do it (talking with "Tutorial 4 Networking" if you set the network to 224.224.224.1 in mobmuplat....... udpreceive-help.pd

"control" is proof of concept..... simple and probably not the best way..........
David.

@raynovich I had forgotten what I learnt before about Mobmuplat....sorry
It runs a Pd patch on a phone...... but doesn't communicate with anything else over Wi-Fi or Bluetooth.
It just runs a Pd patch on the phone.
So it will not do what you are looking for.

The osc messages in the wrapper are purely for testing the Pd patch before uploading it to the Mobmuplat app.

So you will have to look for free osc apps for apple and android if you don't want to use TouchOSC.

The only other way I can think of at the moment would be to use a VNC app on the phone and share the computer desktop. I will google some more looking for other solutions when I get time.
David.

@raynovich I was involved with some Mobmuplat issues a year ago........ https://forum.pdpatchrepo.info/topic/12748/mobmuplat-grid-not-receiving-message-from-pd/7
The "wrapper" is the important part of Pd that deals with the comms for the Mobmuplat app.
The original "wrapper" was 32-bit MrPeach and I don't know whether it has been updated....
That thread might help..... it was a bit long but got there in the end.
There are some patches toward the end that worked for a "grid" and you could use for testing in Vanilla.
David.

@ricky I think that is just to work out a good window size with enough samples in it but not too many,
The relationship between a semitone interval and frequency is a ratio....... discovered long before digital audio when "samplerate" might have referred to wine tasting (a bit before cocktails too........).
As I said I could be wrong but I cannot see anything in the patch and cannot imagine how the samplerate could be relevant to the [phasor~] frequency.
Sorry about the "arguing"..... and thank you for the link. I always thought Millers book was a real paper thing, and didn't know it was online.
David.

@ricky It's [- 1] because the exponent of 0 (no shift) is 1 but the tape head has to be stationary (no rotation = 0) for playback at normal speed......
And [* -1] because (although it seems wrong until you really think about it) the tape head has to be turning backwards relative to the tape (negative values for [phasor~]...) for the pitch to increase (positive transposition values).
There is no point arguing with the patch because it works as expected.......

[cos~] windows the output so that amplitude sums are "sort of" ok (with the in and out of phase bits) and the vertical edge of the [phasor~] saw is declicked.
And of course the change of delay gives the rotating read head effect.

@katjav gave it a lot more thought here........ https://www.katjaas.nl/pitchshift/pitchshift.html
I could be wrong but I don't see why the samplerate would be part of the calculation (it isn't)...... as all variables are relative.
David

@ingox Yes it looks like Mobmuplat can post messages now so it is an option.
@raynovich Bluetooth range could be a problem on stage..... and especially off stage if they wander about.
David.

@raynovich I imagine they could have either Android or iPhone devices (hopefully not windows as there are fewer options).
TouchOsc is available for both at a small cost ($5?). and layouts can be made easily. Labels can receive messages and their contents and colours can be changed from Pd.
Buttons, faders knobs xy pads etc can also have their colours and labels changed with messages from Pd and can be used to control functions in Pd and also send midi messages.
There can be multiple pages of controls and labels.
The only other extra apart from the laptop running Pd is a Wi-Fi router for the communications.
Layouts for the panels for their phones can be sent from your computer to their phones over the Wi-Fi once they have TouchOSC installed.

If they are musicians or VJ's they might already have the app for controlling Logic, VIZ, FL Studio, Live, BeatMachine etc..... https://osculator.net/forum/forum/support/mobile-apps-ios-android/touchosc-layouts/page3.......
David.