oh wow yes that works @ingox many many thanks!

I don't know why -path works better than -lib, I wonder if it's a PD-wide issue, or just specific to this library?

Either way, it works, I won't complain

thanks a bunch. I'll be sharing this patch I'm working on really soon...

ah ha, yeah I can imagine it would create issues. I suppose if I only use these externals for this project then I could remove them from my standard externals folder to avoid conflicts. However it sure feels wrong (and doesn't really address the underlying question of why this is happening!)

thanks!

The library was installed using the library manager...I did this with my other external libraries and they work fine, so I'm pretty certain my path preferences are ok.

That's a good idea to copy the externals into the patch folder. Seems a bit strange to have to do that for these externals only, but whatever works is ok with me.

I'm working on a patch at the moment using purest_json, which works well once it is up and running.

A weird thing, though: the purest_json objects will not load when I open my own patch first. If I go into the externals folder and open a help file for one of the objects (rest-help.pd, for example), the objects will load perfectly. I can then close that patch and re-open mine, and the objects will work fine.

I have a [declare -lib purest_json] object in the patch already, for what it's worth.

I have to repeat this process each time I quit and relaunch PD. I don't have to do it for any other externals I have installed. Any ideas how I can avoid this?

I'm wondering if anyone can tell me whether it's normal that my patch using the pof library is making my CPU spike like crazy?
I'm on OS X, 10.14, PD 0.50-2.
Essentially when I open a patch that uses [pofjson] it will start using over 50% of my CPU, according to Activity Monitor, even before I've done anything. I'm not doing anything intensive, just loading and accessing a single small JSON file.
It makes my computer fan go crazy, of course, and it just generally seems wrong.
Another, possibly related thing - when I quit PD when I have a patch with a pof object in it, I get a notification from the OS saying that "pd quit unexpectedly".
Any ideas? I'm wondering if it has something to do with the extra window that opens up when I load a pof object (I believe this is for rendering oFx stuff, but since I'm not doing anything visual it feels unnecessary).

Hi folks.
I'll be in Montreal for a week at the beginning of March for a mini research residency. I was wondering if anyone here knows about any interactive sound/art/music meetups or groups or anything that I could drop in on? French or English speaking is fine (so long as you tolerate my eurofrench accent).

Or, indeed, if anyone just wants to show me a cool craft brewery and talk about pure data

Otherwise, any suggestions on things to do that might be of interest to someone who is into interactive sound and music?

@whale-av @beep-beep that's great, thanks!

Hello!
Is it possible to put a variable name in the "Send symbol" and "Receive symbol" fields in a UI object property window?

using an Hslider, for example, I don't seem to be able to fill those fields with "slider_$0", this gets automatically changed to "slider_0".

I know I can connect a message box to the slider to change this, and I know I can send a remote message with a message box (using the receive symbol), but I'd love to be able to just fill those two automatically with a unique number for each patch.

Does the question even make sense?

(sorry not to respond to your email yet - I'll respond on here instead!)

scraping data from the internet isn't the easiest thing to do in Pd, in my experience, I think the solution @andresbrocco describes is probably best. It's (annoyingly) easier to do in Max/MSP, but hey.

In terms of sensor data from a micro controller - in my experience the most dependable way is to code a Teensy micro controller to function as a USB MIDI device. You connect any sensors you like to the Teensy, and convert the data into MIDI CC or note values, which can be read in PD using the [notein] or [ctlin] objects. This is a really solid and relatively straightforward method...I have some generic code for doing that on my website: https://www.yannseznec.com/works/teensy-usb-midi-controller-code/

For most things you can just use a Teensy LC, which is only like £12 or something.

The primary downside of that method is that the resolution is quite low, because MIDI is so old fashioned. So it means that whilst you can get 12 bit analog input resolution on the Teensy (values between 0-1023), you have to downsample that to go from 0-127 for it to work over MIDI. so that kind of sucks. However, if you really want high resolution you can be clever with numbers and split them up and send them over several CC controller numbers or something, which is sort of how NPRN works.

Hope that helps!

@RetroMaximus thanks!