Reblocking under the hood
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.
Reblocking under the hood
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
[samphold~] noise, [phasor~] noise, round-off error, or ?
@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
[samphold~] noise, [phasor~] noise, round-off error, or ?
@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)
mobmuplat grid not receiving message from pd
@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
Recommended Pitch Detection Object?
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
Recommended Pitch Detection Object?
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.
possible deken bug + general question on dependencies
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
i/o-errors in pd
Have you given Pd root priority (chmod 4755)?
why should I do that? this would make pd run as root always right?
pd already runs with realtime priority, as far as I can see:
$ pd -rt &
Jack: JackClient::SetupDriverSync driver sem in flush mode
Jack: JackLinuxFutex::Connect name = jack_sem.1000_default_pure_data
Jack: Clock source : system clock via clock_gettime
Jack: JackLibClient::Open name = pure_data refnum = 4
Jack: JackClient::PortRegister ref = 4 name = pure_data:input0 type = 32 bit float mono audio port_index = 7
Jack: JackClient::PortRegister ref = 4 name = pure_data:input1 type = 32 bit float mono audio port_index = 8
Jack: JackClient::PortRegister ref = 4 name = pure_data:output0 type = 32 bit float mono audio port_index = 9
Jack: JackClient::PortRegister ref = 4 name = pure_data:output1 type = 32 bit float mono audio port_index = 10
Jack: JackClient::Activate
Jack: JackPosixThread::StartImp : create non RT thread
Jack: JackPosixThread::ThreadHandler : start
Jack: JackClient::kBufferSizeCallback buffer_size = 256
Jack: JackClient::Init : period = 5804 computation = 100 constraint = 5804
Jack: JackPosixThread::AcquireRealTimeImp priority = 5
Jack: JackClient::ClientNotify ref = 4 name = pure_data notify = 2
Jack: JackClient::kActivateClient name = pure_data ref = 4
Jack: JackClient::Connect src = system:capture_1 dst = pure_data:input0
Jack: JackClient::ClientNotify ref = 4 name = pure_data notify = 18
Jack: JackClient::ClientNotify ref = 4 name = pure_data notify = 18
Jack: JackClient::Connect src = system:capture_2 dst = pure_data:input1
Jack: JackClient::Connect src = pure_data:output0 dst = system:playback_1
Jack: JackClient::Connect src = pure_data:output1 dst = system:playback_2
Jack: JackClient::ClientNotify ref = 4 name = pure_data notify = 18
Jack: JackClient::ClientNotify ref = 4 name = pure_data notify = 18
$ ps al | grep pd
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
0 1000 1212 746 -7 - 259980 183892 - SLl pts/0 0:19 pd -rt
0 1000 1214 1212 20 0 58984 24812 - Sl pts/0 0:02 wish /usr/lib/pd/tcl//pd-gui.tcl 5401
0 1000 1216 1212 -9 - 2308 796 - S pts/0 0:00 /usr/lib/pd/bin/pd-watchdog
0 1000 1311 746 20 0 15064 3088 - R+ pts/0 0:00 ps al
...