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

Update: turns out enabling wifi on the iPad is not necessary after all! See this thread with various discussion throughout on the subject.

@esaruoho said:

Are you.... you're serious? do i really have to have wi-fi on, even if no wi-fi connection, for OSC to work over USB tethering?

Ha, well yes, I am serious! I was sharing the result of beating my head against this problem for 30-40 hours, in the hopes that others might not waste their time in a similar manner. It's entirely possible that there is a better & more reliable method to achieve this connection, I simply shared the solution that worked for me.

This post of yours is from 7 years ago, is this still the case in 2023?

In one of your other current threads I mentioned that I just tested this setup yesterday, and bi-directional OSC over USB is still working for me. Of course these are versions of TouchOSC/studiomux/midimux that I installed 7 years ago, it's entirely possible that there have been breaking changes in these apps since then.

it's a 100% dealbreaker. i don't want wifi on and don't need it for anything.

My solution was to carry a cheap mini wifi hub and just connect my iPad to its network; neither was connected to the internet (nor was my computer) and as far as I could tell no data was actually sent over the wifi network. Again, this was the only way I could figure out how to convince TouchOSC to send OSC over the USB connection. Maybe there's a better way, if you find it please do share your findings!

guess i'm stuck in MIDI over USB?

It did seem like wired MIDI connections were easier to set up when I did this in the past, and it sure seems like that's still an option. I went through the trouble to get OSC working because I'm lazy & grew tired of dividing/multiplying all control data by 127...

@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 I did something similar to what you're trying to do with TouchOSC, although in my case I was specifically using OSC rather than MIDI. It's been years since I've used this setup but here's my old post from when I was setting it up in case any of the info is helpful:
https://forum.pdpatchrepo.info/topic/10184/touchosc-direct-usb-connection-finally-possible-with-midimux

(tldr: I had to turn the iPad's wifi on for the USB connection to work)

Also, my experience was long enough ago that there could be much easier ways to do this nowadays. It looks like there's a new version of TouchOSC that I haven't checked out, so maybe there's an easier way in 2023?

@seb-harmonik.ar Thanks again!

For anyone else who's following:
https://github.com/pure-data/pure-data/issues/1823
https://github.com/MetaluNet/moonlib/issues/20

@seb-harmonik.ar Yes indeed, thank you! The Console app brought the crash report right up.

And I think I may have quickly found the likely culprit: mknob (from moonlib), which crashes if I bring up the help patch. If that's true, I wonder if this should be a bug report for the external itself (perhaps this repo?) rather than Pd? Or might it still be useful for the Pd devs to see this if other externals could also be broken due to a change in Pd 0.53?

One other question: when the time comes, what's the preferred format for submitting a crash log? Paste the entire thing into a Github issue, or is there a cleaner way?

@Load074 Similar (or same) issue for me on macOS Monterey, certain gigantic older patches of mine are crashing Pd 0.53 when trying to open. I've been doing a bit of initial research into how to generate a crash log (which I've never done & have no idea where to begin) for submitting a bug report to Github, but free time is a bit scarce at the moment. Any quick pointers for doing so are welcome!

The only initial thing I could think to do was to start Pd via command line... saw "segmentation fault" but no other clue about what the error might be.

@Metronome I probably experienced somewhere in the neighborhood of 8-10 headphone explosions when I was new to Pd, and possibly suffered some nonzero amount of hearing damage as a result, so I can very much relate to your question.

Ultimately I came to accept this as inseparable from the nature of Pd as a programming language, in that it gives you the raw tools to do pretty much whatever you like (including things that may not be advisable, either for your ears or your computer). Nowadays I always approach any unfamiliar patch (a help patch, demo from this forum, or anything whatsoever) with caution; I always take a look at what's going into [dac~] first, as many of my past unpleasant experiences came from patches where the author simply connected a number box with no defined upper limit directly into the right inlet of [*~] as gain control, meaning that if you mouse directly on the number box to turn up the volume (without shift-clicking), it's quite easy to slip & blast your ears in an instant.

For my own patch, I used zexy's [limiter~], which lets you specify an output limit in dB; you could make an abstraction which wraps such a limiter, and make sure to always add it in before [dac~] as a safety precaution in any patch you open. Or, when opening patches, just watch out for sketchy output levels before turning on DSP, and if necessary edit the patch first (perhaps [*~ 0.1] or [/ 100] or [dbtorms] may come in handy in these situations, if you catch my drift).

It is worth noting though that accidental volume spikes in general are certainly not unique to Pd, and keeping headphone/speaker volume low at first when checking levels is simply good practice with any speaker in any application.

@Kosmas Hi there, I haven't (successfully) used jack on Mac (I'm also on 10.15.7), but this is what I use to run Pd from the terminal:

/Applications/Pd-0.51-3.app/Contents/Resources/bin/pd /Users/*your*/*path*/*to*/*your*/patch.pd```

I also use several flags depending on what other options I want (-nogui, -channels, -audiobuf, etc.), maybe the -audiodev or -jack flags would get things working? I think I've seen some discussion recently on Pd-list/Github about jack & macos, and if memory serves, it isn't a simple solution...

@ricky Hmm, I don't have experience with that particular error, but it's possible your hunch is correct.

The first time an app requests to use the mic, the webcam, access certain directories, etc., the OS will throw a popup at you asking if you want to grant permission. Either way you answer, you can change this later in System Preferences / Security & Privacy / Privacy / Microphone.

If that doesn't work, you might need to do some more searching (this forum, Pd-list, Pd's github, stack exchange, and so on). But I hope the easy solution works out for you!

I'd try creating a [declare -path zexy -lib zexy] in your patch first to see if that loads the library. You can check the zexy readme on github for more info, specifically the part under "making pd run with the zexy external".

@cfry This sounds suspiciously like a known bug in older versions of freeverb, see here:

https://lists.puredata.info/pipermail/pd-list/2009-11/074142.html

I had the same problem years ago when I added an older version of freeverb to my patch, namely that this denormals bug would cause the CPU to grow out of control if the input to [freeverb~] fell silent. The readme in my current version says "Recent changes (1.2.2): fixed the NaN/denormal check", but I haven't actually tested to see if the problem remains. I still have my original workaround in place just to be safe, which is to add a tiny amount of noise to the input signal:

[noise~]
|
[*~ 0.00000001]
|
[freeverb~]

@yannseznec I’m quite familiar with that bullied-by-Apple-to-upgrade feeling.

Pd 0.51-1 is indeed working fine for me on Catalina 10.15.7, aside from the usual shenanigans required to launch third party software (right-clicking & selecting “open” on first launch instead of directly double-clicking on the app icon, granting permissions for microphone, network, directories, etc… feel free to ask if you’re not already familiar with how to do all of this).

I do use zexy, which works fine, but not purest_json or comport. When I upgraded to Catalina, I did have 3-4 external libraries which MacOS refused to allow to run. Some I had to manually grant permission to load in System Preferences / Security & Privacy, others I had to download source code from GitHub & recompile in Xcode. However, if memory serves I did this using Pd 0.50, and I believe the devs have done recent work that allow Pd 0.51 to load older libraries without all of these extra steps. I haven’t tested this since the new release but hopefully this should all work now without the extra hassle.

Oh, and of course if you’re still using anything 32 bit (Pd, externals, or other software), they simply won’t run in Catalina, so it’s worth going through your software library & researching alternatives before diving in head first.

@zigmhount said:

Good advice on the discontinuities. I was kind of hoping that [phasor~] would handle this better than restarting [line~] from 1 to 0, but I suppose that it also just jump from 1 to 0?

Yep. Regardless of whether you're using [line~] or [phasor~] to drive [tabread4~], discontinuities can happen anytime you abruptly jump from one spot to another. This isn't unique to Pd, if you perform edits to a waveform in any DAW without crossfades at the edit points, you will get clicks/pops (unless you get lucky & happen to edit at a zero crossing). So, if the first & last values stored in your array (loop) are not the same & the loop restarts (either beginning a new 0->1 ramp with [line~] or letting [phasor~] wrap around), you'll get a pop unless you use windowing.

In your example, you record the ramp up and ramp down into the array itself, right? Is that not audible when looping the same array over and over? Thanks to this ramp in the array, I guess that [tabread4~] may not click even if started without a volume ramp in, would it?

Yes indeed, that example essentially records the fade in/out into the array, so you wouldn't hear clicks when the loop wraps even without using a window with [tabread4~]. However, note that this is only one of the causes I mentioned... if you're eventually planning to add any playback controls with abrupt changes (such as pause/stop, start from the middle, rewind, jump to a new position, etc), you'll need a fade out before the change and a fade in after the change. FYI, my personal use for recording the fade into the array itself is because I sometimes use a phase vocoder for time stretching of my loops, which seems to misbehave if I have extreme values at the start/end of the array.

And, yes, the windowing can be audible, but it really depends on the nature of the audio that you're recording into the array. I randomly chose a 10ms fade in/out for the example above, but that could be any duration you like (you might want it to be adjustable if you're looping many different types of sounds, to experiment with shorter/longer fade times). There are also ways of shaping the curve of the fades if you really want to minimize their chances of being audible. But even if the fades are obvious, I think you'll still find them to be a million times less strident than a loud speaker pop.

@zigmhount said:

In general, I still hear quite many clicks and glitches when playing

Sounds like the most likely culprit is setting the delay too low in your Pd audio settings, which will lead to dropouts when the CPU isn't able to keep up with Pd's computation deadlines. I can sometimes push it as low as 6ms on my 2016 Macbook Pro if most parts of my patch are switched off, but sometimes I have to bump the delay up to 25+ms if many modules are working hard simultaneously.

The only time I've used Pd on Linux was on a Raspberry Pi 2, which needed at least 50-100ms (if not more) to run even very basic audio patches. I haven't used Jack, so I can't say whether that could cause any glitching trouble. But an easy first step is to increase your delay & see if that helps.

Another possible source of clicks could be discontinuities in the loop waveforms, which seems likely if you're hearing it when your looper wraps around. You'll need to add windowing, or a short fade in/out anytime a loop starts, stops, wraps, or jumps to a new position. And, you also need to take care when using [tabwrite~], otherwise discontinuities can be recorded into your loop. For example, something like this:

@zigmhount Happy to help steer you in the right direction! Indeed, the documentation is rather vague for some objects, and the [block~]/[switch~] object is particularly confusing. Alas, learning to dig for answers outside of the help patches (the html documentation, this forum, Pd-list, etc.) is a big part of learning one's way around Pd, so hats off to you for getting it working so quickly!

I imagine you may have also stumbled across some of the other CPU-saving methods, but might be worth mentioning the [pd~] subprocess object, as well as the option to manually run several other instances of Pd to spread out the load among several processors (since you're already doing so with the separate UI/DSP instances). But [switch~] is definitely the quickest & easiest way that I know of.

@zigmhount Hi there,

You can stop audio processing in specific subwindows/abstractions with [switch~]. All tilde objects ([tabread4~], [phasor~], [*~], [+~], etc.) will calculate their output after every DSP tick unless you switch them off, regardless of whether their output is actively changing (including the cases you mentioned: a [phasor~] at 0hz, or a disconnected tilde object). You won't reclaim 100% of that CPU load, but the savings are quite significant.

Dynamic creation will very likely cause audio dropouts, so if you're trying to avoid glitching, that might not be the route you want to take.

If you do go with [switch~], be sure to ramp up/down the output amplitude of your abstractions, so that you avoid discontinuities. (i.e., ramp down to zero before switching off, and ramp back up to one after switching on)

HTH!

@yealace Hi there, I believe I found this technique in one of @Maelstorm’s patches & adapted it, so I’m a bit fuzzy on the math.

But yes, [cos~] plays a part in creating the window. It’s fed by the same [phasor~] that is driving [tabread4~] (the audio table playback), and generating a slice of the positive part of the sin function ([phasor~] -> [cos~] is equivalent to [sin~]) which is being amplified & clipped to shape the window.

I made a quick attempt to add some calculations that make the length of the window consistent at any playback speed (for example, 25ms fade in / fade out at either end, regardless of whether you’re playing the loop at 0.5x speed or 4x speed). It kinda works but is definitely not accurate at all loop sizes & speeds, so anyone who wants to improve on it is most welcome to do so!

Here's a vanilla version of the patch I posted earlier in this thread, which should be easier to get working if you're just interested in the windowing part:
single_precision_looper.pd

@s.elliot.perez I'm not a coder, but I do get the sense that there will always be certain programming techniques that can be realized faster in code than in Pd.

That said, I feel like my biggest breakthrough in Pd was in learning how to quickly build abstractions. Anytime that you're repeating similar calculations & connecting dozens of cables, you can likely create a new abstraction & realize the idea in a fraction of the time it would have taken you otherwise. I don't think it'll ever be quite as efficient as a few lines of code, but at least will get you much closer.

You can also pull off some fairly advanced trickery with [expr], although I'm not the one to ask about that.