[r pd] receives pings
That's an interesting hack. Garray display is so inefficient that it will typically send so many bytes to the GUI that "ping" is sent to ensure the GUI is still alive.
However, GUI_BYTESPERPING is set to 1024 by default and I think small arrays will squeak underneath that limit and not trigger the ping message.
If you mean by clicking or dragging on a "Put" menu array-- I believe Ico added this awhile back for pd-l2ork 1.0, and it's available in Purr Data as well:
If you have an garray named "array1", you may set a
[receive array1_changed]and it will output a bang when the array is changed with the mouse.
Purr Data 2.11.0 is now available
- fixed ambiguity in [select] where argument "bang" could match
- both "symbol bang" and an incoming "bang" message (Thanks Zack!)
- fixed graph label position to be consistent with pd-l2ork 1.0 (Pd
- Vanilla positioning still available with "-legacy" flag)
- display button for putting multiple arrays in a single graph
- added color legend for array labels with multiple arrays of
different colors inside one graph
- fixed some multiply defined global variables that cause compiler errors
- fixed potential memory leak with netreceive/netsend "disconnect"
- fixed some segfaults with preset_hub and preset_read (Thanks Ico!)
- fixed passing LDFLAGS to configure in the build scripts (Thanks Sam!)
- added support for compiling on aarch64
- fixed bug where wrap~ would default to old compatibility mode behavior
- ported unauthorized/pianoroll (even though it's not really a piano roll)
Please report issues here:
Just a reminder that Purr Data is participating in Google of Summer of Code for 2020.
The GSoC site has more details about the program.
Check out our dev guide to see how to quickly get up and running as a developer.
As in other years-- if you can write Pd patches, you can apply to do a project with us this summer.
Deadline is March 31, so patch fast!
Also, just skimming the source-- that object is set up so that at each dsp tick it schedules the work to be done at the next dsp tick. For Pd that means a delay of 64 samples. Without numbers on the output image in your link I have no idea whether that represents a significant proportion of the delay you measured or not.
I also have no idea how the delay you measured compares to the delay you experience from the time it takes for the sound to hit your ears. That's why I mentioned rountrip latency above-- it's the only (per-device) measurement that doesn't carry with it the risk of getting caught inside a bubble of insignificant digits.
Where is the specification for ableton link?
Also-- Assuming that arbitrary devices are to be able to connect through ableton link, I don't see how there could be any solution to the design of abl_link that doesn't require a human user to choose an offset based on measuring round-trip latency the given arbitrary device/configuration. You either have to do that or have everyone on high end audio interfaces (or perhaps homogenous devices like all iphones or something).
Put another way-- if you can figure out an automated way to tackle this problem for arbitrary Linux configurations/devices, please abstract out that solution into a library that will be the most useful addition to Linux audio in decades.
Searching for "biquad" does turn up biquad~ help, but the problem is that the help patch illustrates nothing about calculating filter coefficients.
Try the search again using the settings I gave in the comment under the issue you added to the tracker.
Using those settings, a search for "fmod" also returns "fmod". Unfortunately the search results aren't prepending the library name which is an issue that needs fixing.
Also I see that
[creb/fmod]easily loses precision. I think I've got a fix for that...
That Purr-Data for Mac doesn't support GEM is, unfortunately, a deal-breaker.
I'm not sure what your original terms were. Are you in search of
- the most suitable software
- the most suitable free/open source software
- the most suitable gratis software
- something else?
@Nicolas-Danet I think of it from the standpoint of the user-- there's almost certainly a low threshold of crashers and other bugs that the user quickly interprets as the natural state of the system,
That's esp. important for devs to keep in mind. I'm typically running Purr Data from the terminal where it will spit out a "fault" or some kind of error message to the virtual terminal. But for people running from a graphical menu Pd simply disappears on crash. Over time they may become anxious about doing any kind of business that could lead to Pd going away-- e.g., data structures, some external library, or even some method of an external library.
Add to that the open source "it's free" ethos and a user may be convinced that it would be rude to complain on the list that something isn't ripe soon enough for their tastes.