-
Jonathan Wilkes authoredJonathan Wilkes authored
Pd-L2Ork
maintainers:
- Ivica Ico Bukvic ico@vt.edu
- Albert Graef aggraef@gmail.com
- Jonathan Wilkes jancsika@yahoo.com
- Downloads
- One Paragraph Overview
- Three Paragraph Overview
- Goals
- User Guide
- Relationship of Purr Data to Pure Data
- Build Guide
- Code of Conduct
- Project Governance
- Contributor Guide
- Human Interface Guidelines
- Core Pd Notes
- GUI Message Spec
One Paragraph Overview
Pure Data (aka Pd) is a visual programming language. That means you can use it to create software graphically by drawing diagrams instead of writing lines of code. These diagrams show how data flows through the software, displaying on the screen what text-based languages require you to piece together in your mind.
Three Paragraph Overview
Pd has been designed with an emphasis on generating sound, video, 2D/3D graphics, and connecting through sensors, input devices, and MIDI as well as OSC devices.
Pd has a special emphasis on generating audio and/or video in real time, with low latency. Much of its design focuses on receiving, manipulating, and delivering high-quality audio signals. Specifically, the software addresses the problem of how to do this efficiently and reliably on general purpose operating systems like OSX, Windows, Debian, etc.-- i.e., systems designed mainly for multi-tasking.
Pd can easily work over local and remote networks. It can be used to integrate wearable technology, motor systems, lighting rigs, and other equipment. Pd is also suitable for learning basic multimedia processing and visual programming methods, as well as for realizing complex systems for large-scale projects.
Goals
Pd-L2ork has the following goals:
- Documentation. We like documentation. It's like code, except friendly.
- Be reliable. Binary releases must be usable for performances and installations. The git repo must always be in a workable state that can be compiled. Regressions must be fixed quickly.
- Be discoverable. Undocumented features are buggy. Missing help files are bugs. Patches for new functionality that lack documentation are spam.
- Be consistent. Consistent interfaces are themselves a kind of documentation. We like documentation, so it follows that we like consistent interfaces.
User Guide
For a more in-depth look at Purr Data for new users and developers, see:
https://agraef.github.io/purr-data-intro/Purr-Data-Intro.html
For more resources see:
https://agraef.github.io/purr-data/