Boids (flock simulator)
@60hz said:
It works for me, but you certainly need to refresh the [number 15( message AFTER create the [pd boid] subpatches creation.
Also, here is a better version using [clone] object that has been part of puredata and makes the design more convienient.
(Note that boids Gem examples need [poltocar] object fom cyclone to work well)
Hi, your patch works fine, the boids move correctly, but when I increase their number for example from 15 to 115, also doing the "refresh after..." as you said, the boids increase but stay still, they don't move.
Now, when I open your patch, I get these errors:
--------------------------------------------------------------------
:: Cyclone 0.6-1; Released june 8th 2022
:: License: BSD-3-Clause (aka Revised BSD License)
:: Copyright © 2003-2021 - Krzysztof Czaja, Hans-Christoph Steiner,
:: Fred Jan Kraan, Alexandre Porres, Derek Kwan, Matt Barber
:: and others.
:: -----------------------------------------------------------------
:: Cyclone 0.6-1 needs at least Pd 0.52-0
(you have 0.52-1, you're good!)
:: Loading the cyclone library did the following:
:: - A) Loaded the non alphanumeric objects, which are:
:: [!-], [!-~], [!/], [!/~], [!=~], [%~], [+=~], [<=~], [<~],
:: [==~], [>=~] and [>~]
:: - B) Added /home/a/Pd/externals/cyclone
:: to Pd's path so the other objects can be loaded too
:: but use [declare -path cyclone] to guarantee search priority
:: in the patch
--------------------------------------------------------------------
opened alsa MIDI client 130 in:1 out:1
declare: Gem: unknown declaration
canvas.top
... couldn't create
canvas.top
... couldn't create
canvas.top
... couldn't create
canvas.top
... couldn't create
canvas.top
... couldn't create
canvas.top
... couldn't create
canvas.top
... couldn't create
canvas.top
... couldn't create
canvas.top
... couldn't create
canvas.top
... couldn't create
canvas.top
... couldn't create
canvas.top
... couldn't create
canvas.top
... couldn't create
canvas.top
... couldn't create
canvas.top
... couldn't create
boids2d 2005-2006 a.sier / jasch 1995-2003 eric l. singer Jan 1 2023 13:49:25
These are my startup paths:

** [poltocar]** object appears to be in place:
a@a:~$ cd /home/a/Pd/externals/cyclone
a@a:~/Pd/externals/cyclone$ ls
[CUT]
poltocar.d_fat
poltocar~.d_fat
poltocar-help.pd
poltocar~-help.pd
poltocar.l_amd64
poltocar~.l_amd64
poltocar.l_arm
poltocar~.l_arm
poltocar.l_i386
poltocar~.l_i386
poltocar.m_amd64
poltocar~.m_amd64
poltocar.m_i386
poltocar~.m_i386
[CUT]
Something is probably missing or i am doing something wrong.
Bye,
a.
envgen does not work with Linux?
@bobpell You can check in /etc/security for limits.conf or limits.d/, grep limits.conf/the files in limits.d/ for audio, grep audio limits.conf or grep audio limits.d/*, you should have
@audio - rtprio 95
@audio - memlock unlimited
If you have them but the settings for rtpro or memlock are different, than change them to 95 and unlimited. If you do not have anything for audio then if you have limits.conf, add the lines, if you have limits.d/ then add the file audio.conf with those lines and restart. If you do have those or adding them does not work than it is a quirk of LinuxMint and you will have to ask in a LinuxMint forum how to set it up or wait for someone more familiar with LinuxMint to show up. LinuxMint is Ubuntu based so this should already be setup and just adding your user to the audio group should work, but LinuxMint may have decided to change this and you will need to ask people well versed in the distro or do some searching to find what you need to do. One thing you can do is install the Ubuntu Studio package, but that is a great deal of software so somewhat overkill.
Edit: looks like I missed an update and duplicated a response, either of our numbers will work. Regarding the niceness line, from what I understand that is a hold over from bygone days and not needed on modern systems, does not hurt to have it but it does not actually accomplish anything.
Trying to create Variable speed delay, but buffer clears when read index is same as write index.
No problem... here it is simplified, with some comments. Thanks!
#N canvas 678 92 1242 928 12;
#X msg 273 196 resize $1;
#X obj 527 71 nbx 5 14 -1e+37 1e+37 0 0 empty empty empty 0 -8 0 10
#fcfcfc #000000 #000000 1 256 0 0 1 0;
#X obj 273 221 array define sampler1;
#X obj 923 853 dac~;
#X obj 152 352 phasor~ 1;
#X obj 919 286 nbx 5 14 -1e+37 1e+37 0 0 empty empty empty 0 -8 0 10
#fcfcfc #000000 #000000 0.7 256 0 0 1 0;
#X text 526 84 buffer size (s);
#X obj 978 636 vsl 15 128 0 127 0 0 empty empty empty 0 -9 0 10 #fcfcfc
#000000 #000000 0 1 0 1;
#X obj 922 814 *~;
#X obj 281 586 vsl 8 128 0 127 0 0 empty empty empty 0 -9 0 10 #fcfcfc
#000000 #000000 0 1 0 1;
#X obj 263 753 *~;
#X text 997 719 volume;
#X text 300 644 feedback;
#X obj 107 803 +~, f 4;
#X obj 410 39 loadbang;
#X obj 472 38 bng 26 250 50 0 empty empty empty 17 7 0 10 #fcfcfc #000000
#000000 1;
#X obj 106 22 adc~;
#X obj 920 327 phasor~ 1;
#X obj 517 451 edge~;
#X obj 517 482 bng 15 250 50 0 empty empty empty 17 7 0 10 #fcfcfc
#000000 #000000 1;
#X obj 152 374 *~ 44099;
#X obj 545 267 - 1;
#X obj 920 369 *~ 44099;
#X obj 107 839 poke~ sampler1;
#X text 500 14 this part up here just calculates the buffer size as1
second , based on the sample rate;
#X text 575 226 sutracting 1 from buffer sizefor index range because
indexrange starts at 0 , not 1;
#X text 992 341 phasor forplayhead pointer;
#X text 226 356 phasor forwrite head pointer;
#X text 566 445 this is here to indicatewhen the read and write indexare
the same (diagnostic);
#X obj 970 557 s~ feedback;
#X obj 188 725 r~ feedback;
#X obj 20 63 s~ dry;
#X obj 516 420 expr~ (abs($v1-$v2)< 1);
#X obj 927 493 tabread~ sampler1;
#X text 976 282 playback speed (try 0.7);
#X obj 832 777 r~ dry;
#N canvas 0 0 450 300 buff 0;
#X obj 40 107 samplerate~;
#X obj 40 130 * 1;
#X msg 127 105 1;
#X obj 40 80 t b b;
#X obj 40 152 t f f;
#X obj 13 26 inlet;
#X obj 63 26 inlet;
#X obj 13 225 outlet;
#X obj 69 225 outlet;
#X obj 125 225 outlet;
#X connect 0 0 1 0;
#X connect 1 0 4 0;
#X connect 2 0 9 0;
#X connect 3 0 0 0;
#X connect 3 1 2 0;
#X connect 4 0 7 0;
#X connect 4 1 8 0;
#X connect 5 0 3 0;
#X connect 6 0 1 1;
#X restore 472 68 pd buff;
#X text 249 244 defines and sizes the buffer;
#N canvas 0 0 450 300 line 0;
#X obj 40 100 nbx 5 14 -1e+37 1e+37 0 0 empty empty empty 0 -8 0 10
#fcfcfc #000000 #000000 0 256 0 0 1 0;
#X obj 40 80 / 127;
#X obj 40 148 line~;
#X msg 40 118 $1 100;
#X obj 13 26 inlet;
#X obj 13 221 outlet~;
#X connect 0 0 3 0;
#X connect 1 0 0 0;
#X connect 2 0 5 0;
#X connect 3 0 2 0;
#X connect 4 0 1 0;
#X restore 281 725 pd line;
#N canvas 0 0 450 300 line 0;
#X obj 40 103 line~;
#X msg 40 80 $1 100;
#X obj 13 26 inlet;
#X obj 13 176 outlet~;
#X connect 0 0 3 0;
#X connect 1 0 0 0;
#X connect 2 0 1 0;
#X restore 920 304 pd line;
#N canvas 0 0 450 300 line 0;
#X obj 40 100 nbx 5 14 -1e+37 1e+37 0 0 empty empty empty 0 -8 0 10
#fcfcfc #000000 #000000 0 256 0 0 1 0;
#X obj 40 80 / 127;
#X obj 40 148 line~;
#X msg 43 118 $1 100;
#X obj 13 26 inlet;
#X obj 13 221 outlet~;
#X connect 0 0 3 0;
#X connect 1 0 0 0;
#X connect 2 0 5 0;
#X connect 3 0 2 0;
#X connect 4 0 1 0;
#X restore 978 774 pd line;
#X connect 0 0 2 0;
#X connect 1 0 36 1;
#X connect 4 0 20 0;
#X connect 5 0 39 0;
#X connect 7 0 40 0;
#X connect 8 0 3 0;
#X connect 8 0 3 1;
#X connect 9 0 38 0;
#X connect 10 0 13 1;
#X connect 13 0 23 0;
#X connect 14 0 36 0;
#X connect 15 0 36 0;
#X connect 16 0 13 0;
#X connect 16 0 31 0;
#X connect 17 0 22 0;
#X connect 18 0 19 0;
#X connect 20 0 23 1;
#X connect 20 0 32 0;
#X connect 21 0 20 1;
#X connect 21 0 22 1;
#X connect 22 0 32 1;
#X connect 22 0 33 0;
#X connect 30 0 10 0;
#X connect 32 0 18 0;
#X connect 33 0 8 0;
#X connect 33 0 29 0;
#X connect 35 0 8 0;
#X connect 36 0 0 0;
#X connect 36 1 21 0;
#X connect 36 2 1 0;
#X connect 38 0 10 1;
#X connect 39 0 17 0;
#X connect 40 0 8 1;
Sending PD data between Raspberry Pis, perhaps with Pduino?
@Dizzy-Dizzy Yes, @alexandros means connect them with an Ethernet cable. You will not be able to connect another computer though.... the 2 rpi's will just talk to each other.
You should set the rpi's to use static ip addresses anyway..... and they must be different..!
The home/etc/dhcpcd.conf files should look something like this....... dhcpcd.conf ..... which is set to use wifi and to fall back to Ethernet.... so the fallback should be commented out for your setup..... unless of course you are connecting them to the router with Ethernet cables...... in which case eth0 should be set as primary.
It will help if you post your Pd patches for the 2 rpi's and their home/etc/dhcpcd.conf files and their home/etc/wpa_supplicant/wpa_supplicant.conf files.
Zip them all up in a zip folder and upload them to this thread.
The router should not be connected to the internet..... so the NAT redirection can be turned off.
You can protect access to the router by MAC addresses (the Mac addresses of any device you want to use should be added to the table in the router) to try as far as possible to stop anyone else connecting to the wifi.
The ip addresses of the rpi's should be outside the range of the dhcp server of the router....... but the router dhcp server can be turned off anyway.
You want to be certain that the message passes between the rpi's so you should use TCP and not UDP for netsend/netrecieve.
Also there has been a discussion on the pdList about [netsend -u] dropping the socket so it is best avoided until fixed.
You could add a "fix" mechanism to your patch that makes sure the connection is good before playing anything and doing a disconnect + connect if it gets no reply.
David.
[catch~]: Would like to set the name programmatically
@ingox said:
latency-tester right,
it's not. here some fixes:
[throw~] and [catch~] do bring some latency with them as far as i know...
It depends on the execution order, described in 3. G05 of Pd documentation.
Patching like this has no latency for your 2nd and 3d version, as for dyncatch~ and throw~ chatch~ and s~ r~.
But there is other trouble with the 2nd and 3d version:
Deleting by 'dynamic-mouse-clicks' doesn't work if I use Pd's zoom-in, as I usaually do.
This is a bug of Pd: it messes up the coordinates.
Same happens if I undo after moving an object, it reappears somewhere else...
@ddw_music said:
In SC, I can arrange mixer channels in the order source --> target
[...] looks like the only way to force order is using an explicit patch cable
Not sure, but I belive only the order of objects is important, and even msend~ v1 could have 0 latency, if it would care about creation order!? Even across multiple patches? Creation order = execution order ?
Edit: yes and no: it's the creation order of the whole chain ...
in latency-tester2.pd:
[pd latency-meter] is the first object, [pd click] comes later,
... so deleting the patch-cord between [pd s] [pd r] brings back block-latency.
Why does Pd look so much worse on linux/windows than in macOS?
Howdy all,
I just found this and want to respond from my perspective as someone who has spent by now a good amount of time (paid & unpaid) working on the Pure Data source code itself.
I'm just writing for myself and don't speak for Miller or anyone else.
Mac looks good
The antialiasing on macOS is provided by the system and utilized by Tk. It's essentially "free" and you can enable or disable it on the canvas. This is by design as I believe Apple pushed antialiasing at the system level starting with Mac OS X 1.
There are even some platform-specific settings to control the underlying CoreGraphics settings which I think Hans tried but had issues with: https://github.com/pure-data/pure-data/blob/master/tcl/apple_events.tcl#L16. As I recall, I actually disabled the font antialiasing as people complained that the canvas fonts on mac were "too fuzzy" while Linux was "nice and crisp."
In addition, the last few versions of Pd have had support for "Retina" high resolution displays enabled and the macOS compositor does a nice job of handling the point to pixel scaling for you, for free, in the background. Again, Tk simply uses the system for this and you can enable/disable via various app bundle plist settings and/or app defaults keys.
This is why the macOS screenshots look so good: antialiasing is on and it's likely the rendering is at double the resolution of the Linux screenshot.
IMO a fair comparison is: normal screen size in Linux vs normal screen size in Mac.
Nope. See above. 
It could also just be Apple holding back a bit of the driver code from the open source community to make certain linux/BSD never gets quite as nice as OSX on their hardware, they seem to like to play such games, that one key bit of code that is not free and you must license from them if you want it and they only license it out in high volume and at high cost.
Nah. Apple simply invested in antialiasing via its accelerated compositor when OS X was released. I doubt there are patents or licensing on common antialiasing algorithms which go back to the 60s or even earlier.
tkpath exists, why not use it?
Last I checked, tkpath is long dead. Sure, it has a website and screenshots (uhh Mac OS X 10.2 anyone?) but the latest (and only?) Sourceforge download is dated 2005. I do see a mirror repo on Github but it is archived and the last commit was 5 years ago.
And I did check on this, in fact I spent about a day (unpaid) seeing if I could update the tkpath mac implementation to move away from the ATSU (Apple Type Support) APIs which were not available in 64 bit. In the end, I ran out of energy and stopped as it would be too much work, too many details, and likely to not be maintained reliably by probably anyone.
It makes sense to help out a thriving project but much harder to justify propping something up that is barely active beyond "it still works" on a couple of platforms.
Why aren't the fonts all the same yet?!
I also despise how linux/windows has 'bold' for default
I honestly don't really care about this... but I resisted because I know so many people do and are used to it already. We could clearly and easily make the change but then we have to deal with all the pushback. If you went to the Pd list and got an overwhelming consensus and Miller was fine with it, then ok, that would make sense. As it was, "I think it should be this way because it doesn't make sense to me" was not enough of a carrot for me to personally make and support the change.
Maybe my problem is that I feel a responsibility for making what seems like a quick and easy change to others? 
And this view is after having put an in ordinate amount of time just getting (almost) the same font on all platforms, including writing and debugging a custom C Tcl extension just to load arbitrary TTF files on Windows.
Why don't we add abz, 123 to Pd? xyzzy already has it?!
What I've learned is that it's much easier to write new code than it is to maintain it. This is especially true for cross platform projects where you have to figure out platform intricacies and edge cases even when mediated by a common interface like Tk. It's true for any non-native wrapper like QT, WXWidgets, web browsers, etc.
Actually, I am pretty happy that Pd's only core dependencies a Tcl/Tk, PortAudio, and PortMidi as it greatly lowers the amount of vectors for bitrot. That being said, I just spent about 2 hours fixing the help browser for mac after trying Miller's latest 0.52-0test2 build. The end result is 4 lines of code.
For a software community to thrive over the long haul, it needs to attract new users. If new users get turned off by an outdated surface presentation, then it's harder to retain new users.
Yes, this is correct, but first we have to keep the damn thing working at all.
I think most people agree with you, including me when I was teaching with Pd.
I've observed, at times, when someone points out a deficiency in Pd, the Pd community's response often downplays, or denies, or gets defensive about the deficiency. (Not always, but often enough for me to mention it.) I'm seeing that trend again here. Pd is all about lines, and the lines don't look good -- and some of the responses are "this is not important" or (oid) "I like the fact that it never changed." That's... thoroughly baffling to me.
I read this as "community" = "active developers." It's true, some people tend to poo poo the same reoccurring ideas but this is largely out of years of hearing discussions and decisions and treatises on the list or the forum or facebook or whatever but nothing more. In the end, code talks, even better, a working technical implementation that is honed with input from people who will most likely end up maintaining it, without probably understanding it completely at first.
This was very hard back on Sourceforge as people had to submit patches(!) to the bug tracker. Thanks to moving development to Github and the improvement of tools and community, I'm happy to see the new engagement over the last 5-10 years. This was one of the pushes for me to help overhaul the build system to make it possible and easy for people to build Pd itself, then they are much more likely to help contribute as opposed to waiting for binary builds and unleashing an unmanageable flood of bug reports and feature requests on the mailing list.
I know it's not going to change anytime soon, because the current options are a/ wait for Tcl/Tk to catch up with modern rendering or b/ burn Pd developer cycles implementing something that Tcl/Tk will(?) eventually implement or c/ rip the guts out of the GUI and rewrite the whole thing using a modern graphics framework like Qt. None of those is good (well, c might be a viable investment in the future -- SuperCollider, around 2010-2011, ripped out the Cocoa GUIs and went to Qt, and the benefits have been massive -- but I know the developer resources aren't there for Pd to dump Tcl/Tk).
A couple of points:
-
Your point (c) already happened... you can use Purr Data (or the new Pd-L2ork etc). The GUI is implemented in Node/Electron/JS (I'm not sure of the details). Is it tracking Pd vanilla releases?... well that's a different issue.
-
As for updating Tk, it's probably not likely to happen as advanced graphics are not their focus. I could be wrong about this.
I agree that updating the GUI itself is the better solution for the long run. I also agree that it's a big undertaking when the current implementation is essentially still working fine after over 20 years, especially since Miller's stated goal was for 50 year project support, ie. pieces composed in the late 90s should work in 2040. This is one reason why we don't just "switch over to QT or Juce so the lines can look like Max." At this point, Pd is aesthetically more Max than Max, at least judging by looking at the original Ircam Max documentation in an archive closet at work. 
A way forward: libpd?
I my view, the best way forward is to build upon Jonathan Wilke's work in Purr Data for abstracting the GUI communication. He essentially replaced the raw Tcl commands with abstracted drawing commands such as "draw rectangle here of this color and thickness" or "open this window and put it here."
For those that don't know, "Pd" is actually two processes, similar to SuperCollider, where the "core" manages the audio, patch dsp/msg graph, and most of the canvas interaction event handling (mouse, key). The GUI is a separate process which communicates with the core over a localhost loopback networking connection. The GUI is basically just opening windows, showing settings, and forwarding interaction events to the core. When you open the audio preferences dialog, the core sends the current settings to the GUI, the GUI then sends everything back to the core after you make your changes and close the dialog. The same for working on a patch canvas: your mouse and key events are forwarded to the core, then drawing commands are sent back like "draw object outline here, draw osc~ text here inside. etc."
So basically, the core has almost all of the GUI's logic while the GUI just does the chrome like scroll bars and windows. This means it could be trivial to port the GUI to other toolkits or frameworks as compared to rewriting an overly interconnected monolithic application (trust me, I know...).
Basically, if we take Jonathan's approach, I feel adding a GUI communication abstraction layer to libpd would allow for making custom GUIs much easier. You basically just have to respond to the drawing and windowing commands and forward the input events.
Ideally, then each fork could use the same Pd core internally and implement their own GUIs or platform specific versions such as a pure Cocoa macOS Pd. There is some other re-organization that would be needed in the C core, but we've already ported a number of improvements from extended and Pd-L2ork, so it is indeed possible.
Also note: the libpd C sources are now part of the pure-data repo as of a couple months ago...
Discouraging Initiative?!
But there's a big difference between "we know it's a problem but can't do much about it" vs "it's not a serious problem." The former may invite new developers to take some initiative. The latter discourages initiative. A healthy open source software community should really be careful about the latter.
IMO Pd is healthier now than it has been as long as I've know it (2006). We have so many updates and improvements over every release the last few years, with many contributions by people in this thread. Thank you! THAT is how we make the project sustainable and work toward finding solutions for deep issues and aesthetic issues and usage issues and all of that.
We've managed to integrate a great many changes from Pd-Extended into vanilla and open up/decentralize the externals and in a collaborative manner. For this I am also grateful when I install an external for a project.
At this point, I encourage more people to pitch in. If you work at a university or institution, consider sponsoring some student work on specific issues which volunteering developers could help supervise, organize a Pd conference or developer meetup (this are super useful!), or consider some sort of paid residency or focused project for artists using Pd. A good amount of my own work on Pd and libpd has been sponsored in many of these ways and has helped encourage me to continue.
This is likely to be more positive toward the community as a whole than banging back and forth on the list or the forum. Besides, I'd rather see cool projects made with Pd than keep talking about working on Pd.
That being said, I know everyone here wants to see the project continue and improve and it will. We are still largely opening up the development and figuring how to support/maintain it. As with any such project, this is an ongoing process.
Out
Ok, that was long and rambly and it's way past my bed time.
Good night all.
use table to store midi channel information
@bengorilla The OP didn't post the solution as a patch....... and very unfortunately didn't put triggers [t f f f] on the outlets of [notein] so we cannot know the order of connections.
It looks as though you have copied it exactly, but if the connections to [notein]....... or [unpack] in your patch........ were not made in the correct order that could explain your note off problem....... maybe.....
The text might indicate the connection order that is required........ in the very first post they had the same problem and wrote about the order that they needed.
It looks like the order should be [stripnote] [swap] [tabread] [noteout] [pd transpose]........ but that is another maybe from me......
Read this too to understand better what I am talking about....... https://forum.pdpatchrepo.info/topic/13320/welcome-to-the-forum
David.
Snail... a pure data patch for slow sounds
Hello there, this seemed an interesting patch, so i unzipped it on a folder and tried to open it but got an unusable display and a string of errors on console, something like this (its not all of it);
list fromsymbol
... couldn't create
list tosymbol: unknown function
list tosymbol
... couldn't create
pdcontrol
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
clone 1 0 3 0 (canvas->outlet) connection failed
clone 1 1 8 0 (canvas->list split) connection failed
else/receiver
... couldn't create
else/receiver
... couldn't create
text search $1
... couldn't create
text set $1
... couldn't create
text search $1
... couldn't create
text get $1
... couldn't create
text size $1
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
text delete $1
... couldn't create
text_replace.pd 31 0 6 0 (canvas->select) connection failed
text_replace.pd 31 1 34 0 (canvas->trigger) connection failed
text define $0-guithru
... couldn't create
text size
... couldn't create
text get
... couldn't create
else/loadbanger -init
... couldn't create
else/receiver
... couldn't create
else/dollsym 1
... couldn't create
else/dollsym 2
... couldn't create
text define -k $0-controls
... couldn't create
array: no method for 'set'
else/args
... couldn't create
else/break -
... couldn't create
list fromsymbol: unknown function
list fromsymbol
... couldn't create
list tosymbol: unknown function
list tosymbol
... couldn't create
pdcontrol
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
clone 1 0 3 0 (canvas->outlet) connection failed
clone 1 1 8 0 (canvas->list split) connection failed
else/receiver
... couldn't create
else/receiver
... couldn't create
text search $1
... couldn't create
text set $1
... couldn't create
text search $1
... couldn't create
text get $1
... couldn't create
text size $1
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
text delete $1
... couldn't create
text_replace.pd 31 0 6 0 (canvas->select) connection failed
text_replace.pd 31 1 34 0 (canvas->trigger) connection failed
text define $0-guithru
... couldn't create
text size
... couldn't create
text get
... couldn't create
else/loadbanger -init
... couldn't create
else/receiver
... couldn't create
else/dollsym 1
... couldn't create
else/dollsym 2
... couldn't create
text define -k $0-controls
... couldn't create
array: no method for 'set'
else/click
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
q 8 0 11 0 (canvas->outlet) connection failed
q 8 1 5 0 (canvas->+~) connection failed
q 8 2 12 1 (canvas->canvas) connection failed
else/args
... couldn't create
else/break -
... couldn't create
list fromsymbol: unknown function
list fromsymbol
... couldn't create
list tosymbol: unknown function
list tosymbol
... couldn't create
pdcontrol
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
clone 1 0 3 0 (canvas->outlet) connection failed
clone 1 1 8 0 (canvas->list split) connection failed
else/receiver
... couldn't create
else/receiver
... couldn't create
text search $1
... couldn't create
text set $1
... couldn't create
text search $1
... couldn't create
text get $1
... couldn't create
text size $1
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
text delete $1
... couldn't create
text_replace.pd 31 0 6 0 (canvas->select) connection failed
text_replace.pd 31 1 34 0 (canvas->trigger) connection failed
text define $0-guithru
... couldn't create
text size
... couldn't create
text get
... couldn't create
else/loadbanger -init
... couldn't create
else/receiver
... couldn't create
else/dollsym 1
... couldn't create
else/dollsym 2
... couldn't create
text define -k $0-controls
... couldn't create
array: no method for 'set'
else/click
... couldn't create
text define -k $0-controls
... couldn't create
array: no method for 'set'
else/args
... couldn't create
text define -k $0-controls
... couldn't create
array: no method for 'set'
else/args
... couldn't create
else/loadbanger -init
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
mode 14 0 3 0 (canvas->clip) connection failed
mode 14 1 4 0 (canvas->wrap) connection failed
mode 14 2 6 0 (canvas->abs) connection failed
mode 14 3 15 0 (canvas->moses) connection failed
else/args
... couldn't create
else/break -
... couldn't create
list fromsymbol: unknown function
list fromsymbol
... couldn't create
list tosymbol: unknown function
list tosymbol
... couldn't create
pdcontrol
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
clone 1 0 3 0 (canvas->outlet) connection failed
clone 1 1 8 0 (canvas->list split) connection failed
else/receiver
... couldn't create
else/receiver
... couldn't create
text search $1
... couldn't create
text set $1
... couldn't create
text search $1
... couldn't create
text get $1
... couldn't create
text size $1
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
text delete $1
... couldn't create
text_replace.pd 31 0 6 0 (canvas->select) connection failed
text_replace.pd 31 1 34 0 (canvas->trigger) connection failed
text define $0-guithru
... couldn't create
text size
... couldn't create
text get
... couldn't create
else/loadbanger -init
... couldn't create
else/receiver
... couldn't create
else/dollsym 1
... couldn't create
else/dollsym 2
... couldn't create
text define -k $0-controls
... couldn't create
array: no method for 'set'
else/click
... couldn't create
else/break -
... couldn't create
list fromsymbol: unknown function
list fromsymbol
... couldn't create
list tosymbol: unknown function
list tosymbol
... couldn't create
pdcontrol
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
clone 1 0 3 0 (canvas->outlet) connection failed
clone 1 1 8 0 (canvas->list split) connection failed
else/receiver
... couldn't create
else/receiver
... couldn't create
text search $1
... couldn't create
text set $1
... couldn't create
text search $1
... couldn't create
text get $1
... couldn't create
text size $1
... couldn't create
else/args
... couldn't create
else/loadbanger -init
... couldn't create
text delete $1
... couldn't create
text_replace.pd 31 0 6 0 (canvas->select) connection failed
text_replace.pd 31 1 34 0 (canvas->trigger) connection failed
text define $0-guithru
... couldn't create
text size
... couldn't create
text get
... couldn't create
else/loadbanger -init
... couldn't create
else/receiver
... couldn't create
else/dollsym 1
... couldn't create
else/dollsym 2
... couldn't create
count.pd 15 0 8 0 (canvas->+) connection failed
count.pd 15 1 14 0 (canvas->-) connection failed
else/args
... couldn't create
else/loadbanger -init
... couldn't create
display 60 0 29 0 (canvas->message) connection failed
display 60 1 31 0 (canvas->select) connection failed
display 60 2 32 0 (canvas->message) connection failed
display 60 3 31 0 (canvas->select) connection failed
Any ideas ? cheers
s~/r~ throw~/catch~ latency and object creation order
I searched through many of the s~/r~ throw~/catch~ hops in my own code for mistakes based on what I've learned, and it looks like ~50% of all my non-local audio connections carry modulation signals that originate from control rate objects, so those aren't affected much. Only a few programs would have been broken had the non-local connections not matched, but because things were created in signal-flow order where it mattered, there was a consistent (and often unnecessary) 1 block delay everywhere. Many of those patches were later converted to use tabsend~/tabreceive~ under a small block size, and a few were converted to use delay lines. I was burned by the creation order side effect of delwrite~/delread~ once, but it wouldn't have happened had I not taken a lazy shortcut. Hilariously, I also found one test patch that I used to declare definitively, once and for all, that s~/r~ always introduces a 1 block delay if the sort order isn't controlled using the G05 technique. To paraphrase Agent K in the movie Men in Black, imagine what I'll "know" tomorrow!
So as a practical issue, I doubt coders are getting tripped up by this frequently. If you're like me you tend to code in signal flow order, and so you are mostly just introducing latency unnecessarily. RE advice, I agree with @Nicolas-Danet: use local audio connections wherever it matters and never mind the clutter. Even my worst spider web isn't so bad. Subpatches and abstractions can help hide the mess.
But when things are broken and showtime is looming, you'd be foolish not to use what you know, especially when you can always go back after curtain calls and adjust things to satisfy the style police. Here is a summary of the sort rules as best as I've been able to figure them out so far:
- A patch orders its constituent audio subpatches and abstractions, but has no influence over their internal ordering. Consequently, these rules are applied starting at the top level patch and recurse into each subpatch and abstraction.
- Audio chain tributaries and independent audio chains are executed in reverse order of their head's creation, except for those created by [clone], which are executed in the order of their creation (i.e. ascending clone index order).
- Audio branches that start from fanout connections are executed in reverse order of their start connection's creation.
- Whenever the rules conflict, the rule that places the tilde object the latest in line takes precidence.
These sort rules can affect your patch because unless s~ and throw~ buffer their data before their corresponding r~ and catch~ are executed, the latter will have to wait a block to access it. Delread~ will have a minimum 1 block delay.
Finally, I thought of this technique if you're absolutely certain you are going to get burned (or are just paranoid): wrap all s~, r~, throw~, catch~, delwrite~, delread~, and audio chain heads in their own subpatches. I noticed that if you modify the contents of a subpatch, it doesn't change its sort order in the containing patch, so you can add test code (e.g. [sig~ <uniqueNr>]->[tabsend~ <sharedArray>]) to subpatch pairs and check their execution order without changing it. If the order is wrong, then you cut and repaste the appropriate subpatches or audio connections according to the rules above until it isn't. That should take 15 mins, not days.
s~/r~ throw~/catch~ latency and object creation order
@seb-harmonik.ar Wow, that change would affect the sound of a lot of existing patches!
@whale-av OK, so I no longer think that "creation order side effects are scoped locally and don't reach across patch-subpatch boundaries". Check out these mystifying examples: cloneException.zip

This is a really contrived patch that passes signal left to right and right to left between instances of [lateral~]. I arranged the creation order to theoretically run [phasor~] first, then [clone -s 1 lateral 4 6], then the [catch~]s. Were my previous creation order side effect scope claim true, then you'd expect the latency flowing left to equal the latency flowing right because each clone instance of [lateral~] is an abstraction. And then you'd be excused for thinking that Pd is treating all clone instances as one combined abstraction for the purposes of computing tilde object sort order, but the problem is that it appears to be sorting in order of creation--the opposite of what I found previously!
Even crazier, if I create the [lateral~] instances by hand in the same order that clone creates them, the sort order reverses!



