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.
Looks like a bug that should be fairly easy to fix. I'll try to include the bugfix in the next release:
@ddw_music Please hammer away at the
<ctrl-b>help browser in Purr Data by adding issues to the tracker:
If it's not returning useful results for a term like biquad there are probably lots of ways to tweak it.
That help browser searches all the external libs that are already installed on your machine, so being able to successfully leverage that should address a lot of the problems.
Also-- please report if any of the externals are broken. I've never seen a single Pd external lib that shipped with tests, and we're talking about trivial bugs like broken arg parsers in a constructor, pointers to nowhere, etc. An unfortunate part of the Pd culture is that instead of reporting a bug a new user quickly learns, "if doing X crashes Pd then don't do X."
I mean, there's an XML parsing class that had a bug which ended up indexing past the end of an array for a core part of the algorithm. All that effort to do something as mind-numbing as string parsing in C, and the developer apparently never even called a method on it. It's like the code equivalent of 5'33".
That would be great.
I've got some code in Purr Data that essentially does that-- each canvas window is just an svg. But most of the editor code is still handled in C.
But I think it's possible to develop a fully HTML5 editor/display engine in parallel to the current GUI. Then you could use it as a library to display editable patches in a web page (even with audio running in the background). It's the little details that make this a rather complex project-- e.g., what should happen in a web patch display if the user clicks on a subpatch?