Hey,

I've uploaded the Zexy external on the latest version of PD-Vanilla (Pd-0.51-1) on my Mac, (I'm on Catalina) but when I go to add a repack object it still isn't recognised and won't create the object. Any ideas why?

http://puredata.info/Members/zmoelnigbot/software/zexy/2.3.1/zexy[v2.3.1](Darwin-amd64-32)(Linux-amd64-32)(Linux-arm64-32)(Linux-armv7-32)(Linux-i386-32)(Windows-amd64-32)(Windows-i386-32).dek

Best
Jess

@Jona I think the issue with your method is that the value stays the same over the entire block, so using it to drive a function would only output changed values at the beginning of every block.

you could use your method of adding the samples of a block in conjunction with a [tabreceive~] reading from a table that contains every integer from 0 to blocksize-1 and that would work though.
(btw I also have an object in my library [pinb~] that simply outputs the current sample # in the block for situations like this)
also if you do run it at a samplerate of 8000 hz it will take a ~5.5 times longer for rpole~ to not be able to represent than @ 44.1k so in this case it might not be as much of an issue (though obviously a counter that doesn't do that at all is preferable)

of course any method will lose precision between samples, especially if the counter isn't reset to 0 after 2^32 -1 samples (assuming "t" is a 32-bit integer)
in pd-double it would probably be better to use phasor~ with / and *~ to scale phasor to increment 1 every sample, with a period of 2^32 samples. Unfortunately in 32-bit float pd you can only represent up to 24 bits of precision so you can't divide or multiply by 2^32 exactly

A degenerate case that has probably no utility but that i post for fun.

The [block~ 32 2] (reblocked down overlapped twice)???

block.32.2.pd

Notice that here the letters represents 16 samples (64/4). And since it is always complete at each tick just one of them is required. The result is strange. Each DSP vector is sliced in four pieces, and combined. Is it normal. I don't know? But it can be awesome! For what?

TBH I did that kind of thing only to be sure that i didn't make an error while refactoring Pure Data.

[a b c d]  !  [A B - -]
              [- C D -]
              [- - A B]
              [D - - C]

-->       [A+D B+C A+D B+C]

// [block~ 32 2]

BLOCK FREQUENCY+4
BLOCK PERIOD+1
INLET SIZE+64
INLET WRITE+64
INLET HOP+64
OUTLET SIZE+64
OUTLET HOP+16

#+0#

P+0/+64

R+0/+32
W+0/+32
R+32/+32
W+16/+32
R+0/+32
W+32/+32
R+32/+32
W+48/+32

E+0/+64

#+1#

...

Basic upsampling and downsampling is obvious also. The up/down sampling is done before/after (the prologue/epilogue) in anothers buffers. The DSP computation is performed in one shot with the required block size.

// [block~ 32 1 0.5]

BLOCK FREQUENCY+1
BLOCK PERIOD+1
INLET SIZE+32       // Downsampling is done before.
INLET WRITE+32
INLET HOP+32
OUTLET SIZE+32      // Upsampling is done after.
OUTLET HOP+32

#+0#

P+0/+32             // Read 32 samples already downsampled from 64.

R+0/+32
W+0/+32

E+0/+32             // Write 32 samples that will be upsampled to 64.

#+1#

P+0/+32

R+0/+32
W+0/+32

E+0/+32

// [block~ 128 1 2]

BLOCK FREQUENCY+1
BLOCK PERIOD+1
INLET SIZE+128      // Upsampling is done before.
INLET WRITE+128
INLET HOP+128
OUTLET SIZE+128     // Downsampling is done after.
OUTLET HOP+128

#+0#

P+0/+128

R+0/+128
W+0/+128

E+0/+128

#+1#

P+0/+128        // Read 128 samples already upsampled from 64.

R+0/+128
W+0/+128

E+0/+128        // Write 128 samples that will be downsampled to 64.

For reblocked down (e.g. [block~32]) it is rather easy.

At each DSP tick the parent's vector (64 samples) is simply processed right away piece by piece.

// [block~ 32]

BLOCK FREQUENCY+2
BLOCK PERIOD+1
INLET SIZE+64
INLET WRITE+64
INLETHOP+64
OUTLET SIZE+64
OUTLET HOP+32

#+0#

P+0/+64     // Prologue: write 64 samples in the buffer in.

R+0/+32     // Proceed first half part (32 samples).
W+0/+32
R+32/+32    // Proceed secondth half part (32 samples).
W+32/+32

E+0/+64     // Epilogue: read 64 samples from the buffer out.

#+1#

P+0/+64

R+0/+32
W+0/+32
R+32/+32
W+32/+32

E+0/+64

@jameslo yes, @ddw_music was correct. It's a combination of double and single precision (and I edited my last comment, this prediction is consistent w/ the 1st patch at least). The value "conv" in the source code is stored in a t_float, which is generally a 32-bit float these days (though maybe that will change soon..). This is set to 1/samplerate. every sample conv is multiplied by the input frequency (which is also a 32-bit float) and then added as a double to the current phase, which is a double with value 1572864 + actual phase, (1572864 is 3^19, a float value that makes bit 32 of the entire 64-bit double value the 1s place, leaving the remaining 32 bits as the fractional part). Every sample the top 32 bits of the phase are set to the top 32 bits of 1572864, and when the phase is output, 1572864 is subtracted from it.

tldr: the phase accumulator is basically 32-bit fixed-point

@jameslo the phasor~ source was a bit confusing to me at first, it works by setting the upper 32 bits of a double (including the exponent) such that bit 32 of the double represents the "1s" place value, so all of the lower 32 bits represent the fractional part. Then after the correct phase accumulation is added, the magnitude that was added to make all lower 32 bits the fractional part is subtracted from the double in order to output just the fractional part. (and then the upper 32 bits are again set to that value, destroying the non-fractional part)
All of this is done to avoid cpu branching so it can pipeline instructions better (so instead of having to check if the phase > 1, each sample you just set bits to a certain value)

@borelei Wish85.exe *32 is fine if you also see pd.exe *32 or pd.com *32 in the task manager.
That means you are running a 32 bit version of Pd.
For a 64-bit Pd you would see pd.exe and wish86.exe.
It looks like for you mobmuplat is receiving floats just fine...... but they have commas like 1,000
That is weird..... or are they decimal points like 1.000....... hard to see on the screenshot.

@liamorourke I have an idea for a fix which will mean you can send [pdwrapper] a formatting message from the pd patch for each change of message type. I will upload it here asap.
I will then try to automate it but I am not sure it's possible given the various messages that can be sent.
I need to look at why there is an extra float going to the grid and how the /flash command is supposed to work...... so I need to do a fair bit of research in the examples on the Mobmuplat github.
CAN you post a link to where the "flash" is documented please?
I thought feedback was causing the network errors. It is good to know that is the cause.

If you could both zip up and upload your complete pd patch to this thread that would be useful for testing.... even though I cannot do a complete test with an Android device.
David

!

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