Related-- one mechanism that would be nice is the ability to have a singleton as part of an abstraction-based library. For example-- perhaps you want an abstraction that forwards messages to and from a sequencer, and you want the sequencer itself to be part of the abstraction. There's no easy way to do that.
As a result users generally just put the singleton thing-- array, text object, etc.-- in the main patch, adjacent to the object chain that reads and writes the thing.
I'm referring to a general problem which currently has no general solution in Max or Pd. Maybe other dataflow environments have found a solution.
As is often the case with Pd, it's not ergonomic. But it does generalize. You can dispatch arbitrary pd messages to and from any stateful object or abstraction using this technique.
You can probably also use abstractions to wrap the sends/receives in order to hide the ugly $0 passing.
Hmm, no, the point is to decouple the output from one and only one path.
It decouples the output of your state machine from one and only one path. You get N paths where N is the number of abstraction instances you use to, say, implement the Supercollider state machine thingy you linked to. (Just to clarify-- each abstraction only generates output when a message gets sent to its own inlet.)
If you're thinking that you now want each abstraction to dynamically output to different paths, either I don't understand what you're trying to do or you are overengineering your solution.
Wondering if there are other options.
You can set up an abstraction which just forwards the message on to your global sequencer along with the abstraction's "$0" value. You use that "$0" value to set the symbol to the right inlet of a
[send]that connects to the output of the sequencer-- something like that "$0" value prepended to "_the_output". Now just let that output flow from the sequencer to that
Inside your abstraction, you have
[receive $0_the_output]. Just hook that to an
[outlet]and you're done.
Now that abstraction receives the output for whatever method it called, another abstraction receives its own output, and so on.
But [value] can hold only a single number (why? wouldn't the equivalent of a 'variant' type be useful?), and [text] is dealing with lists.
If you don't want a single number, or a list, or an array (which also can be shared by name), what is it you're after?
Note you can also define your own data structure with
[struct], but shuttling around the references with
[pointer]is pretty clunky.
Not sure if I ever posted this: it is a tutorial/game where you shoot bullets at iemguis.
It ships with Purr Data-- you can find it in doc/4.data.structures/pd-l2ork/sprite-game/. (If you follow that link, there is a little button in Gitlab that will download the directory as a zip file.)
Purr Data 2.15.1 has been released.
We had some build issues and Albert graciously stepped up to help merge the relevant patches and posted the release on github quite quickly:
If you're on Gnu/Linux, do use the OBS repos that he set up. He's posted a very clear guide, and if you use it you'll get Purr updated automatically any time you update the system.
As always, report issues here:
With that out of the way, I'd like to highlight the work our students did for Google Summer of Code Projects that wrapped up over a month ago.
Patch Private Abstractions
This was a feature created by Guillem Bartrina. (Actually, one of several features he added as part of his GSoC project this summer. I'll try to post about his other additions later.) It allows the user to create and use abstractions which get saved in the parent patch. Abstraction names are local to the patch which contains them, which makes for a quite workable and flexible namespacing system that's easy to use and understand.
This is a very tricky feature to design and get right, and Guillem did an excellent job considering various corner cases and optimal UX. Notice in the video that he added a few features which are useful generally for abstractions, too:
- a notification when the user has an unsaved abstraction somewhere in the running instance
- another notification when the user has two or more unsaved abstractions in the running instance. This is quite a handy feature for normal abstractions, too, as it can save you from the headache of overwriting important changes when you're working after midnight on your last cup of coffee!
There are also some helper classes that give some options to ensure that the user doesn't lose data.
Purr Data Webapp
This was another ambitious project with frontend work by Hugo Neves de Carvalho and backend, API, and merging work by Zack Lee.
This project runs the core of Purr Data and a surprisingly large number of all the externals it ships in a webpage. The front end can load, save, close, and "vis" multiple patches and run them from the same backend engine.
Thanks to the way Zack leveraged the emscripten file system, you can even save abstractions and call them from a new patch!
The patch private abstractions have already been merged into Purr Data, and we're currently working on upstreaming the webapp changes into Purr Data as well.
I'm setting up an RPI4 build machine. But I'll be building on whatever the stock Raspbian version is.
Is there a reason you're using the beta?
Anyway, I have compiled Purr Data for a rockchip-based machine which is arm64 and everything seemed to work fine.
What I mean is: If we agree that using Pd without cyclone and zexy is tying one hand behind your back... someone downloads Pd, never used it before. How do they find out that they should install cyclone and zexy?
That's part of the reason we have default startup paths in Purr Data for all the libraries that were shipped with Pd-extended. The other reason is that this means that any patches that were developed during the Pd-extended days will work by default in Purr Data.
This means there are probably object names taken by some of these libraries that you'd rather have for yourself. On the other hand if you don't load or ship anything as a default then you end up with this discoverability problem you describe.
Do you believe they would be receptive to this idea?
Depends on how the precedence is actually implemented.
Where is this "new user documentation?"
In Purr Data we load these libraries by default and have improved the search functionality recently. So it's less of an issue.
Everyone that sticks with pd likely has a counter abstraction, why not just standardize it finally?
If you want to create an abstraction-based library of utility objects which you think are common to a large number of use cases, you should do it. I believe there are at least a handful of such abstraction-based utility libraries in Pd-extended, but they probably include a different set of abstractions than what you want. If you use a consistent interface for everything and include full documentation in the help-patches, your library will probably be a welcome addition to the available externals. I'd be willing to include such a library in Purr Data for example.
If you want your library to somehow have precedence over other libraries-- e.g., shipping with Pd Vanilla-- I'd suggest to first gauge interest in your idea on the pd dev mailing list.
It sounds like a regression. Please report it at
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!