Previously been using an older MacBook Pro with OSX 10.10, and PurrData, all good.

New MacBook Pro M4 Max, and PurrData v2.19.3 from here... (2.20 was reported as damaged by the OS)...

https://github.com/agraef/purr-data/releases

PurrData v2.19.3 and v2.19.2 work fine, but there's no audio coming in from ~adc.

Opened a DAW, Reaper, set the input channels correctly, and there's audio coming in - to my new MacBook Po M4 Max. So the audio interface - a MOTU, is fine, and set up correctly ...it's just PurrData - there's nothing coming in from ~adc (I tried hooking up all input channels ~adc 1 2 3 4 5 6 7 8, and still nothing). Otherwise midi flows back and forth ok, and audio is sent out to the audio interface (via ~dac), but ~adc is dead ...and just to reiterate Reaper hears the input on those channels fine - but PurrData doesn't.

The audio properties in PurrData are set up fine, the audio interface selected, and multiple channels - so all good there (and I've using PD for many many years).

Anyone come across this - what to do?

Hi there,
I would like to share a project I am working on for a while which might interest anyone who like making physically interactive or reactive installations.
It’s a plug-and-play sensing platform for creative and audiovisual applications, with MIDI, OSC, wireless capabilities and a convenient web interface.
You can turn movement, touch, distance, or other sensors into wireless controllers in seconds.

I developed this project to ease the connection of sensors to audiovisual and music software. After doing that with arduino for years, but encountering so many limitations and struggles, I decided to make and share a much easier, convenient and robust solution for all: the whole project will be open sourced.

The project is called “Pipo Interfaces”. It is still in the making and will be launched as a pre-order campaign on Crowd Supply (a funding platform for open source electronics).
If you are interested, check out the pre-launch page and subscribe to the project updates !

https://www.crowdsupply.com/pipo-interfaces/pipo

You can also check the Insta @pipo_interfaces
Any feedback or questions welcome !

@jameslo said:

I'd still like to know if spaces are legal and possible with [oscformat] though.

I'm a bit surprised to see this, but in fact, according to the OSC spec 1.0, spaces are not allowed in OSC command paths.

https://ccrma.stanford.edu/groups/osc/spec-1_0.html#osc-address-spaces-and-osc-addresses

Each OSC Method and each OSC Container other than the root of the tree has a symbolic name, an ASCII string consiting of printable characters other than the following:

-character-	-name-	-ASCII code (decimal)-
’ ’	space	32
#	number sign	35
*	asterisk	42
,	comma	44
/	forward slash	47
?	question mark	63
[	open bracket	91
]	close bracket	93
{	open curly brace	123
}	close curly brace	125

So Pd has no obligation to support spaces here.

I suppose it depends on the software's OSC handler. SuperCollider doesn't complain (contrary to the OSC spec):

n = NetAddr.localAddr;  // send to myself

o = OSCFunc({ |msg|
    msg.postln;
    o.free;
}, '/test space');

n.sendMsg('/test space', 1);

prints: [ /test space, 1 ]

I did some other tests:

• "symbol patch 1" --> [list fromsymbol]: escape char 92 is not in the ASCII list.
• list "112 97 116 99 104 32 49" --> [list tosymbol]: resulting symbol prints with a backslash. I don't know if the backslash is stored internally, or if it's inserted only for the printed output. A quick look at the source code in x_list.c suggests that the backslash is not stored internally.
• list "112 97 116 99 104 32 49" --> [list tosymbol] --> [list prepend set] --> [list trim] --> [oscformat]: The printed bytes from oscformat do include char 92. But I couldn't see in the source code where the space is being escaped. (This long way around to build the "set" message is to be certain that there's no backslash in my input -- the backslash must be generated internally somewhere..)

So [oscformat] seems to be where the problem is happening -- but the OSC spec makes no promises that spaces will work, so there wouldn't be any justification to log a bug.

hjh

@whale-av said:

I am almost certain that Gui objects in TouchOSC can talk midi and OSC at the same time.
But I doubt that it will communicate over wireless (required for OSC messages) and USB at the same time.

GUI objects in TouchOSC can send Midi and OSC at the same time, and wired USB connection does work for both, no issues. no need for having the iPad on Wi-Fi. just takes a while for TouchOSC on the iPad to realize what the IP address of the laptop is.

The communications between Pd and touchOSC are set in the abstraction [osc-s-r] within the [globpitcharray1] patch in the zip I posted.
There is a TouchOSC layout plom.touchosc in the zip that should be used with this patch (for a test demo).

thanks for breaking this down for me!

You would need to fix the IP address of the Ipad (static address) and use that address for [netsend] and [netreceive] in [osc-s-r] ....... if you ever get over your fear of using Wi-Fi for this.... or just feel like trying it to see what it will do.......

yes, [osc-s-r] is definitely where it's at. thanks for spelling out the [netsend] and [netreceive] to me, cos looking at the screenshot i had, i can now realize where to input 11000 and 11001 for send + receive. the connect portion of the script was throwing me.

i hope i have it right now,

I've written a VST3 plug-in using Camomile+Pd to output groups of control change messages in response to OSC commands. The CC messages are used to turn channels of a Yamaha 01V96i mixer on and off.

On Windows, everything works fine, but on my M2 Mac I'm having strange issues. The plugin receives OSC fine but the MIDI CC it generates is zeroed-out, e.g. when I ask it to send B0 48 7F, the mixer receives B0 00 00. I can run the Pd patch standalone on the Mac and it works fine.

The AU version of my plugin doesn't output MIDI at all and I get an OSC error message in the Camomile console. I tested a different CC generating Pd/Camomile/VST3 plugin on my Mac and its CC messages are also being zeroed out. In contrast, I've written two other plugins that work fine on the Mac: one is a side-chained envelope follower with adjustable release time and the other generates 5 channels of audio in response to OSC messages.

I saw a somewhat old discussion on the Camomile Github site referring to some issues with MIDI CC under VST3 (https://github.com/pierreguillot/Camomile/discussions/260), but I don't recall having issues like this on my old Mac with my CC-generating plugins hosted in REAPER circa late 2020, and I don't see any similar complaints in discussions about PlugData, which I believe uses Camomile under the hood. In case the issue was REAPER, I tried to load the plug-in to Audacity, but Audacity complains that the plugin is incompatible.

I think there's probably a better way to achieve my end goal but wanted to check in with Pd brain trust because I'm sad to think that I've lost this capability. What would you try next?

I'm using REAPER 6.81 as the VST host, Camomile 1.0.7, Pd 0.54.0, and MacOS 12.6.7 on last year's M2 MacBook Pro.

@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 This being a new thread I had forgotten that you were using a wired USB connection.
Yes, that means that you are limited to midi only.
It will be possible to talk both ways but you will be limited to 127 steps for your controls.. so much lower resolution than OSC...... unless you use the pitchbend in TouchOSC and the [bendin] and [bendout] objects in Pd..... see below.
Also I am not sure that you can change data and colour for the same GUI through midi, but you could use 2 GUI's.... a fader and a "push" button or text label above or on top of the fader for the colour.

The 127 step resolution can be improved using pitchbend to get 14-bit resolution...... https://vi-control.net/community/threads/touchosc-has-been-updated.110551/page-3

I am almost certain that Gui objects in TouchOSC can talk midi and OSC at the same time.
But I doubt that it will communicate over wireless (required for OSC messages) and USB at the same time.

So the patch I posted was for OSC wireless....... sorry.
The communications between Pd and touchOSC are set in the abstraction [osc-s-r] within the [globpitcharray1] patch in the zip I posted.
There is a TouchOSC layout plom.touchosc in the zip that should be used with this patch (for a test demo).
You would need to fix the IP address of the Ipad (static address) and use that address for [netsend] and [netreceive] in [osc-s-r] ....... if you ever get over your fear of using Wi-Fi for this.... or just feel like trying it to see what it will do.......
David.

Hi, I'm looking for someone with a deeper understanding of PD and audio synthesis to help me understand why my patch sounds the way it sounds. I don't know why the audio is generated this way. I don't know if it is because of some expected behavior of square waves and the math behind it, or if it is because of some quirk of PD and the way I'm generating the square wave. If you think you can help, please stay with me, I don't know who to go to or what to study to help me understand this.

I was attempting to make a square wave from scratch, I saw some tutorials and I know there are more "proper" ways of doing this, but the simplest I could think of was -1 and 1 alternating. The osc I built is a metronome with a route alternating between -1 and 1 at a given hertz. But the result doesn't sound like a single square wave, there are some harmonics, almost like having senoidal waves mixed with the square wave.

Experimenting, I noticed a cycle of the resonances going from 1hz to 1378.125hz where it completely stops, like zero hz, or one tick in several, several minutes. Other cycles multiples of this frequency exist, like this:

n=1378.125hz
Cycle0 = 1 to n* 2^0
Cycle1 = n*(2^0) to n*(2^1)
Cycle2 = n*(2^1) to n*(2^2)
Cycle3 = n*(2^2) to n*(2^2)
? Cyclen= n2^(n-1) to n(2^n) ?

C0 and C1 are very similar, with subtle differences, but inside of C2 it seems like 2 times C0 or C1 (I didn't check it, but it sounds like this). Inside C3 there are 3 times, and next, C4, 4 times, and so on, the same cycle but more times and faster in each power of two.

I have made a patch that makes it easy to clone the osc to generate each Cycle. For example, clone 10 times to get audio files from C0 through C9.

Where do the resonances come from? Why these cycles exist? Are they some kind of harmonic series? Why 1378.125hz? Is this expected from the math, or is it a quirk result of some PD object (like inputing very low numbers to the metronome)? Does someone understand why this is happening?

main_oscs_cycles.pd
square-from-scratch-osc.pd used in main
square-from-scratch-osc-lineramp.pd used in main

@cfry I used the Arduino library "OSC" by Adrian Freed and in it there are lots of Arduino examples and a few Pd examples using the mrpeach library (which I don't use anymore since vanilla started talking OSC natively). If you can give me a better sense of what you are having trouble with I can make a more helpful example, e.g. do you need bidirectional messaging? What data are you passing (if any)? What Arduino library would you prefer to use (I see there are more now than when I started)? is it over WiFi or ethernet or something else?

But maybe this example from the OSC lib is all you need: UDPSendMessage.ino

Edit: I found my knockoff ethernet shield and wrote this Arduino sender and Pd receiver,. It includes an example of how to route numbers in the OSC path. Hope this helps.
testOSCSend.ino
osc rcv dump.pd

Agreed. I've been playing with Camomile and have written effects plug-ins in Pd that have sent and received MIDI and/or OSC and have been controlled by DAW automation, so that's substantial integration. I defer to @emviveros regarding the support for externals since I'm just a vanilla guy. I've also written effects plug-ins with side-chains for Reaper, so that means your Pd VST patches can be modulated by audio signals from other Reaper tracks. Reaper itself supports fairly complete OSC and MIDI controls (both input and output) so that's another layer of integration that's possible. And for completeness I suppose one should mention using MIDI and audio loopback software, but the flexible MIDI and audio routing capabilities in Reaper seem to make them unnecessary.