@callummalcolm seem to recall the numbers the daisy seed reports from potentiometers are normalized float .. which is just fancy talk to say they range from 0-1 (or maybe more like 0-0.99999)

in that case you can use [+ 1] into [log 2] to convert them to a linear(ish) curve .. its probably good enough for rock and roll.

for other numbers (like the arduino's 0-255) its the same concept, [+ 1] because log is weird, [log 256] which turns it into 0-1, you can add [* 255] again or work with the normalized float

in a sense and at the ranges were interested in its sort of like a fixed look up table, so the log function will either make a linear ramp into log or make a log ramp into linear

and yeah as they mention above the log (audio) taper potentiometer is actually a linear taper with an extra resistor that is then doing resistor math (see https://sound-au.com/pots.htm and https://sound-au.com/project01.htm for a better description).

delay (msec) is to create the total buffer size. Its important for round trip latency where PD is looping the input to the output - the delay (msec) gets added with the block size (which for compatibility with other patches just keep at 64)

Usually JUCE based programs just give you a "block" of audio, PD is more under the hood about the DSP, the 64 block is a ring buffer that the main patch is at (which is why you have to subpatch to reblock) and the delay msec is padding for the CPU.

Normally you only run into it when you have to up the amount with the sine playing in 'Media, test audio and midi' when you first install PD until it stops sounding scratchy

but also theres another patch in the help browser under 7.stuff/tools/latency you can loop back the output of your audio to the in and play around with lowering it. Either with a loopback function on a dac, or like a wire plugged from out ot line or just have the mic and speakers setup where they could cause feedback if turned up too loud. Tests on the internet for mostly vintage DACS doing round trip latency were actually done in PD.

playing around with it I found Intel macs can go down to 3, and prosumer asio (like an old external edirol dac) can go down to the lowest, 2. Its up to the low level driver to give you the real round trip latency.

usually as long as you can get the sine wave to play in Media.. test audio and midi you are good. Its really only for processing audio in with minimal audible latency - super small delays go off the rails the second you really hit the CPU with polyphony, delay lines, small block sizes.

For a while I had it at as low as it was without being scratchy, but as I got into more complicated (and bloated) synth designs I just kept mine at 50 because when it was having problems more latency than that never helped but less could cause stutters/scratchy sounds.

Linux and Windows are usually set by default to 50 or 100 tho I dont have a problem above 23, offhand I think intel macs were set to 5 or 10. the new arm macs can run into a problem where the old default was too small and should have it higher as well. So the real winners were old intel macs.

use callbacks is only for some older audio drivers in linux

pd.exe is the helper utility in windows to process startup flags. it can even run the crash debugging when launched with mingw64

from powershell navigated to the bin folder

.\pd.exe -noprefs -nostdpath mypatch.pd

will work if your mypatch.pd file is also in the \bin folder - otherwise you need to append a path to the patch.

also to note -noprefs and -nostdpath will stop pd from loading any previous settings like the correct sound card and not look in standard paths for extras like rev3~ here

@oid the tclprompt-plugin external might help speed things up https://deken.puredata.info/library/tclprompt-plugin

@atux check out patchstorage, https://patchstorage.com/platform/pd-vanilla/?search_query=loop&tax_platform=pd-vanilla&tax_post_tag=&orderby=modified&wpas_id=search_form&wpas_submit=1 ,

tho there's about a dozen hardware/software listings on https://patchstorage.com that work using pure data patches - the most popular being ones that run on the organelle https://patchstorage.com/platform/organelle/?search_query=loop&tax_platform=organelle&tax_post_tag=&orderby=modified&wpas_id=search_form&wpas_submit=1

the .pd patch format is fairly portable especially if they are made with vanilla abstractions. so minor modifications (like changing to dac~ to hear the audio out with an organelle patch)
but if they use compiled externals the console will complain and you have to track them down and install them, and cross your fingers, in either order, usually using "find externals"

@porres like a raspi4 with a sick graphics card https://pi3g.com/commercial-comparison-nvidia-jetson-nano-raspberry-pi-coral-usb-coral-devboard/ i see it can run nn_tilde https://forums.developer.nvidia.com/t/embedded-realtime-neural-audio-synthesis-using-a-jetson-nano/236044

@zoebreed .pd_linux is an older (maybe just lazier now) way to name compiled extensions that run on linux (same as windows externals can show up as .dll) - .. but only one tho - its not saying arm/arm64/aarch64 for linux on microcomputer (or android, chrome laptop) or amd64/x86_64 for a regular laptop/desktop running linux .. so pure data will try loading it .. but unless its the right CPU it wont work .. the console errors can sometimes be helpful here

it looks like the intel jetson nano runs Jetson Linux which is Arm64 .. assume thats what you have on it? knowing that would help. .. so its compiled externals are (probably) compatible with Raspi 4 and up running Rasbian64 .. arm can be really tricky tho .. saw a download that had this many different versions for debian/ubuntu .. arm armhf armhfp armv7l armv7hl aarch64 based on OS and CPU and the capabilities of the OS ..

the way compiled exernals work - unless you have a cross compiler that can build for another CPU/ARCH and know how to do that on your own - you can only build the external on the operating system and cpu itself. so you'd build cyclone on the intel jetson nano, but if you built it on something else (besides a raspi4 or better running rasbian64) its probably a no go .. really why vanilla abstractions/externals are golden

you can find a lot of .pd_linux used on patches for critter and guitari orac/pocket piano 201/organelle which target microcomputers (inside the instruments) - the only compiled externals in the folder with the patch included will be for the micro - but named .pd_linux and maybe also mac for testing
.. so trying these probably wont work as they all target arm32 ..

here's the one to try putting in the folder with your patch (if its in the same folder as the patch just use [scale] - scale~.zip - I downloaded cyclone(v0.7-0)(Darwin-amd64-32)(Darwin-arm64-32)(Linux-amd64-32)(Linux-arm64-32)(Linux-armv6-32)(Windows-amd64-32).dek from https://deken.puredata.info and renamed it .zip to unzip it

here's a probably vanilla compatible from rj https://github.com/rjdj/rjlib
m_scale-help.pd m_scale.pd (just rename back to m_scale put them in the same folder as your patch and then use [m_scale arg arg arg arg] ..in pure data after changing a prepatched object to another one - you can even hit undo and redo and it will reconnect all the wires for you )

@zoebreed

assuming you are running PD on linux and not doing something with libpd like the bela (although the bela forum has a great thread about compiling externals)..

so because cyclone is a compiled external (opposed to a vanilla external that is an abstraction made up of objects just using pd vanilla) it will only work on the correct OS and CPU

for the OS
mac is darwin .d_
windows is msw .m_
linux is .l_
haiku is?
bsd is?

CPU/ARCH is
_fat = a mac thing - both types of mac (now adays the M1,2,3 and Intel, historically it was for PPC and Intel or 32bit and 64bit intel)
_amd64 = intel/amd/ (regular desktop or laptops)
_arm
_arm64 _aarch64
_riscv someday haha

but ARM is confusing because the raspi3 and earlier were 32bit only but raspi4 can be 32 or 64bit - so 32 or 64 depends on the OS and version of Pure Data..

• (assuming) Linux and ARM which can be called aarch64 / arm7 / arm64 / or arm for 32bit

you can cover your bases tho and stick them all together - compiled externals (if named correctly as we will see) can be together in the same folder so it will run on a mac, or windows, or linux laptop and then on a rasberry pi or jetson nano - pure data does a really good job of looking for the right one

but another tricky thing is where to put them - the easiest way to approach this is to put the compiled externals and their help in the same folder as your patch. you should also be able to put them in a named folder inside the patch /cyclone and call the externals with that folder first [cyclone/>~]

if you download the .dek file at the bottom here - its actually a zip ..

https://deken.puredata.info/info?url=http%3A%2F%2Fpuredata.info%2FMembers%2Fporres%2Fsoftware%2Fcyclone%2F0.7-0%2Fcyclone[v0.7-0](Darwin-amd64-32)(Darwin-arm64-32)(Linux-amd64-32)(Linux-arm64-32)(Linux-armv6-32)(Windows-amd64-32).dek

the easiest thing would be to put all these in the same folder as your patch or just put the ones for the OS and CPU/ARCH you are using

ps if you are just using the [>~ ] signal comparason objects you can use heavylib [>~] = [gt~] .. vanilla abstractions are objectsNamed.pd you call [objectsNamed] and have the same deal with foldering - easiest to keep them in the root of your patch. https://github.com/Wasted-Audio/heavylib

yes. its not a finished object until it has been clicked away from/left somehow,

this is how I get a loadbang to fire after its already been made, I add a space behind it [loadbang ] and when instantiates back to [loadbang] it sends another bang

I guess it just helps to hit the save shortcut more than less.

also your text will be reformatted to pure data's liking;
;
will;
be like enter;
blank space will be obliterated, well as 0's. numbers will be turned into 32 bit floats. so you just end up giving up trying to write 1,000,000

you can cut/paste a text or message object to see what it will look like after you have closed/saved the patch

what you are thinking of is an accumulator - this is from Desigining Sound's free intro http://aspress.co.uk/ds/pdf/pd_intro.pdf - (More about the book at) http://aspress.co.uk/ds/about_book.html

so here is a more complicated one that can do addition and subtraction as well as multiplication and division - doing that involves using two steps to turn off the addition/subtraction or the multiplication/division depending on what you are doing - also the way you had [/ 4] and [* 4] - wont work unless you bang a 1 into them.. its like sending 0 into /4 or *4

complicatedAccumulator.pd

@Dizzy-Dizzy on the EE side - sounds like you might not be interfacing to the arduino in an ideal way, normally you want to wire them pull up just using the arduinos internal resistors, putting a small capacitor across the switches will also filter out a lot of noise.