Controlling Pd from another programme
@Worik Not sure what you are looking for.....
If you want to open a patch from the command line you can open Pd and a patch with a batch file...... in windows it would look something like this....
"C:\Program Files (x86)\pd\bin\pd.com" -path C:\Users\David\Desktop\PDMusic\Minx -path C:\Program_Files_(x86)\pd\extra\readanysf~\ -r 44100 -asio -nomidi -audioindev 20 -audiooutdev 15 -inchannels 32 -outchannels 22 -audiobuf 2 -blocksize 64 -callback -nosleep -open Minx_Run.pd
exit`
which on my system opens Minx_run.Pd and tells Pd where to find it........ \PdMusic\Minx
It also sets a load of command line switches...... to set up audio for this very specific instance (useful!).
There will be similar methods in other os's.
When you want to close the patch (and Pd) you kill the Dos window that the batch file created.
Messages can be sent to Pd to close a specific patch..... but another patch will have to be open (probably the one receiving the message) or Pd will terminate.
It can be done from within the patch but its complicated........ https://forum.pdpatchrepo.info/topic/11710/closing-patches-without-pd-crashing-hopefully-in-an-elegant-way ...... and not easy.
If you want to keep Pd open and control from another program........ then as @seb-harmonik.ar describes........ but the menuclose message might crash Pd if another patch (any patch) is not open........ https://forum.pdpatchrepo.info/topic/4063/close-patch-window-command-object
Anyway, it is cleaner to use a second patch to receive your messages and close the desired patch.
David.
"Things I wish I had known when I started Pd"
@ddw_music Sending to {value] is really what got me, they were getting their bangs before their new values arrived. I I had just copied part of the patch into a sub-patch to clean things up, this moved that bit to the end of the patch and caused the problems. If I had realized what had happened earlier I would have just moved the sub-patch in a text editor but I tried to fix things in pd and made it a hopeless mess. I have now adopted using sub-patches to structure order creation and using wires between them for all timing critical information, this means I can edit the subpatch and keep everything in that sub-patch in the proper place in the chain regardless of my editing. I knew about the order creation for sends and receives and the patch worked perfectly before that edit which changed nothing about the physical patch, I just did not understand the long term consequences and what would happen when I change things a year down the line. Wasted a few hours and ended up redoing the patch from the ground up, but it is greatly improved and more robust regarding minor edits years down the line breaking it and even if they do I will only have to deal with a small subpatch as I no longer have all the sends to communicate between the sub-patches. Lesson learned.
Can't install purr-data on Manjaro
Hey, I'm trying to get purr-data to work on my fresh Manjaro XFCE install, but it does not work. Any help is greatly appreciated!
$ yay purr-data
7 aur/purrdata-faust 0.18-1 (+0 0.00)
Run Faust signal processors in Pd, Purr-Data version
6 aur/purrdata-pure 0.26-1 (+0 0.00)
Loader plugin for the Pure programming language, Purr-Data version
5 aur/purrdata-lv2plugin-git 25.e00f302-1 (+0 0.00)
LV2 plugin host for Pd, Purr-Data version
4 aur/purrdata-mdnsbrowser-git 8.88d2b0c-1 (+0 0.00)
Zeroconf service advertising and discovery for Pd, Purr-Data version
3 aur/purrdata-touchosc-git 44.443c793-1 (+0 0.00)
A TouchOSC MIDI bridge for Pd, Purr-Data version
2 aur/purr-data-git 2.12.0.r4366.6d94e10b-1 (+2 0.00)
Jonathan Wilkes' nw.js variant of Pd-L2Ork (git version)
1 aur/purr-data 2.12.0.r4346.aeb24d89-1 (+6 0.03) (Out-of-date: 2021-06-17)
Jonathan Wilkes' nw.js variant of Pd-L2Ork (git version)
==> Packages to install (eg: 1 2 3, 1-3 or ^4)
==> 2
:: There are 2 providers available for gconf:
:: Repository AUR
1) gconf 2) gconf-gtk2
Enter a number (default=1): ==>
:: Checking for conflicts...
:: Checking for inner conflicts...
[Aur:2] gconf-3.2.6+11+g07808097-10 purr-data-git-2.12.0.r4366.6d94e10b-1
2 gconf (Build Files Exist)
1 purr-data-git
==> Packages to cleanBuild?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==> a
:: Deleting (1/1): /home/olav/.cache/yay/gconf
:: (1/2) Downloaded PKGBUILD: gconf
:: (2/2) Downloaded PKGBUILD: purr-data-git
2 gconf (Build Files Exist)
1 purr-data-git (Build Files Exist)
==> Diffs to show?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==>
:: (1/2) Parsing SRCINFO: gconf
:: (2/2) Parsing SRCINFO: purr-data-git
==> Making package: gconf 3.2.6+11+g07808097-10 (Wed 09 Feb 2022 10:23:23 PM CET)
==> Retrieving sources...
-> Cloning gconf git repo...
Cloning into bare repository '/home/olav/.cache/yay/gconf/gconf'...
==> Making package: purr-data-git 2.12.0.r4366.6d94e10b-1 (Wed 09 Feb 2022 10:23:23 PM CET)
==> Retrieving sources...
-> Cloning purr-data-git git repo...
Cloning into bare repository '/home/olav/.cache/yay/purr-data-git/purr-data-git'...
remote: Enumerating objects: 21531, done.
remote: Enumerating objects: 63399, done.
remote: Counting objects: 100% (1852/1852), done.
remote: Compressing objects: 100% (641/641), done.
remote: Total 21531 (delta 0), reused 0 (delta 0), pack-reused 21531
Receiving objects: 100% (21531/21531), 10.88 MiB | 9.46 MiB/s, done.
Resolving deltas: 100% (17681/17681), done.1 KiB | 704.00 KiB/s
-> Found 01_xml-gettext-domain.patch388.01 KiB | 704.00 KiB/s
-> Found gconf-reload.patch
-> Found gconf-merge-schema
-> Found gconfpkg
-> Found gconf-install.hook
-> Found gconf-remove.hook
==> Validating source files with sha256sums...
gconf ... Skipped
01_xml-gettext-domain.patch ... Passed
gconf-reload.patch ... Passed
gconf-merge-schema ... Passed
gconfpkg ... Passed
gconf-install.hook ... Passed
gconf-remove.hook ... Passed
remote: Total 63399 (delta 1106), reused 1786 (delta 1052), pack-reused 61547
Receiving objects: 100% (63399/63399), 177.19 MiB | 5.71 MiB/s, done.
Resolving deltas: 100% (33721/33721), done.
-> Downloading nwjs-sdk-v0.24.4-linux-x64.tar.gz...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 86.7M 100 86.7M 0 0 3966k 0 0:00:22 0:00:22 --:--:-- 8404k
==> Validating source files with md5sums...
purr-data-git ... Skipped
==> Validating source_x86_64 files with md5sums...
nwjs-sdk-v0.24.4-linux-x64.tar.gz ... Passed
==> Making package: gconf 3.2.6+11+g07808097-10 (Wed 09 Feb 2022 10:24:19 PM CET)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Updating gconf git repo...
Fetching origin
-> Found 01_xml-gettext-domain.patch
-> Found gconf-reload.patch
-> Found gconf-merge-schema
-> Found gconfpkg
-> Found gconf-install.hook
-> Found gconf-remove.hook
==> Validating source files with sha256sums...
gconf ... Skipped
01_xml-gettext-domain.patch ... Passed
gconf-reload.patch ... Passed
gconf-merge-schema ... Passed
gconfpkg ... Passed
gconf-install.hook ... Passed
gconf-remove.hook ... Passed
==> Removing existing $srcdir/ directory...
==> Extracting sources...
-> Creating working copy of gconf git repo...
Cloning into 'gconf'...
done.
Switched to a new branch 'makepkg'
==> Starting prepare()...
/home/olav/.cache/yay/gconf/PKGBUILD: line 30: patch: command not found
==> ERROR: A failure occurred in prepare().
Aborting...
-> error making: gconf
And
yay purr-data
7 aur/purrdata-faust 0.18-1 (+0 0.00)
Run Faust signal processors in Pd, Purr-Data version
6 aur/purrdata-pure 0.26-1 (+0 0.00)
Loader plugin for the Pure programming language, Purr-Data version
5 aur/purrdata-lv2plugin-git 25.e00f302-1 (+0 0.00)
LV2 plugin host for Pd, Purr-Data version
4 aur/purrdata-mdnsbrowser-git 8.88d2b0c-1 (+0 0.00)
Zeroconf service advertising and discovery for Pd, Purr-Data version
3 aur/purrdata-touchosc-git 44.443c793-1 (+0 0.00)
A TouchOSC MIDI bridge for Pd, Purr-Data version
2 aur/purr-data-git 2.12.0.r4366.6d94e10b-1 (+2 0.00)
Jonathan Wilkes' nw.js variant of Pd-L2Ork (git version)
1 aur/purr-data 2.12.0.r4346.aeb24d89-1 (+6 0.03) (Out-of-date: 2021-06-17)
Jonathan Wilkes' nw.js variant of Pd-L2Ork (git version)
==> Packages to install (eg: 1 2 3, 1-3 or ^4)
==> 2
:: There are 2 providers available for gconf:
:: Repository AUR
1) gconf 2) gconf-gtk2
Enter a number (default=1): ==>
:: Checking for conflicts...
:: Checking for inner conflicts...
[Aur:2] gconf-3.2.6+11+g07808097-10 purr-data-git-2.12.0.r4366.6d94e10b-1
2 gconf (Build Files Exist)
1 purr-data-git
==> Packages to cleanBuild?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==> a
:: Deleting (1/1): /home/olav/.cache/yay/gconf
:: (1/2) Downloaded PKGBUILD: gconf
:: (2/2) Downloaded PKGBUILD: purr-data-git
2 gconf (Build Files Exist)
1 purr-data-git (Build Files Exist)
==> Diffs to show?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==>
:: (1/2) Parsing SRCINFO: gconf
:: (2/2) Parsing SRCINFO: purr-data-git
==> Making package: gconf 3.2.6+11+g07808097-10 (Wed 09 Feb 2022 10:23:23 PM CET)
==> Retrieving sources...
-> Cloning gconf git repo...
Cloning into bare repository '/home/olav/.cache/yay/gconf/gconf'...
==> Making package: purr-data-git 2.12.0.r4366.6d94e10b-1 (Wed 09 Feb 2022 10:23:23 PM CET)
==> Retrieving sources...
-> Cloning purr-data-git git repo...
Cloning into bare repository '/home/olav/.cache/yay/purr-data-git/purr-data-git'...
remote: Enumerating objects: 21531, done.
remote: Enumerating objects: 63399, done.
remote: Counting objects: 100% (1852/1852), done.
remote: Compressing objects: 100% (641/641), done.
remote: Total 21531 (delta 0), reused 0 (delta 0), pack-reused 21531
Receiving objects: 100% (21531/21531), 10.88 MiB | 9.46 MiB/s, done.
Resolving deltas: 100% (17681/17681), done.1 KiB | 704.00 KiB/s
-> Found 01_xml-gettext-domain.patch388.01 KiB | 704.00 KiB/s
-> Found gconf-reload.patch
-> Found gconf-merge-schema
-> Found gconfpkg
-> Found gconf-install.hook
-> Found gconf-remove.hook
==> Validating source files with sha256sums...
gconf ... Skipped
01_xml-gettext-domain.patch ... Passed
gconf-reload.patch ... Passed
gconf-merge-schema ... Passed
gconfpkg ... Passed
gconf-install.hook ... Passed
gconf-remove.hook ... Passed
remote: Total 63399 (delta 1106), reused 1786 (delta 1052), pack-reused 61547
Receiving objects: 100% (63399/63399), 177.19 MiB | 5.71 MiB/s, done.
Resolving deltas: 100% (33721/33721), done.
-> Downloading nwjs-sdk-v0.24.4-linux-x64.tar.gz...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 86.7M 100 86.7M 0 0 3966k 0 0:00:22 0:00:22 --:--:-- 8404k
==> Validating source files with md5sums...
purr-data-git ... Skipped
==> Validating source_x86_64 files with md5sums...
nwjs-sdk-v0.24.4-linux-x64.tar.gz ... Passed
==> Making package: gconf 3.2.6+11+g07808097-10 (Wed 09 Feb 2022 10:24:19 PM CET)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Updating gconf git repo...
Fetching origin
-> Found 01_xml-gettext-domain.patch
-> Found gconf-reload.patch
-> Found gconf-merge-schema
-> Found gconfpkg
-> Found gconf-install.hook
-> Found gconf-remove.hook
==> Validating source files with sha256sums...
gconf ... Skipped
01_xml-gettext-domain.patch ... Passed
gconf-reload.patch ... Passed
gconf-merge-schema ... Passed
gconfpkg ... Passed
gconf-install.hook ... Passed
gconf-remove.hook ... Passed
==> Removing existing $srcdir/ directory...
==> Extracting sources...
-> Creating working copy of gconf git repo...
Cloning into 'gconf'...
done.
Switched to a new branch 'makepkg'
==> Starting prepare()...
/home/olav/.cache/yay/gconf/PKGBUILD: line 30: patch: command not found
==> ERROR: A failure occurred in prepare().
Aborting...
-> error making: gconf
[olav@AMD-Computer ~]$ yay purr-data
7 aur/purrdata-faust 0.18-1 (+0 0.00)
Run Faust signal processors in Pd, Purr-Data version
6 aur/purrdata-pure 0.26-1 (+0 0.00)
Loader plugin for the Pure programming language, Purr-Data version
5 aur/purrdata-lv2plugin-git 25.e00f302-1 (+0 0.00)
LV2 plugin host for Pd, Purr-Data version
4 aur/purrdata-mdnsbrowser-git 8.88d2b0c-1 (+0 0.00)
Zeroconf service advertising and discovery for Pd, Purr-Data version
3 aur/purrdata-touchosc-git 44.443c793-1 (+0 0.00)
A TouchOSC MIDI bridge for Pd, Purr-Data version
2 aur/purr-data-git 2.12.0.r4366.6d94e10b-1 (+2 0.00)
Jonathan Wilkes' nw.js variant of Pd-L2Ork (git version)
1 aur/purr-data 2.12.0.r4346.aeb24d89-1 (+6 0.03) (Out-of-date: 2021-06-17)
Jonathan Wilkes' nw.js variant of Pd-L2Ork (git version)
==> Packages to install (eg: 1 2 3, 1-3 or ^4)
==> 2
:: There are 2 providers available for gconf:
:: Repository AUR
1) gconf 2) gconf-gtk2
Enter a number (default=1): ==> 2
:: Checking for conflicts...
:: Checking for inner conflicts...
[Aur:2] gconf-gtk2-3.2.6-5 purr-data-git-2.12.0.r4366.6d94e10b-1
2 gconf-gtk2 (Build Files Exist)
1 purr-data-git (Build Files Exist)
==> Packages to cleanBuild?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==> a
:: Deleting (1/2): /home/olav/.cache/yay/gconf-gtk2
:: Deleting (2/2): /home/olav/.cache/yay/purr-data-git
:: (1/2) Downloaded PKGBUILD: purr-data-git
:: (2/2) Downloaded PKGBUILD: gconf-gtk2
2 gconf-gtk2 (Build Files Exist)
1 purr-data-git (Build Files Exist)
==> Diffs to show?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==>
:: (1/2) Parsing SRCINFO: gconf-gtk2
:: (2/2) Parsing SRCINFO: purr-data-git
==> Making package: purr-data-git 2.12.0.r4366.6d94e10b-1 (Wed 09 Feb 2022 10:40:58 PM CET)
==> Retrieving sources...
==> Making package: gconf-gtk2 3.2.6-5 (Wed 09 Feb 2022 10:40:58 PM CET)
==> Retrieving sources...
-> Cloning purr-data-git git repo...
Cloning into bare repository '/home/olav/.cache/yay/purr-data-git/purr-data-git'...
-> Downloading GConf-3.2.6.tar.xz...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 1523k 100 1523k 0 0 1610k 0 --:--:-- --:--:-- --:--:-- 1610k
-> Found gconf-merge-schema
-> Found gconfpkg
-> Found gconf-reload.patch
-> Found gconf-install.hook
-> Found gconf-remove.hook
-> Found 01_xml-gettext-domain.patch
-> Found dbus-dontspew.patch
-> Found gsettings-data-convert-fix-invalid-schema-path.patch
==> Validating source files with sha256sums...
GConf-3.2.6.tar.xz ... Passed
gconf-merge-schema ... Passed
gconfpkg ... Passed
gconf-reload.patch ... Passed
gconf-install.hook ... Passed
gconf-remove.hook ... Passed
01_xml-gettext-domain.patch ... Passed
dbus-dontspew.patch ... Passed
gsettings-data-convert-fix-invalid-schema-path.patch ... Passed
remote: Enumerating objects: 63399, done.
remote: Counting objects: 100% (1852/1852), done.
remote: Compressing objects: 100% (641/641), done.
remote: Total 63399 (delta 1106), reused 1786 (delta 1052), pack-reused 61547
Receiving objects: 100% (63399/63399), 177.19 MiB | 9.76 MiB/s, done.
Resolving deltas: 100% (33721/33721), done.
-> Downloading nwjs-sdk-v0.24.4-linux-x64.tar.gz...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 86.7M 100 86.7M 0 0 11.7M 0 0:00:07 0:00:07 --:--:-- 14.4M
==> Validating source files with md5sums...
purr-data-git ... Skipped
==> Validating source_x86_64 files with md5sums...
nwjs-sdk-v0.24.4-linux-x64.tar.gz ... Passed
==> Making package: gconf-gtk2 3.2.6-5 (Wed 09 Feb 2022 10:41:26 PM CET)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found GConf-3.2.6.tar.xz
-> Found gconf-merge-schema
-> Found gconfpkg
-> Found gconf-reload.patch
-> Found gconf-install.hook
-> Found gconf-remove.hook
-> Found 01_xml-gettext-domain.patch
-> Found dbus-dontspew.patch
-> Found gsettings-data-convert-fix-invalid-schema-path.patch
==> Validating source files with sha256sums...
GConf-3.2.6.tar.xz ... Passed
gconf-merge-schema ... Passed
gconfpkg ... Passed
gconf-reload.patch ... Passed
gconf-install.hook ... Passed
gconf-remove.hook ... Passed
01_xml-gettext-domain.patch ... Passed
dbus-dontspew.patch ... Passed
gsettings-data-convert-fix-invalid-schema-path.patch ... Passed
==> Removing existing $srcdir/ directory...
==> Extracting sources...
-> Extracting GConf-3.2.6.tar.xz with bsdtar
==> Starting prepare()...
/home/olav/.cache/yay/gconf-gtk2/PKGBUILD: line 39: patch: command not found
==> ERROR: A failure occurred in prepare().
Aborting...
-> error making: gconf-gtk2
Forwards Compatibility Vanilla 0.52 (listbox aka list item)
Hey everyone
I've been working on a fairly elaborate sequencer patch in Puredata Vanilla version 0.52. I'm using just vanilla objects which have all been available in Puredata for some time.
I noticed when I open this patch in "Purr Data" or in older versions of Vanilla Puredata, (like 0.49), all the objects load correctly, but a lot of the patching is wrong. Specifically in sub-patches, the patching is just...... all over the place with cords going everywhere and not at all how it was patched when I made things.
I'm interested in making sequencers in Puredata that can be used on platforms like Bela or the Organelle. Those types of things usually use older versions of Pd. I expected that, because .pd files are human readable text files, there would be backwards compatibility, but I guess this was a faulty assumption?
I'm curious:
Is Vanilla Puredata generally not backwards compatible with older versions? Or is this a bug? Is there any easy way I could correct the patching in my patch so that it'll open in older versions of Puredata without having to re-patch everything? Or should I just stick to older versions of Puredata for this type of work going forward?
thanks
Dynamically patched vslider with local send symbol
@oid This is a problem from my 2nd ever dynamic patch, so I wouldn't try to read deep meaning into my questions . Like my first dynamic patch, it's just a patch that generates the repetitive, static parts of other patches--a way to reduce the tedium of having to edit multiple send/receive names by hand, that's all. I'm expecting to have to cut and paste from this helper patch into the patch I'm really trying to write, so the value of $0 in the generating patch is irrelevant. Is that reasonable? In a patch that needed its UI to be dynamically generated, your way would make total sense, but I'm def not there yet. Also, regarding your other topic, I think the message that dynamically generates a vslider can itself be static, so I'm not sure that add2 technique is applicable.
@ingox OK, now I'm getting the same results as you, which is odd because the patch I've presented is just a small example from a larger patch that was giving me trouble. After discovering the $\$0
syntax I applied it to that larger patch, saw that it too was working, and then posted this topic. But now my larger patch is broken, which makes me believe that the system is behaving differently since running your patches (and that I wasn't previously hallucinating). But that can't be true, right?
So here's another small patch to demonstrate how my larger patch is (now) broken: dynamicPatchVerticalSlider2.pd
See how \$0
is just generating a 0
in the send symbol? When I save and reload it to test the fader (which doesn't work), the backslash gets dropped from the creation message!
So next I try falling back to the syntax I got working earlier, and the generated vslider send symbol looks good
and on reloading it I can confirm that it is good, but now I can't use my generating patch because $1 is backslash escaped!
Paths and organizing .pd files for use.
@raynovich I use the [declare]
object instead of paths, keeps the paths list shorter and more manageable and also gives you a nice list of dependencies right in the patch so you never have to wade through the patch trying to figure out what it needs if you want to share the patch or copy it to a different machine. If you need a sub-folder you just declare the sub-folder. Use absolute paths when you declare, this way you can move the patch and it will still find what it needs. I generally have a sub-patch in each patch for declares and I avoid declaring folders, just declare the abstraction directly so I never have to try and figure out which abstractions a given patch uses, just open the declare sub-patch and it is all there. In my pd folder I have all my current patches, an abstractions folder, a folder for patches I am not currently working on and a folder for reference patches. I do my best to avoid making abstractions which only have use in a single patch, I will figure out how to generalize it to make it more useful for other patches so it can live in my abstraction folder without cluttering it up and helps avoid needing folders for patches. When a patch must have a folder it goes in the pd directory with the patch and I declare it instead of keeping the patch in it's own directory, this is mainly to minimize having to navigate folders as much.
Using [declare]
to explicitly declare individual abstractions also makes it easier to clean your abstraction folder, a simple shell script can check for abstractions which are not used by any patch or ones that just get used by a single patch so you can check them out to see if they are worth keeping or should be moved too the folder of that one patch which uses them.
"Send" & "Receive" to Child PD
Hi,
first of all, i am Stef from Germany, a "once in a while" PD User since a few years. My currently used PD-Version is 0.51 running on Ubuntu 20.04.
My question is:
I have a pd-Module, which has several "Receive" inputs inside with the same Name.
I would like to use several copies of the same module with the goal to control them all independently "wireless". To do this, i would need in fact a parent PD, which has a command/Value inlet , attach it to a "Send" object wiith the, which communicates with the underlying "cloned" pd Module.
Of course this would not work, because currently every other module with the same "receive" Object and the same name in the global PD sheet would react to the command/value being send. What i would need is a "Send"-Object which only does cummunicate with a child PD Object and does not send value changes -outside- the parent PD Object, like a "Container".
Like so:
Main PD Object=>Message -only- to Child PD=>Message -only- to Child PD and so on. The Message inside a parent Patch "Container" going to a child PD should not affect any other Receive object -outside- this container.
This would save me in fact a lot of time renaming the "Receive" Objects of each individual Child PD Patch.
The only thing that has to be done, would be to have a Parent PD Patch with some inlets that connects to a send object with the same static name that the -next- underling child PD would accept - in order to prevent renaming each individual "Receive" Inlet of the last Child PD Patch.
Is this possible in any way?
Another question that i would have - is it possible to clone PD Patches in such a way, so that any change in a PD Patch could affect every other PD patch when they use the same name?
Like so: Having 2 PD Patches on the main sheet with the same functionality and the same name=> any change on PD Patch number one (adding/removing objects, wiring etc) also affects/changes the contents of PD Patch Number 2,
Kind regards
Stef
Few questions about oversampling
Hi,
About a year ago I started to learn a bit pure data in order to create a patch that would act as a groovebox and that should perform on limited cpu resources since I want it to run on a raspberry pi. First I tried to make somekind of fork of the Martin Brinkmann groovebox patch, even if it allowed me to learn a lot about data flow I didn't went to the core of the patch tweaking with sound generation. This led me to end this attempt at forking MNB groovebox patch because even if I could seperate GUI stuff from sound generation and run it on different thread ect... I couldn't go further in optimization in order to reduce the cpu use.
Then a few weeks ago I decided to start again from scratch my project and this time I wanted to be more patient and learn anything needed in order to be capable of optimizing my patch as much as possible. After making a functional drum machine which runs at 2/3% of cpu with 8 different tracks, 126 steps sequencer, a bit of fx ect... I tried to find synths that would opperate well aside the drum machine. And I basicly didn't find any patch that wouldn't use massive amount of cpu time. So I created my own synths, nothing incredible but I'm happy with what I got, though I noticed some aliasing. I read a bit the floss manual about anti aliasing and apply the method used in the manual(http://write.flossmanuals.net/pure-data/antialiasing/), it work well but my synths almost trippled their cpu use, even if I put all my oscilators in the same subpatch in order to use only one instance of oversampling.
I didn't tried to oversample it less than 16 time but since oversampling is so cpu intensive I'm wondering if there's no other option in order to get a good sound definition at a lower cpu cost. I'm already using banlimited waveform so I don't know what I could do in order to limit the aliasing, especialy for my fm patch where bandlimited waveform isn't very useful in order to reduce aliasing.
Since I want to have at least 4 synth track with some at least one synth having 5 voice polyphony I want to know what the best thing to do. Letting FM aside for this project and use switch~ for oversampling 2 or 4 time my synths that use bandlimited waveform ? Or should I try to run different instances of pd for each synth and controling it from a gui/control patch with netsend(though it wouldn't bring down the cpu use at least it would provide somekind of multithreading for my patch) ? Or is there another way to get some antiliasing ? Or should I review lower my expectation because there is no solution that could provide a decent antialiasing for 4 or more synth running at the same time with a low cpu use in pure data in 2021.
Thanks to everyone that would read my topic and try to give some advice in order to get the best antialising/low cpu use solution.
Closing patches without Pd crashing, hopefully in an elegant way...
EUREKA! I solved the following problem:
Problem: provide a mechanism for allowing patches to self-close without Pd crashing.
Requirements: (1) uses only Pd vanilla; (2) action to close patch starts on the very patch that will be closed.
Solution: copy patch killer.pd in the same folder as the patch to be closed, and send a message containing ";pd open killer.pd <dir>;kill_me symbol patch_to_be_closed.pd":
killer.pd
patch_to_be_closed.pd
Comments: (documented in the killer patch) Pd doesn't deal well with menuclose requests that originate (in a direct chain reaction) from the same patch that wants to be closed, so a separate killer patch is needed, which can be opened by the same patch requesting to be closed. In order to break the direct chain reaction, the solution is to postpone this request and make it appear as being originated inside the killer patch. This is done by storing the received symbol and delaying the message menuclose by 0 ms, which is enough to issue a new chain of events. The killer patch stays alive (but invisible), and any new instances of the killer patch will silently kill the previous instances so that only one killer patch is alive at any given time. [EDIT: I included a safeguard [pipe 1] in the killer patch, check the inline comments]. This implementation fixes the problems with my previous solution and also with the 3-patches method by @ingox, both of which didn't work through a send/receive pair. It also does not depend on dynamic patching.
This has been tested in Pd 0.50-2 and Ubuntu 20.04. I appreciate feedback to confirm if it works in other platforms/versions.
@whale-av Thanks again David for the suggestions (hcs, mouse clicks)! I wasn't too keen on the idea of depending on external libraries, and I also had to abandom the idea of having the killer patch embedded in the patch to be closed.
Patchbox pisound phone app parameter issue
@rei Yes..... the $0 is the problem.
In your patch the $0 is given a value as the patch is opened. It is a value greater than 1000...... but as you open each patch they are given a different value.
You can discover the value for each patch like this......
So $0-mix-send becomes 1001-mix-send even though it still looks like $0-mix-send in the patch.
But the json file doesn't know the value.
Even if you discover the value of $0 and change the json file you will run into problems when you open the patch after opening another and the value given is 1002 and not 1001..... so that is not a solution.
If you will only have one json file and one copy of the patch open then just remove the $0 everywhere (and in the json file).
If you will have more than one copy of the patch then use $1 instead of $0 in the patch and give each copy an argument.....1 or 2 or?...... eg......
[my_patch 1]
[my_patch 2]
and then use that argument ( 1, 2 etc..... not $1 ) in place of the $0 in the json file that controls the patch.
David.