Purr Data 2.9.0 is now available:
- made autopatch y-offset distance settable in the Preferences dialog
- added a stop-gap shortcuts file for (most) current keybindings
- ported [drawtext] from Pd Vanilla
- enabled keyboard entry for [drawsymbol]
- split out l2ork version from s_stuff.h to make development easier
- fixed autorepeat suppression for [key], [keyup], and [keyname] on
Windows (thanks to Aayush Surana)
- fix for changing the midi api under linux and a few other fixes for
OSS midi handling (thanks to Pranay Gupta)
- fixed menu item in Pd console for OSX
- fixed bug handling certain encodings in filenames under Windows
(thanks to Alv_ro on the Pd Forum for reporting it)
- fixed regression with Windows when socket connection gets reset
(e.g., when quitting from the terminal with <ctrl-c>)
- fixed bug where array name wasn't getting updated
Please report bugs here:
If @jancsika has a moment maybe he can explain where things stand.
In Purr Data you can do
[floatsize(---[pdinfo]to tell whether floats are single or double precision. The current possible outputs from that message would be "32" for single precision or "64" for double precision.
Pd and the externals you use have to be compiled for one or the other-- you can't mix the two floatsizes. Currently Purr Data is able to build itself and most externals with floatsize=64, but some libraries need to be revised so that they work. So atm we're shipping floatsize=64 Purr Data with just the core and a few convenience libraries. I named these builds "purr-double-trouble" since they don't yet ship with all the externals.
That is all a separate issue from the arch for which a piece of software is compiled. "Arch" means chip architecture and uses nicknames like "i32", "x86_64", "arm64". For general purpose computers these generally divide into two broad categories-- the ones which the hardware shuttles data around in groups of 64 bits, and hardware that shuttles data in groups of 32 bits. Some 64-bit platforms even let you run old stuff built for a 32-bit hardware in a special compatibility mode.
So to clarify: you can have:
- single-precision Pd built for a 32-bit arch
- single-precision Pd built for a 64-bit arch
- double-precision Pd built for a 32-bit arch
- double-precision Pd built for a 64-bit arch
For future reference-- try the following flags to debug loading a library:
pd -noprefs -nostdpath
Run it from the same directory where your external binary is located.
Doing this prevents loading any libs or setting any paths from the preferences file. It also disables the standard paths making it more likely you will properly load your external binary instead of one located in a random place on your hard drive.
We've gotten some interest in several of the project ideas listed so far. We've gotten some inquiries about porting K12 mode, making an ASCII art parser, and even the ambitious idea of porting Purr Data to the web.
If anyone has project ideas to add, feel free to post them here or make a merge request for the repo which is here.
I'll just repeat my pitch that if you write Pd patches and are in college, you should definitely apply for GSoC with us.
You might try the raspbian deb for Purr Data:
You'll have fewer dependencies because it doesn't ship Gem.
There should be a package called gdebi. If you install that you can right-click on the deb and install it. Then gdebi should install all the required dependencies (if it can).