Hi -- I realize this is a common topic, but... I looked at a few of the forum threads about this, and I think I tried their recommendations, but I'm still having only partial luck.

Some years ago, I had created a patch using pd-extended. I now need to revive the patch, but pd-extended is withdrawn(!) so I have to retrofit it for pd-vanilla.

Success: I found all of the cyclone objects and rewrote them as "cyclone/..." and those seem to be OK.

Failure: I'm using the mrpeach OSC objects (packOSC, unpackOSC, send/receiveUDP). I tried mrpeach/packOSC, net/packOSC, and mrpeach/net/packOSC, and none of them work.

I do find it a bit perplexing that I added mrpeach into the path and loadlib sections (as I had done for cyclone), and I verified the exact location on my system, and it's correct in the configuration file, but pd still complains about it and the objects are not available. Typical user expectation would be that you add a path and it would load from all subdirectories under the path. Obviously Pd has a different policy, but none of the forum threads explain what that is, just give a few hacks to get around it.

Anyway, thanks in advance for advice.

hjh

Also, adding "-lib mrpeach" to startup flags doesn't change the situation.

@ddw_music Does........ -lib C:/usr/lib/pd/extra/mrpeach/mrpeach (i.e. the complete path (is your drive C:/...?) help?
Putting the complete path can work, because otherwise it could be looking for (for example) pd/usr/lib/pd/extra/mrpeach/mrpeach
I assume you already have an [import mrpeach] object in your patch.
You could try a path definition in the patch as well...... [declare -path C:/usr/lib/pd/extra/mrpeach]

If all else fails then use my abstractions in a path that Pd is pointed to. They should work for you (your mrpeach objects will create, but will in fact be my vanilla abstractions which do the same job). Let me know if you need any others.
David

"/usr/lib" is a standard Linux path. I would expect C: to confuse Pd when running in Linux.

But, omitting C: and having "flags: -lib /usr/lib/pd/extra/mrpeach" in .pdsettings, I still get:

cyclone: can't load library
mrpeach: can't load library
/usr/lib/pd/extra/mrpeach: can't load library

[import mrpeach] says:

[import] 1.3
written by Hans-Christoph Steiner hans@eds.org
compiled on Jun 17 2011 at 10:45:22
compiled against Pd version 0.43.0
[import]: ERROR: can't load library in mrpeach

I appreciate the abstractions, and I might try them later.

I can't shake the feeling that something is fundamentally broken about library loading in Pd. My main audio programming platform is SuperCollider. In SC, I can go to Preferences > Interpreter, click [+] next to the box for include paths, add a directory, exit preferences, then Language > Reboot interpreter, and the new classes are there. I think it's a reasonable assumption for Pd to be able to go to Edit > Preferences > Path and > Startup, add a directory which actually exists in the file system and which contains Pd objects, and it should work.

https://puredata.info/docs/faq/how-do-i-install-externals-and-help-files/

^^ This page appears to claim that all libraries under /usr/lib/pd/extra will be loaded, or at least available for loading. That is not happening.

I've also seen the online that many other people have had the same problem. So, if in this thread we can find a proper solution, then we can help many people instead of just working around it.

hjh

Or, is perhaps the problem that Ubuntu Studio installs Pd 0.46.7 and also installs externals for 0.43.0?

hjh

@ddw_music Did you try an automatic install through "Deken"?

"Help" "Find externals" from the Pd menu.
If that does not work then mrpeach might need to be compiled against your system....
It is old and links are broken, but..... https://forum.pdpatchrepo.info/topic/6439/compiling-mrpeach-osc-on-beagleboard-under-ubuntu .... suggests that compilation is necessary without a Deken version already uploaded.
David.

@whale-av thanks for the tip. I had tried a deken download yesterday, but that didn't work either.

Then I found https://github.com/reduzent/pd-mrpeach, which seems to be the version of the sources used for deken. cd pd-mrpeach/net && make gives me a slew of .pd_linux files. But, after that, all of the following still fail:

• path4: /home/dlm/share/pd/pd-mrpeach
• path4: /home/dlm/share/pd/pd-mrpeach/net
• [import mrpeach]
• [import mrpeach/net]

So it seems mrpeach is now a dead library, unless somebody else has other advice. If that's the case, it should probably be removed from distributions. It's misleading (and really quite frustrating for users) to have a "mrpeach/" entry in the help browser when you can't use it.

So my remaining alternatives seem to be:

• I think I'm only using the OSC objects from mrpeach. Somebody else just told me that there are core objects now for OSC. (I'm pretty sure when I created the patch before, mrpeach was recommended but perhaps the core objects have improved in the last, ummhhh, 5 years lol.)

• If all else fails, now I see there's purr-data.

Thanks for the help!
hjh

@ddw_music I don't know if this helps in your case but I've found that some libraries are compiled for 32-bit, and so using Pd 64-bit won't recognise those externals, and therefore you have to use Pd 32-bit. Perhaps you could give that a try.

Yes there are built-in objects for OSC in Pd 0.48 that were't available before, so it might be easier to adapt your patch to use those instead.

Hi @ddw_music ... what was the error when you used deken? I downloaded yesterday pd-0.48.1 (in OSX) and successfully installed mrpeach from deken....

you might want to start by using declare instead of import, which was an external which was distributed with the extended fork of pd, which was abandoned five or so years ago. and on that note, extended was a fork of the main pd distribution, so backwards compatibility doesn't really even enter the picture here at all, but if you are making comparisons then I think you'd have a difficult time making the argument that supercollider has introduced fewer breaking changes in that timeframe, at least if you aren't comparing apples to donuts.

also, you say that you are retrofitting your patches for vanilla, so, I guess I would have to interpret that as meaning you are using a version of pd that is more than five years old, which might be the source of at least some of your problems. I would suggest updating to the just released 0.48-2, as there are a number of features and improvements that have been implemented since back then, though perhaps I'm just being too generous in my interpretation of your comments, and your problem is instead that you are having some difficulties understanding the difference between pure data and the various forks which, with the exception of pd2lork (which is itself a fork of extended), are all no longer being developed.

I have literally started using pd today, coming from a maxmsp environment and aiming to use pd on a raspi as well. i've basically stumbled upon the same issues as ddw_music, where all desired libraries function as expected, apart from [mrpeach]. however, what is most riddling, is that the individual objects DO work, once I open the helpfiles which contain them. that is, routeOSC has udpreceive and pipelist in it and thus these objs will work thereafter in a session (not however unopened ones). I cannot find anything in the helpfiles which explains, let alone justifies this behaviour. in order to use the mrpeach library i would thus have to open the respective helpfiles individually first before I can use the objects, or, prepend the library name for every object I instantiate like mrpeach/routeOSC — then they work.
although I am basically crisp new to pd~ this does seem very odd, can anyone reproduce?

I see that I dropped this thread from a year ago -- sorry about that.

teo523: "what was the error when you used deken? I downloaded yesterday pd-0.48.1 (in OSX) and successfully installed mrpeach from deken...."

Oh, deken gives error messages? It appears that its only feedback to the user is a one line message in the status bar at the bottom of the window, which soon disappears and then cannot be recovered.

jtg3:

I think you'd have a difficult time making the argument that supercollider has introduced fewer breaking changes in that timeframe

Touche (though most of my code has survived version upgrades pretty well).

also, you say that you are retrofitting your patches for vanilla, so, I guess I would have to interpret that as meaning you are using a version of pd that is more than five years old, which might be the source of at least some of your problems.

The objective at the start of this thread was to take an old patch of mine, which had worked under pd-extended, and make whatever changes to that patch are necessary so that it would work on an up-to-date pd-vanilla (i.e. currently-maintained version). As this is a reasonable thing to do, I think most of your two posts to me were not quite useful.

Those changes ended up being:

• cut the dependency on cyclone by replacing [gate] with a subpatch.
• cut the dependency on mrpeach by using [netsend] and [netreceive].

So the only remaining dependency is GEM.

@oni_shogun "I have literally started using pd today, coming from a maxmsp environment and aiming to use pd on a raspi as well. i've basically stumbled upon the same issues as ddw_music, where all desired libraries function as expected, apart from [mrpeach]. however, what is most riddling, is that the individual objects DO work, once I open the helpfiles which contain them"

That sounds like a different problem from mine. After a year, you would be justified in opening a new thread to focus on your problem, rather than possibly getting details mixed up with mine.

In any case, my experience was that I couldn't get mrpeach to work at all and I had to abandon it. So maybe that will save you some time.

hjh

@oni_shogun Way back in time we used to declare the MrPeach library in a patch by putting an object [import mrpeach] in the main patch.
Only [declare] is now available for setting the environment variables for a patch.
That should always work but can be a problem when sharing a patch, so it is probably best to use [declare -stdlib] which should have the best chance of conformity.
David.