@whale-av yes, copying a selceted file in win-file-browser does full path in clipboard...

I think sending via pdsend is slick. And I believe and hope and am interested in if Pd receives it without [netreceive].

Otherwise, opening a [netreceive] patch with a startup-flag (in terminal or preferences or in a script) should do the trick:
https://forum.pdpatchrepo.info/topic/13895/opening-a-patch-inside-another-patch-by-filename/2

@beep.beep - i'm running fully usb-tethered with all wi-fi bluetooth mobiledata off. can you have a look and see if this will solve your "OSC only works with wi-fi" issue?

@esaruoho Confirmed! Using your clues I was able send OSC over USB with wifi disabled. Nice to discover that my hacky workaround is no longer necessary! I’ve updated my other TouchOSC thread to point back to our present thread here, if there’s more to discuss on this subject please continue to do so here instead of replying to multiple threads, it makes it quite difficult for others to follow over time.

When I connected my iPad to my Mac & ran “arp -a” in the Mac’s terminal, I only saw one listing: the iPad’s IP address (unlike your screenshot, where you had many entries). This did enable me to at least send from Pd to TouchOSC, but since no IP was listed for my Mac I couldn’t send in the other direction.

Then — for reasons unknown — after fiddling with netsend/netreceive for a bit, “arp -a” then returned a 2nd entry for “broadcasthost (255.255.255.255)”. I’m not a networking expert but some quick searching indicates that this IP can be used to broadcast messages over a local network, so I tried entering 255.255.255.255 for “Host” in TouchOSC and voila, I can send to Pd! This also works the other way with “connect 255.255.255.255 9000” into [netsend -u -b], which successfully sends to TouchOSC on port 9000. I don’t know if there’s an efficiency downside to using a broadcast IP versus a direct IP, but if not this seems to simplify things a lot!

@ddw_music looking at your earlier comment, I didn’t know about netreceive’s -f flag either, that’s great to know! I tried your autoconnect logic and it works nicely, although of course it still requires the iPad to be configured correctly before doing its magic. I guess if there’s truly no harm in leaving TouchOSC’s host set to 255.255.255.255 and “broadcasting” all outgoing OSC data, maybe that’s about as close to zero-config as one can get?

edit: the above tests were done with a 2016 Macbook Pro and iPad 5th gen; when I tried these approaches with my much older 2008 Macbook and iPad 4th gen (both with older OS's) I did not succeed... so this all might be dependent on relatively recent hardware/software.

@whale-av said:

@esaruoho OSC is horrible in Vanilla..... because message headers are symbols but can include numbers that Pd interprets as floats. It is much easier to use the MrPeach externals.

Anyway...... vanilla....... plom.zip using a multifader object.
The index currently played by metro turns green.....
David.
Low-res screenshot.......

ok, so now that i have UDP working, what specifically do i need to modify in plom.zip for the [netreceive] to be patched onto it? it seems that the PD script example you provided does not have anything related to [netreceive] or [netsend] .

@esaruoho said:

I could try again, but it looked like UDP required me to know the IP address of both the laptop and the iPad, and that really threw me (i don't know how to figure out what the IP address of the iPad is, or how to make sure it's always the same, same for macOS).

Ah right, for bidirectional communication.

Actually in the netreceive help file, there is a flag for this: "optional -f flag for from address & port outlet (0.51+)".

Help file example prints from: list ::ffff:127.0.0.1 57120 where ::ffff:127.0.0.1 is an IPv6 address.

So...

... should configure the [netsend] to send to the first address from which messages were received (and I did a quick test, which worked). If you enable "Ping" in TouchOSC, then it will automatically send a message to the computer, which will trigger the "connect" logic right away.

Incidentally, I didn't know about this feature (never used the "from" address in Pd). My thought process was, "Well... this is a very common requirement, so let me have a look at the [netreceive] help patch and see if there's anything about 'from'" -- and toward the lower right, there's a [print from] box. Hm. Then, what's different about the [netreceive] feeding it is that it isn't only "-u -b xxxx" but rather "-u -b -f xxxx"... what's that "-f"? Then, looking up from there a little bit, there's a list of object creation flags, where "-f" is explained.

So the solution exists, and documentation for that solution is actually reasonably clear.

i have maybe an hour every 2-3 days to try and get something going, and also feel a bit like there's no "TouchOSC with PureData for idiots" blog-post for iPad / macOS going on, or at least i haven't been able to find it.

This I fully understand.

Pd OSC sending, like this. It won't send anything until after you push a connect ip.ad.dr.ess port message into the netsend inlet -- as noted above, you can get the parameters for the connect message from [netreceive].

... producing messages like /1/toggle1 1.0 or /1/toggle2 0.0. This type of message format is what you need to change a control's value on the tablet.

It's also possible to "set" the OSC command path before providing the arguments -- but try the simple way first.

hjh

@esaruoho said:

and also feel a bit like there's no "TouchOSC with PureData for idiots" blog-post for iPad / macOS going on, or at least i haven't been able to find it.

As I mentioned in another recent thread of yours where you were exploring iPad control options, I had some experiences with this type of setup several years ago:
https://forum.pdpatchrepo.info/topic/10184/touchosc-direct-usb-connection-finally-possible-with-midimux

I just tested it & it's still working. (7 years later!) I have midimux & TouchOSC running on the iPad, and studiomux & Pd running on my Mac. As mentioned in my old thread, the iPad must be connected to wifi (any active network, doesn't matter which) in order to send OSC data over the tethered USB connection.

And yes, you will most certainly need to know the IP addresses of the Mac & iPad (for use with [netsend] in Pd, and with TouchOSC on the iPad). I don't know of a way to ensure that they will be persistent, I've always had to reenter them manually every time. Also make sure your in/out port numbers are in order (again, on the Pd side for [netsend] and [netreceive], and on the iPad you can set the in/out port numbers in midimux).

Ah, and finally I'm using [netreceive -u -b] into [oscparse] and [list trim] for receiving in Pd, and [oscformat foo bar etc] into [list prepend send] then [list trim] then [netsend -u -b] for sending out from Pd.

@esaruoho You will need to select UDP client........ not TCP...... to connect to [netreceive -u -b]

Fifo (first in first out) overflowed probably just means the buffer has filled to overflow as it is not managing to send the messages onwards.

For TCP then use [netreceive -b] ...... remove the -u....
David.

@oid said:

@esaruoho If you are trying to save CPU than I would just separate UI and DSP, run the UI in its own instance of PD and DSP in another, communicate between them with [netsed]/[netreceive], there comes a time in PD when you just have to either separate UI and DSP or sacrifice. Beyond that it is difficult to say, I do not know what your needs are and what sacrifices are acceptable. What are your requirements? I can optimize these patches in a dozen different ways but I have no idea if any of them will meet your needs since I do not know what your needs are or even why you are trying to change things beyond a vague notion of there possibly being something better.

ok. i have heard about this UI DSP separation. so.. is it a case of every single slider for instance needs to do a [netsend] to some other abstraction that only does DSP? or have two separate patches altogether, one for UI and one for DSP? sorry, i'm really vague on this.

So, my main painpoints with the current channelstrip is that when I set up 16 "LFOs" to "breathe" up and down the volume slider (which also has slider-color-changing while it is moved from 0 to 1) - when i have more than 4 of these LFO counters cycling from 0...1 on the channelstrips, all sliders stop updating. it might be 4, 8 or 12, but by the time i try to get all 16 of the looper volumes to cycle from 0...1 (my "breather" has a setup of cycling from "min-max every 2 seconds" to "min-max every 60 seconds") -- and that to me makes me think that the UI is not as optimized as possible.

i keep hearing that ELSE library supposedly has some larger crossmatrix/channelstrip that i could use, but i have not looked at it.

so ideally i'd prefer to take the channelstrip even further, i.e. have all effect sends be modulatable (well, that word where the effects have LFO modulation) so i could have even larger more complex things going on where the channelstrips that receive audio from loopers, are sent to specific sends like reverbs, delays and so on. this kind of larger modulation on all parameters would be really useful.

the way the channelstrip is built is that the dwL and dwR go to a separate [diskwrite~] abstraction which i use to record audio. the "p" (and p1-p8) defines that any channelstrip that has p enabled, is sending to all the other loopers - so in that case, any audio that goes to a channelstrip, can be sampled into the 64kb loopers (16 of them).

also i have thechannelstrip labels (i.e. volume slider name) dynamically written to, so i can always have them easily understandable / informative.
here's the "init state". i use bunches and bunches of loadbang -> message -> senders to get them to a specific state. .

one thing i've been toying around as an idea is to incorporate highpass and lowpass filters to the channelstrips, and EQ. but i haven't figured out how to solve the EQ issue so that the single band peak EQ could be incorporated into such a small formfactor ( the width is only 38 and height is 189 so it's hard to conceive how an EQ could be usable there).

i also have for the 16 channelstrip looper instances, BCR2000 + BCF2000 volume slider control and so on. but i'm willing to take the whole setup "to the dock" and rewrite it, if i could be sure that it will be lighter on the cpu..

so yeah, i do only have a vague notion of "maybe it could be better, i'm not sure?".. but i've not yet seen much netsend + netreceive stuff so i'm not entirely familiar how it could be done and how much i need to rewrite (i.e. does everything need to be netsend+netreceived with a complete split of DSP and UI, to reap the benefits, or can i just try it with the 16 loopers and see what happens?

@romulovieira-me In your Pd/bin folder you will find an executable.... pdsend.exe for windows...... or pd.darwin or pd.linux (I think) for other os's.
You can tell Lua where to find it (maybe just copy it into a folder that Lua uses), and call it within your script.
In Pd you would then use [netreceive] to receive the message.
It will probably be a lot easier than creating a socket in Lua.
I don't know Lua.
You would use pdsend (in Python) and [netreceive] (in Pd) like this........ https://guitarextended.wordpress.com/2012/11/03/make-python-and-pure-data-communicate-on-the-raspberry-pi/
You will need to work out how to script the Python equivalent in Lua.
David.

@60hz You might be able to redirect a comport to your cheap usb device.
It is possible in windows using.......
NET USE COM1: //pc_name/printer_share_name /persistent:yes
The usb device has to be shared first......
https://superuser.com/questions/923426/how-to-map-a-virtual-com-port-to-a-physical-usb-port
The proviso about plain text would not bother you for a dmx dongle.

Further down the same thread you will see a link to https://ftdichip.com/drivers/vcp-drivers/
..... and on that page the virtual drivers for windows.
They mention "D2XX Direct drivers" are included...... and I have a very vague recollection that it is they that do the FUDI stuff.
They only mention windows....... and then further down the page are drivers signed by Apple, and quite a few others.

The virtual drivers should make the device appear as a comport.
You can see on Amazon that a few people needed these virtual drivers to make the device you have work with FreeStyler....... where they then select Enntec DmxPro as the output.

In Freestyler selecting the Enntec is essentially choosing to communicate through a comport rather than through a driver interface.
When you select the DMX Pro in Freestyler it asks which comport (years since I have used it... but pretty sure)
David.

P.S. I forgot to mention yesterday that you could send your data directly from the RPI using Python (maybe Python is already involved) and call pdsend....... probably pdsend.linux which is in the Pd folders somewhere.
That would send directly over Ethernet to a [netreceive] on your computer.
Approximate usage..... https://guitarextended.wordpress.com/2012/11/03/make-python-and-pure-data-communicate-on-the-raspberry-pi/
I assume (I do that a lot) that
pdsend (your computer IP address):(port) would send correctly...... something like pdsend 192.168.1.33:3000 would send to [netreceive 3000] on your computer.

You mentioned an Ethernet shield...... does your RPI not have an Ethernet port built in ?...... I thought they all have one.

@KMETE The rpi can also communicate with Pd using pdsend..... probably pdsend.linux in the Pd distribution. You could call pdsend in your Python code (probably copy it into a folder where python can find it).... and send a trigger message..... usb_connect 1 to a [netreceive] object in your patch.
When the message arrives in Pd use that to trigger the "open" connection of [comport].
Example code....

In the case of the above code you would use [netreceive 3000] in Pd.
David.