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

If I may weigh in (on both the pitch detection & 32/64 topics):

I have tried all three of the aforementioned objects, and personally found [helmholtz~] to work best for my uses. I can't say I was extremely scientific in my comparisons, but I generally got the sense that it performs a bit better than [sigmund~].

When I first began migration from extended to 64-bit vanilla, all of the 32-bit externals I was using needed to be replaced, and [helmholtz~] was the one I missed the most. I replaced it for a while with [sigmund~], but eventually I went & compiled a new [helmholtz~] from source against 64-bit vanilla, which is working fine.

Now, as for comparing performance of 32 vs 64 bit Pd in general (very much FWIW... I'm on MacOS, not Windows, and I have no technical knowledge to back these observations up): a couple years ago I did test my most CPU-intensive patch in both 32 and 64 bit vanilla, and found a modest ~15-20% CPU performance boost (according to the load meter) when using 64-bit. I remember seeing some discussion of this on the Pd-list a while back, it might have been this thread. I did not compare memory usage between versions, so I can't speak to that.

Hi,

not sure if this is a bug. Don't wanna noobishly spam to the devs' bug reports pile but this needs to be clarified. Is it a deken issue or on the repository or what?

Some searches for externals in the 64-bit version of PD vanilla for windows (I'm on windows 10) the deken search (in the menu: Help -> Find externals) don't return results while the same externals (in some cases) can found on the 32-bit version. Some externals are neither found in the 32- nor 64-bit version. Additionally - as a marker that something is wrong here - PD does not output the line

[deken]: No matching externals found. Try using the full name e.g. 'freeverb'.

which is the case for truly non-existing names (like searching "sdfsdfsdf").

Example of external found as expected on 32- and 64-version:
cyclone

Example of external found as expected on 32- but NOT on 64-bit version:
moonlib

Example of external found neither on 32- or 64-bit version:
apple

What I'm most eager to find out is whether, say, the moonlib external is just not compiled for 64-bit windows and therefore is not found or whether it should be found and just isn't (which hints more towards a bug).

Does anyone have an idea? I'm not completely new to PD but not up to date at all with its development. It seems the current version 0.49 vanilla is the first to have a 64-bit windows version.

kind regards

Anyone else having this problem?
I recently installed 64-bit Pd to try it out and some cyclone objects where no longer creating so I updated it with deken

(version is: cyclone v0.3rc1.dek
Upoaded by lucarda @ 2018-09-28 00:09:15)

I cannot get any of these objects to create on 64-bit pd

so then I tried the same thing in my 32-bit version of pd that I have installed separately this time the cyclone version was:
cyclone-v0.3rc1-(Windows-i386-32)-externals.zip
Uploaded by porres @2018-06-28 04:10:47

with the same sad but curious result.

Perhaps @Porres has an idea of what is going on?
(by the way great work getting all those Max 7 objects cloned over!)

Any suggestions appreciated
I would really like to be able to get my patches to work and also would be great to test these new objects..

currently what I have done is merge the Pd-extended cyclone
(version v0.0.extended-(Windowsi386-32)-externals.zip
uploaded by chr15m @ 2015-07-30 15:42:43
with the new one from Porres in order to run my older patches. Of course none of the new objects work in this situation, but this works ok
on my 32-bit Pd (which is version 0.48.1).

Hi everyone,

I am comming to you today because i want to make a project live !.
This project work with pureData and some external pd object :
fluid~ , freeverb~..

My objectiv is to install a 32 bits version of pureData to make external pd work.

I tried these solutions :
Multi arch ubuntu 64 bits host

• On a 64 bits ubuntu
  - add i386 arch
  - update , dist-upgrade..

Then when installing : $> apt-get install puredata:i386
This package is no more available :
These packet a replacing it :

puredata-utils puredata-utils:i386 puredata-extra:i386 puredata-core:i386
puredata-core puredata-dev puredata-doc puredata-extra puredata-gui

So i installed

$> apt-get install puredata-utils:i386 puredata-extra:i386 puredata-core:i386 puredata-gui

pureData is now installed. But when i run it i have this message :

ALSA lib conf.c:3357:(snd_config_hooks_call) Cannot open shared library libasound_module_conf_pulse.so
ALSA lib control.c:954:(snd_ctl_open_noupdate) Invalid CTL hw:0
ALSA card scan error

Still i can use the debugger and hear sound..

When running my stido project using some object like :
udpReceive or udpSend...

i got this on the initialisation (you can see also all the pd objects used) :

import mrpeach/routeOSC
... couldn't create
 import mrpeach/udpreceive
... couldn't create
 import mrpeach/udpsend
... couldn't create
 import mrpeach/packOSC
... couldn't create
 import mrpeach/unpackOSC
... couldn't create
 import flatspace/prepend
... couldn't create
 import flatspace/prepend
... couldn't create
 import moocow/sprinkler
... couldn't create
 import cyclone/speedlim
... couldn't create
./libs/fluid~.pd_linux: libreadline.so.5: cannot open shared object file: No such file or directory
 fluid~
... couldn't create
 freeverb~
... couldn't create
beware! this is xeq 0.1, 3rd beta build... it may bite!
./

So its not working ^^

Solution 2 - Docker

I was thinking : maybe i can just make a puredata container with all the 32 bits libs, So i tried to find some puredata 32 bits image. But nothing.. And Docker is a little tricky with 32 bits container as he didn't provide any support yet.

Still its possible to run 32 bits linux on it .. i found some 32 bits images on the net, but no way how to create one..

If someone has a solution please..

I am working as a volunteer on this project because i believe on it. I have no time yet to update the pd engine for 64 bits..
This project is helping disabled people and your respons will help me so much to provide them a long term support for this software

If you wanna take a look at the project http://orguesensoriel.com

Thank you a lot,

Damien

I've just opened this tar.gz file downloaded via deken

motex-v0-0extended-(Darwin-i386-32)(Darwin-PowerPC-32)(Darwin-x86_64-32)-externals.tar.gz

and it contains system.pd_darwin, So when you get Deken sorted [motex/system] may also be an option for macs

Hi lads and lasses,

I am an ex-mac user using pd 32 bit vanilla with zexy and gem libraries (manually installed).
I have recently changed to Windows 10 and in spite of efforts perusing forums and troubleshooting myself I can't seem to get the same kind of installation.

The problem (elaborated):

I want to install pd vanilla onto my windows 10 system, and then manually install zexy and gem libraries (and others in the future).

However, when I had my mac setup I had to install pd 32 bit (as gem was only fully functional on the 32 bit) and the library paths (folder locations for libraries, deken etc) were very different to what they are in windows. Currently I have no idea where to put files on my windows machine to make things work.

This is what it currently looks like at startup (on windows 10, pd vanilla, 0.47.1 64 bit) :

I am now faced with the following problems:
-I cannot find a 32 bit version of PD for my windows machine (so that I can run gem smoothly, assuming that is still the way it needs to be)
-I can't get deken to work, I have tried putting the deken plugin folder and master folder in various folders of program files but I keep getting error messages when I try and download a library (see yellow writing towards the bottom of the screenshot) when I go Help>Find Externals:

[that error followed the selection of a folder for the library to go:]

-Zexy and gem also won't load during startup with the startup flags (well that is because I can't find any place to save the library during the Find Externals command, but I have the startup flags in place for when deken does work).

So can anyone show me the error in my ways and better yet, the right path?
I need 32 bit pd for windows (I think for gem), the folder I need to put deken into , and the folders that I have to save the 'Get External' library downloads from.
Thanks in advance!

There are deken packages for MacOSX, Windows and three Linux variants. The version is V1.2.2. Alternately you can download it from http://puredata.info/Members/fjkraan/software/freeverb~/1.2.2/

The Mac version shows up as:
freeverb~-v1.2.2-(Darwin-ppc-32)(Darwin-i386-32)(Darwin-X86_64-32)(Sources)-externals.tgz

WinXP Pro SP3
Pd version 0.42-5
17-Jan-07 version of PortMidi

hey everyone,

I've been working with PD vanilla 0.42-5 - PortMidi midiout last night, trying to figure out why it wouldn't work with my AKAI MPD 24 properly. Here's what I found:

Patch (as attached:)

240, 71, 0, 104, 49, 0, 11, 8, 0, 0, 72, 97, 108, 108, 111, 32, 32, 32, 247
|
midiout

And to check the results, i used: midiout -> Midiyoke -> MidiOX (all latest versions)

Problem

The message I sent (which was a valid MPD 24 SysEx message, double-checked several times from MidiOX directly) was DEC

240, 71, 0, 104, 49, 0, 11, 8, 0, 0, 72, 97, 108, 108, 111, 32, 32, 32, 247

and should convert have converted to HEX

F0 47 00 68 31 00 0B 08 00 00 48 61 6C 6C 6F 20 20 20 F7

instead, it comes out HEX

F0 47 00 68 31 00 02 08 00 00 52 61 6C 6C 1B 20 20 20 F7

• with 3 wrong HEX pairs.

What happens

I looked a bit at the first number, DEC 11 that should come out HEX 0B but comes out HEX 02

here's how it behaves in reverse engineering:

when i send DEC 0, 1, 2 or 3, it comes out HEX 0
when i send DEC 4, 5 6 or 7, it comes out HEX 1

see table:

DEC .. DEC -> HEX

00 .. 03 -> 00
04 .. 07 -> 01
08 .. 11 -> 02
12 .. 15 -> 03
16 .. 19 -> 04
20 .. 23 -> 05
24 .. 27 -> 06
28 .. 31 -> 07
32 .. 35 -> 08
36 .. 39 -> 09
40 .. 43 -> 0A
44 .. -> 0B

etc.

When you look at the BIN, it becomes obvious what's happening:

DEC (BIN) .. DEC (BIN) -> HEX (BIN)

00 ( 0) .. 03 ( 11) -> 00 ( 0)
04 ( 100) .. 07 ( 111) -> 01 ( 1)
08 ( 1000) .. 11 ( 1011) -> 02 ( 10)
12 ( 1100) .. 15 ( 1111) -> 03 ( 11)
16 (10000) .. 19 (10011) -> 04 ( 100)
20 (10100) .. 23 (10111) -> 05 ( 101)

.. two bits at the end are truncated.

It wouldn't surprise me if we found them somewhere in the other 'wrong numbers' ofthe original message.

When I manipulate the numbers to come out correctly in MidiOX, my MPD 24 will happily accept the sysex and execute it so the probelm is definitely not MidiOx or Midiyoke.

Questions

1. can anyone confirm this?
2. is anyone currently maintaining PortMidi, so this could maybe get fixed?

thanks
groovelastig

http://www.pdpatchrepo.info/hurleur/sysex-conversion_vanilla.pd

Hi everyone

My Max license dried out recently, so here I am in the PD forum. I've been patching for years in Max/MSP so PD feels very familiar. So far Im very impressed with everything.

MY PROBLEM:
Im sending a UDP message from a game engine (called Unity). The message is a string that have been encoded into a byte array using System.Text.ASCIIEncoding (.net/c#).

When I received this message in Max, the byte array was automatically converted into a string again. PD needs some help with this. How do I convert the byte array back into a string?

I get this:
48 32 49 54 46 53 32 48 46 49 48 56 54 51 49 51 32 48 46 49 57 53 56 57 50 57 32 48 46 49 56 48 56 52 54 57 32 45 48 46 48 55 49 53 54 50 54 56

Where I wanted somthing like this:
"theNerveNum 2 theTime 7612 theVelocity 0.76 theCenterDistance 0.23"

I use the "udpreceive" object for recieving the UDP message by the way.

Any help is much appriciated
~ce