Purr Data 2.13.0 is now available
Please report issues here:
- ported Vanilla's [inlet~ fwd] argument (reimplemented to avoid stack allocation and various other problems) (Thanks to Guillem!)
- scrollbar fix for optimal zoom (Thanks Ico!)
- avoid null selectors in core where trivial to do so, gracefully handle and annotate them when/if they happen. Also added an experimental [debuginfo] object so we can output a message with a null selector (and other methods in the future good for testing)
- ported Vanilla patch for [pow~] handling negative samples in input
- ported [savestate] from Vanilla
- ported array, scalar "bang" methods
- add base argument and inlet for [log]
- add zcheckgetfn to m_pd.h for checking method signatures match before doing an end run around typedmess. This is used for the reimplementation of [inlet~ fwd]. (Thanks to Guillem for this)
- port and re-implement Vanilla's "#ffffff" syntax for setting iemgui colors. Additionally, support the "#fff" short syntax. We're not currently saving the symbol colors in the Pd file format, yet. A warning is printed about this since it means we're still storing the lossy color format. A future version will save the symbol colors, but we want to ship a few releases supporting the new syntax before making this breaking file format change.
- added "test-object" abstraction for doing more detailed testing of objects
- fixed bug where the box width was wrong when editing certain objects (thanks to Guillem)
- port "seed" method for [noise~]
- throttle canvas_motion (part 1 of 2 of getting rid of exponential explosion when moving selections)
- port [text] "sort" method
- when clicking an error link, bring the relevant object into the viewport and animate it to make it easy for the user to find
- add "-alsaadd" flag with pulse device for pulse support (Thanks to Sam!)
- fixed some alsa bugs
- ported from Vanilla: preserve phase in [clone] after [all( message, fixed a crasher
- expand and improve the type hints for errors with edge case atoms (null selectors, null symbols, "floatlike" symbol payloads, etc.)
- improvements to french translations (Thanks Joseph!)
- update pd-lua compatibility with Lua 5.4 (Thanks Albert!)
- port multi-step undo from Vanilla (Thanks Guillem!)
- initial touch support in GUI (Thanks Albert and spidercatnat!)
- zoom viewport fix (Thanks Albert!)
Purr Data 2.12.0 is now available
Please report issues here:
- vastly improved window sizing and scrollbar behavior. Now things like the help patches with content that fits in the viewport should load without scrollbars present. (thanks to Ico)
- show current text name (if any) in text editor for [text define]
- ported [text define] "send" method from Vanilla
- ported [text insert] from Vanilla
- ported [dac]/[adc] set method from Vanilla
- added French translation and improve German translation (thanks to Albert and Joseph Gastelais)
- ensure plot traces remain in the bounding box of the graph (thanks to Ico)
- ported "symbol" method for [float] from Vanilla
- added "type hints" for errors wrt unusual or problematic Pd messages. This includes
- symbol atom which would be parsed as a float if found in a Pd file
- same thing but with symbol messages, e.g., "symbol 43"
- empty symbol messages "symbol"
- empty symbol selector ""
- null selector
- symbol atoms/messages with weird "floatlike" data that would overflow/underflow if loaded by a Pd file.
- ported "send" methods from Vanilla for [int], [float], and [value]
- document the "tempo" messages for relevant objects
- fixed a crasher with pasting from Pd patch file (thanks to Ico)
- fixed a long-standing crasher where editing an open GOP window would hide everything except the patch cords under certain circumstances
- an object/gop being edited now has the same size as one that isn't being edited (thanks to Ico)
- fixed keyboard shortcut for dropdown that caused problems for some keyboard types (thanks to Albert)
- fixed ggee/image border selection when on GOP
- fixed long-standing bug with route where a bang wouldn't get sent to the reject outlet
- fixed bug where nested gops erroneously showed a selection rectangle
- fixed a crasher with resizing a nesting GOP when dragging with the mouse
- custom scrollbars from Pd-l2ork 1.0 (thanks to Ico)
- increased gatom character width to 160
- fixed off-by-one problem with iemgui label positions
- fixed bar graph display when graph has its own window
- made a larger hitbox for xlet connection for easier patching (thanks to Ico)
- make default CSS match pd-l2ork 1.0 style
- different, "greyed-out" style for inlet hover (as an inlet can't begin a connection with a mouse, but an outlet can)
[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.
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?
@Jona A brown noise abstraction is a great example of what you're describing-- using a small core set of objects to build more sophisticated functionality. One could use the same design for various noise-related abstractions and roll them into a nice external library that is modular and easy to reason about.
Outputting dsp status is not a great example, however. Introspection of something as central as dsp computation is a missing core feature. The abstractions provided here are buggy and difficult to reason about. The proliferation of various buggy workarounds wastes both the time of users and developers.
Even worse, such workarounds add noise to the discussions that end up making it more difficult to get missing features included in Pd Vanilla. Once a user requested it we added the "clear" method to
delwrite~in Purr Data quite quickly. In Pd Vanilla it took a) a patch, an argument about the patch, c) an argument about Pd Vanilla's dev process, d) the patch sitting for years, e) another argument, f) a proposed workaround so difficult to reason about that one developer familiar with Pd's externals couldn't completely understand it, g) more pleading from other users, and finally h) a reluctant merging of a single trivial patch to the core. I don't think asceticism requires a development process like that.
This is a built-in class in Purr Data. It took 5 minutes to write the method that fetches the dsp state and maybe 10 minutes for us to discuss any gotchas.
By using that simple method in Purr Data's "output~" abstraction all of the gotchas of the various workarounds in this thread simply go away.