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.

mostly nostalgia out of me - the cz 101 felt unique, probably out of its limitations. really wanted to slide through all its settings in real time or at least send sysex to randomize a patch while it was playing.

what interesting now about casio's take on FM/PM with 'phase distortion synthesis' is after listening to it do its thing through a patch randomizer I'm surprised how many real instruments it will attempt to sound like in kind of a plastic toy way. does a lot with very little

@lacuna figured it out, the crash happens in windows with 0.54.1 when you try closing the patch after sending [clone] the [resize < message - but only if the amount of voices is different than when it started

& thanks - it wasn't obvious to have a second subpatch connected to [clone] for the oversampling filter

also looking closer I see that all the math for calculating the filter is in J07.oversampling.pd

I have an old 2010 13" macbook pro thats about similar, it kind of chokes compared to a desktop.. but you definitely should be able to run 200 oscs~

its probably the FX - maybe there's a cheaper reverb out there (they use delay lines) or maybe use delay lines more sparingly

it might also be the UI if you have a PD screen full of number boxes, sliders, other things that are giving feedback all the time, reducing the amount of responsive UI can help

if you are using two monitors try just one, definitely close browsers and other apps, turn off the network

but yeah upping the delay msec setting is usually where you go to try and fix it, you're right around the threshold I run into when I jam in netpd with that laptop. theres a patch you can open with your patch running - its called test audio and midi and listen to the sine wave - if it crackles or sounds weird while your patch is on try setting the delay msec up until its good.

leave the block at 64 - a lot of stuff expects it to be 64, so that can only cause weirdness.

It isn't as much latency as you think it is because its 64+that setting, as little as 2. this is different than something like JUCE which just says its a power of two buffer. it would be 104 at 40. vs 128 is the lowest usually offered

side note: testing the round trip settings in the extras I was able to set it down to 3 on an intel mac. 2 with asio and a roland dac on a pc. quickly had to turn it up when I started working on complicated patches tho