Code Monkey home page Code Monkey logo

libpd's Introduction

libpd

Pure Data as an embeddable audio synthesis library

Copyright (c) Peter Brinkmann & the libpd team 2010-2023

Documentation

For documentation of libpd, see the wiki: https://github.com/libpd/libpd/wiki

If you are using Processing, iOS, or Android, see our companion repositories:

Getting libpd

The preferred method to download libpd is to use git.

Do not download libpd as a zip or tar.gz file from GitHub.

The "Download ZIP" button may look like a good idea, but currently Github does not include submodule files when compiling zip files. This means the zip file is missing the main pd source files and you will not be able to build libpd, with errors such as: No rule to make target pure-data/src/d_arithmetic.o or No such file or directory: pure-data/extra/bonk~/bonk~.c.

To download libpd & check out the pure-data submodule, do the following:

git clone --recurse-submodules https://github.com/libpd/libpd.git

You should now have a libpd directory and the libpd/pure-data directory should contain the pd sources.

Note: If your version of git does not support "--recurse-submodules", you can run the git submodule commands in the libpd directory itself after cloning:

cd libpd
git submodule update --init --recursive

For most uses, it is recommended to check out the latest stable release version via a git tag. For example, to switch to libpd version 0.8.3 after cloning:

git checkout 0.8.3
git submodule update

The master branch contains the latest libpd development and can be considered generally stable. However, we make no guarantees. :)

Repository Layout

pure-data

The directory containing the sources of Pd Vanilla and it's standard externals. This is a git submodule of Miller Puckette's official Pd git repository:

git://git.code.sf.net/p/pure-data/pure-data

libpd_wrapper

This directory contains the source files that make up the core of libpd.

Android.mk, Makefile, libpd.xcodeproj, libpd_csharp.sln, .classpath, .project

Build support for various platforms. Feel free to improve the build system in any way you see fit.

cpp, csharp, java, jni, objc, python

Glue for using libpd with C++, C#, Java, Objective-C, and Python. Feel free to improve or add support for other languages such as Lua.

samples

Small sample programs and tests in the various supported languages.

libs

The build result location and required software libraries for the various supported languages.

Building libpd

Core build requirments:

  • Unix command shell: bash, dash, etc
  • C compiler chain: gcc/clang & make

Note: The various language wrappers may have additional requirements.

Currently the main Makefile builds a dynamic lib on Windows (in MinGW), Linux, & macOS and has the following targets:

  • libpd: build the libpd C core, default if no target is specified
  • csharplib: build libpdcsharp
  • javalib: build libpdnative and the jni wrapper
  • javadoc: generate Java HTML documentation
  • javasrc: create a Java source jar
  • clean: remove object files
  • clobber: remove linked library files
  • install: install libpd C library and C/C++* headers, set location with prefix= (default: /usr/local)
  • uninstall: remove libpd C library and C/C++ headers, set location with prefix= (default: /usr/local)

* C++ headers are only installed if the C utility layers were built as well (ie. UTIL=true), see below.

Makefile options allow for conditional compilation of libpd util and pd extra externals sources into libpd as well as other options:

  • UTIL=true: compile utilities in libpd_wrapper/util (default)
  • EXTRA=true: compile pure-data/extra externals which are then inited in libpd_init() (default)
  • MULTI=true: compile with multiple instance support
  • DOUBLE=true: compile with double-precision support
  • DEBUG=true: compile with debug symbols & no optimizations
  • STATIC=true: compile static library (in addition to shared library)
  • FAT_LIB=true: compile universal "fat" lib with multiple architectures (macOS only)
  • LOCALE=false: do not set the LC_NUMERIC number format to the default "C" locale* (default)
  • PORTAUDIO=true: compile with portaudio support (currently JAVA jni only)
  • JAVA_HOME=/path/to/jdk: specify the path to the Java Development Kit

To build the libpd C core with default options:

make

To build libpd without the util libs and extra externals:

make UTIL=false EXTRA=false

Note: The C++ wrapper requires UTIL=true as it uses the ringbuffer.

* See the Known Issues section for more info.

If you need to add custom search paths to the CFLAGS or LDFLAGS, you can specify them when building via the ADDITIONAL_* variables:

make ADDITIONAL_CFLAGS="-I/usr/local/include" \
     ADDITIONAL_LDFLAGS="-L/usr/local/lib"

Once libpd has built successfully, the compiled libraries will be found in the libs directory.

Linux & BSD

Install the core build requirements using your distribution's package manager. For Debian, you can install the compiler chain, autotools, & gettext with:

sudo apt-get install build-essentials

macOS

macOS is built on top of a BSD system and the bash or zsh commandline can be accessed with the Terminal application in the /Applications/Utility directory.

Xcode

The clang compiler and associated tools are provided by Apple. If you are running macOS 10.9+, you do not need to install the full Xcode application and can install the Commandline Tools Package only by running the following:

xcode-select --install

If you are running macOS 10.6 - 10.8, you will need to install Xcode from the Mac App Store or downloaded from http://developer.apple.com

Fat Libs

By building with the FAT_LIB=true Makefile option, libpd will be compiled with support for multiple architectures depending on the detected system version:

  • macOS <= 10.13: i386 (32 bit Intel) & x86_64 (64 bit Intel)
  • macOS >= 11.0: arm64 (64 bit Arm) & x86_64 (64 bit Intel)

To override autodetection, specify the -arch flags directly using the FAT_ARCHS Makefile option:

make FAT_LIB=true FAT_ARCHS="-arch i386 -arch x86_64"

Windows

libpd on Windows can be built with MinGW which provides the core build requirements: a compiler chain & shell environment. It is recommended to use the Msys2 distribution which provides both a Unix command shell and MinGW. Download the Msys2 "x86_64" 64 bit installer (or "i686" if you are using 32 bit Windows) from:

http://www.msys2.org/

Then install to the default location (C:\msys32 or C:\msys64) and follow the setup/update info on the Msys2 webpage.

Msys2 provides both 32 and 64 bit MinGW and command shells which are used to compile for 32 or 64 bit, respectively. Due to how MinGW is designed, you cannot build a 64 bit libpd with a 32 bit MinGW and vice versa.

Note: Msys2 development seems to change frequently, so some of the package names below may have changed after this document was written.

Open an Msys2 shell and install the compiler chain & make via:

# 32 bit
pacman -S mingw-w64-i686-toolchain mingw-w64-i686-clang make

# 64 bit
pacman -S mingw-w64-x86_64-toolchain mingw-w64-x86_64-clang make

You can also search for packages in Msys2 with pacman -S -s <searchterm>.

Once the packages are installed, you should now be ready to build libpd.

Note: For 64 bit Windows, build Pd with the following additional C flags to ensure long integers are the correct length:

make ADDITIONAL_CFLAGS='-DPD_LONGINTTYPE="long long"'

If you run into strange errors such as /bin/sh: cc: command not found, try closing and reopening your shell window before building again.

Double-Precision Support

By default, libpd computes numbers and samples internally as single-precision 32-bit floats. This is fast and good enough for most general usage. If you are working with small numbers beyond 6 decimal points, however, you will need a higher degree of precision.

To enable double-precision 64-bit floating point support, build libpd with -DPD_FLOATSIZE=64 in the CFLAGS. The libpd makefile provides the DOUBLE makefile variable for this:

make DOUBLE=true

Now utilize the libpd API which use the double type, such as the libpd double hook, libpd_add_double(), and libpd_process_double().

To double-check your build, the following will print a 1 if double-precision support is enabled:

printf("double-precision %d\n", (int)(sizeof(t_float)/8));

Loading Externals

Libpd can load pre-compiled dynamic libraries of external objects in the same manner as desktop Pd if it is compiled with the -ldl LDFLAG. This is done by default in the Makefile. The main difference is that libpd does not inherit the same search paths by default, so paths outside of those specified by the loading patch with [declare] objects need to be added via libpd's "add to search path" function.

Multi-Instance Compatibility

If libpd is compiled with multi-instance support via make MULIT=true and -DPDINSTANCE -DPDTHREADS are defined, it may have trouble loading dynamic externals which are compiled without them:

vbap.pd_linux: vbap.pd_linux: undefined symbol: pd_this
 vbap
... couldn't create

In this case, the vbap external needs to be recompiled with the -DPDINSTANCE -DPDTHREADS CFLAGS defined to add multi-instance support to match.

C++

The C++ wrapper is inspired by the Java wrapper and provides a PdBase class as well as listener, list, and message type classes. This is a header only library so you only need to include the cpp directory in your project. You also may need to add libpd_wrapper/util to you include paths.

Sample programs are found in samples/cpp.

Multiple Instance Support

By default, PdBase always wraps to the single main libpd instance, so it is recommended to only use one instance of PdBase.

If PDINSTANCE is defined, each PdBase will wrap a separate libpd instance.

To enable multiple instance support:

  • Build libpd with make MULTI=true or with CFLAGS -DPDINSTANCE -DPDTHREADS
  • Build the C++ program using PdBase.hpp with CPPFLAGS -DPDINSTANCE

C#

Installation from NuGet

The libpd C# library is available as a NuGet package:

https://www.nuget.org/packages/LibPdBinding

If your platform's native libpdcsharp.(so/dll) is not included, you have to build it yourself following and copy the resulting file to the output directory. Batch scripts for compilation on Windows with MinGW are included.

Building yourself

The C# library expects a file libpdcsharp.(so/dll) in its directory. Before using the project, you need to compile it:

make csharplib

Include csharp/LibPdBinding.csproj in your solution and reference the project in your application. See csharp/README.txt for details.

Windows

The wrapper can be built with MinGW. See the previous "Windows" section for instructions on setting up a MinGW-based build environment using Msys2.

Build libpdcsharp using the the .bat DOS batch file wrappers for make to match which MinGW you are using:

# 32 bit
./mingw32_build_csharp.bat

# 64 bit
./mingw64_build_csharp.bat

Usually you want the 32 bit version, as it will work on 64 bit Windows as well. However so C# environments require a 64 bit version, Unity 5 for instance.

Once the build is finished, a libpdcsharp.(so/dll) library should be found in the libs directory

You also may need to use the libwinpthread library along with libpdcsharp. This included with libpd in the libs directory, either within libs/mingw32 or libs/mingw64. For a current version of libwinpthread-1.dll search in your Msys2 installation's bin directory.

Note: If you have installed Msys2 to a non-default location, you will need to change the variable for %MSYS2% in the .bat files.

Linux

If you want to use the library on Linux with Mono, you need the following changes to the LibPdBinding project:

  1. Compile the .so file with make csharplib.
  2. Remove libpdcsharp.dll and libwinpthread-1.dll from LibPdBinding project.
  3. Add libpdcsharp.so to the LibPdBinding project.
  4. Set "Copy to Output Directory" for libpdcsharp.so to "Copy always"

Java

Precompiled Binaries

May be out of date

Ready-made binaries for Java are available at the libpd-java-build repository:

https://github.com/wivlaro/libpd-java-build

Building Yourself

You will need the Java Development Kit (JDK) to build the libpd Java lib. Make sure the JDK/bin path is added to your $PATH shell variable and, optionally, the JAVA_HOME variable points to the JDK location.

Build the libpd Java lib with:

make javalib

This should result in a libpd.jar and pdnative.(so/dll) in the libs directory.

Optionally, you can build libpd with Eclipse using the .classpath & .project workspace files.

You can also build a libpd source jar and Java HTML documentation:

make javasrc
make javadoc

This should result in a libs/libpd-sources.jar and a javadoc directory.

Linux & BSD

Install the JDK via your distributions package manager.

macOS

Install the JDK either by downloading an installer package or by using one of the open source package managers for macOS:

Windows

The wrapper can be built with MinGW. See the previous "Windows" section for instructions on setting up a MinGW-based build environment using Msys2.

Install the JDK by downloading an installer package, then add the path to JDK/bin to your $PATH shell variable and the JDK path to $JAVA_HOME (optional). If the JDK is installed to C:\Program Files\Java\jdk1.8.0_152, add the following to your ~/.bash_profile:

# add JDK bin path
export PATH=$PATH:'C:\Program Files\Java\jdk1.8.0_152\bin'

# JDK path (optional)
export JAVA_HOME=C:/Program\ Files/Java/jdk1.8.0_152

Restart your shell if it's open.

Build the libpd javalib with:

make javalib

You can also set the JAVA_HOME path when running make with:

make javalib JAVA_HOME=C:/Program\ Files/Java/jdk1.8.0_152

Once the build is finished, you should find libpd.jar and pdnative.(so/dll) in the libs directory.

Objective-C

The Objective-C wrapper is designed to be used on iOS and macOS and includes a (currently iOS-only) audio unit and audio manager for sound I/O.

Xcode Project

libpd.xcodeproj provides an Xcode project to build libpd + the Obj-C wrapper as a static library for iOS & macOS. Drag the libpd project into your existing Xcode project, then add libpd-ios (or libpd-osx) to the Linked Frameworks and Libraries in the General tab of your project target.

The Xcode project builds the following targets:

  • libpd-ios: libpd and the Obj-C wrapper for iOS
  • libpd-osx: libpd and the Obj-C wrapper for macOS
  • libpd-ios-multi: libpd for iOS with multiple instance support
  • libpd-osx-multi: libpd for macOS with multiple instance support

For detailed instructions, see Working with libpd in Xcode

If you are unfamiliar with how static libraries work or how to use them in Xcode, see this useful tutorial.

Note: libpd is tested with the release versions of Xcode. It is recommended that you avoid using beta or developer preview versions.

CocoaPods

If you are using Xcode to build iOS apps, you can use CocoaPods to add libpd to your project.

Use the following in your CocoaPods podfile:

pod 'libpd', :git => 'https://github.com/libpd/libpd', :submodules => true

To specify a stable version tag, use the :tag option:

pod 'libpd', :git => 'https://github.com/libpd/libpd', :submodules => true, :tag => '0.12.1'

Python

The Python wrapper provides a "pylibpd" module mirroring the libpd C API. Build the wrapper with:

cd python
make

See the sample programs in samples/python.

If you have multiple versions of Python on your system, you can specify which is used to build the module via the PYTHON makefile option:

make PYTHON=python3

If you are building for 64-bit Windows, you may need to set the additional MS_WIN64 flag:

make CFLAGS="-DMS_WIN64=1"

pyaudio

Some samples require the "pyaudio" Portaudio library.

If you install pyaudio with pip, you will need to install Portaudio first. On macOS, for example, you can install it with Homebrew:

brew install portaudio

Rust

There is currently a third party Rust wrapper for libpd called libpd-rs which is actively maintained.

libpd-rs uses a fork of libpd which is frequently synchronized with upstream.

Please visit the repository for detailed information.

Building with CMake

CMake can be used to build the libpd C library.

CMake is a cross-platform, open-source build system. CMake is used to control the software compilation process using simple platform and compiler independent configuration files, and generate native makefiles and workspaces that can be used in the compiler environment of your choice.

Dependencies

  • CMake: You can download CMake for your platform here. The minimum version is 2.8.11.
  • pthreads: On Windows, you need to provide a pthreads library.

If you are using MinGW, you can use the libwinpthread-1.dll included in the libs/mingw* directories in this repository. Alternatively, you can also download it or compile it yourself from the sources here. This will typically result in pthreadGC2.(dll/lib).

If you are using Visual Studio, you need to provide a pthreads library compiled for Visual Studio either by downloading it or compiling it yourself. See here. Be careful to download / compile the right version for your setup. This would typically be pthreadVC2.(dll/lib).

Configuring the build

One way to configure CMake is to use the CMake GUI. The GUI will list the variables that can be provided to configure the build. The variables can also be specified in the command-line interface (See below for an example)

In this step you can select the features to be included with PD_EXTRA, PD_LOCALE, PD_MULTI and PD_UTILS as described above. You can also enable building the C sample programs using PD_BUILD_C_EXAMPLES.

When using Microsoft Visual Studio (MSVC), you will be requested to provide a path to the pthreads library and its headers using variables CMAKE_THREAD_LIBS_INIT and PTHREADS_INCLUDE_DIR.

On macOS, you can define different deployment target and architectures from your current system using the variables CMAKE_OSX_DEPLOYMENT_TARGET and CMAKE_OSX_ARCHITECTURES.

You can specify additional compilation flags using the variable CMAKE_C_FLAGS.

CMake can now generate Makefiles, a MSVC solution, or an XCode project.

Building

After generation, depending on your platform you can navigate to the directory where CMake generated the build files and then:

  • On Linux: run make
  • On Windows: open the MSVC solution and build it
  • On macOS: open the XCode project and build it

Of course you can also use CMake itself to build libpd by running this on the command line:

cd <path/to/build/files/generated/by/CMake>
cmake --build .

Windows cross-compilation on Linux

You can build Windows binaries in Linux using MinGW. This will only build the static and shared libraries, and not the C# bindings.

The easiest way is to set up a toolchain file for CMake pointing to all the necessary MinGW tools. For debian-based distributions, the file would contain the following:

SET(CMAKE_SYSTEM_NAME Windows)

SET(CMAKE_C_COMPILER x86_64-w64-mingw32-gcc)
SET(CMAKE_CXX_COMPILER x86_64-w64-mingw32-g++)
SET(CMAKE_RC_COMPILER x86_64-w64-mingw32-windres)

SET(CMAKE_FIND_ROOT_PATH /usr/x86_64-w64-mingw32)

SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

Note paths and binary names might vary in other distributions.

You can then use the CMAKE_TOOLCHAIN_FILE option to tell CMake to load the settings from your file. For example, if the above is saved to $HOME/.local/share/cmake/toolchain-mingw-x86_64-w64.cmake, then CMake can be invoked with

cmake -DCMAKE_TOOLCHAIN_FILE=$HOME/.local/share/cmake/toolchain-mingw-x86_64-w64.cmake

followed by any other CMake options you'd normally use, and the source directory.

Command-line examples

Here are examples of how to download, configure and build the latest libpd on the command line using CMake.

Linux:

git clone https://github.com/libpd/libpd
cd libpd
git submodule init
git submodule update
mkdir build && cd build
cmake .. -DPD_MULTI:BOOL=ON -DPD_BUILD_C_EXAMPLES:BOOL=ON
cmake --build .

Windows / MSVC:

git clone https://github.com/libpd/libpd
cd libpd
git submodule init
git submodule update
mkdir build && cd build
cmake .. -DCMAKE_THREAD_LIBS_INIT:PATH=</path/to/pthreadsVC2.lib> -DPTHREADS_INCLUDE_DIR:PATH=</path/to/pthread/header/files>
cmake --build .

Limitations

Currently the CMake script is not capable of building the C# or the Java bindings. Please use the makefile for that.

Known Issues

How do I use libpd in Visual Studio?

Historically, Pd was designed to be built using the open source gcc & make and did not directly support being built in Visual Studio on Windows, mainly due to differences in C compiler versions.

Recently, the code has been adapted and a CMake build script has been developed that should allow you to generate a MSVC solution. The only important thing you need to be careful about is providing a pthreads library compiled for Visual Studio. See the section above about building with CMake.

Another possible approach is building the libpd C library using gcc and make using MinGW in msys on Windows. You can use the resulting .dll, .def, & .lib files with Visual Studio and the cpp wrapper is provided as an all header library so it should work directly within VS as well.

After building libpd in msys, you can "install" it to a temp directory to get only the libs and headers you need:

make install prefix=libpd-build

Problems with numbers in loaded patches or DSP output always seems to be 0

Pd expects numbers to be in an English format, ie. "0.3". If you are using a non-English language or locale setting on your system, it may be encoding numbers differently, ie. "0,3". This can lead to weird bugs in loaded patches where numbers seem wrong or end up truncated as 0.

By default, libpd is built with the LC_NUMERIC locale set to the "C" default, so this shouldn't be a problem. If you are using libpd within a project that requires specific locale settings, you will need to make sure libpd's LC_NUMERIC is left alone or at least reset it to "C" if working with a different numeric setting. If a non-English LC_NUMERIC is set, you will run into the number parsing issues mentioned above.

If you need to control LC_NUMERIC manually, you can build libpd without the call to setlocale() in libpd_init using the SETLOCALE=false makefile option or by setting the LIBPD_NO_NUMERIC define.

See #130 for more info.

libpd's People

Contributors

alisomay avatar artdent avatar chr15m avatar clwe avatar danomatika avatar eldruin avatar funkyfourier avatar gintas avatar jcelerier avatar jim-lofelt avatar lhondareyte avatar meshula avatar mgsx-dev avatar millerpuckette avatar monkeyswarm avatar mxa avatar myqwil avatar nettoyeurny avatar pierreguillot avatar residuum avatar rpattabi avatar rvega avatar safetydank avatar shakfu avatar tebjan avatar tiagosr avatar tkirshboim avatar umlaeute avatar wivlaro avatar yairsz avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

libpd's Issues

On master branch, error building for 64-bit (using Xcode 5.1 Beta 5B90f)

Heads up that there seems to be an error building for the default 64 bit architecture in the upcoming Xcode 5.1 release (which defaults to 64 bit).

"_atom_string", referenced from:
_loudbug_postatom in loud.o
_loudbug_postbinbuf in loud.o
"_binbuf_getnatom", referenced from:
_loudbug_postbinbuf in loud.o
"_binbuf_getvec", referenced from:
_loudbug_postbinbuf in loud.o
"_bug", referenced from:
_loudbug_bug in loud.o
_fitterstate_dosetup in fitter.o
_fitter_drop in fitter.o
_fitter_getfloat in fitter.o
_fitter_getsymbol in fitter.o
_fitter_setmode in fitter.o
_fitterstate_bang in fitter.o
...
(maybe you meant: _loudbug_bug)
"_class_addbang", referenced from:
_fitterstate_dosetup in fitter.o
_counter_setup in counter.o
"_class_addmethod", referenced from:
_moog_tilde_setup in moog~.o
_fitterstate_dosetup in fitter.o
_counter_setup in counter.o
"_class_addsymbol", referenced from:
_fitterstate_dosetup in fitter.o
"_class_doaddfloat", referenced from:
_counter_setup in counter.o
"_class_getname", referenced from:
_loud_error in loud.o
_loud_errand in loud.o
_loud_classarg in loud.o
_loud_warning in loud.o
_loud_floatarg in loud.o
_loudx_error in loud.o
_loudx_setcontext in loud.o
...
"_class_new", referenced from:
_moog_tilde_setup in moog~.o
_fitterstate_dosetup in fitter.o
_counter_setup in counter.o
"_dsp_add", referenced from:
_dsp_add_moog in moog~.o
(maybe you meant: _dsp_add_moog)
"_freebytes", referenced from:
_loudx_setcontext in loud.o
_loudx_freecontext in loud.o
_fitter_drop in fitter.o
"_gensym", referenced from:
_moog_tilde_setup in moog~.o
_loud_checkint in loud.o
_fitterstate_dosetup in fitter.o
_fitter_setmode in fitter.o
_fitterstate_bang in fitter.o
_fitterstate_symbol in fitter.o
_counter_setup in counter.o
...
"_getbytes", referenced from:
_loudx_setcontext in loud.o
_loudx_newcontext in loud.o
_fitter_setup in fitter.o
"_inlet_new", referenced from:
_moog_new in moog~.o
_counter_new in counter.o
"_nullfn", referenced from:
_moog_tilde_setup in moog~.o
"_outlet_bang", referenced from:
_counter_dobang in counter.o
"_outlet_float", referenced from:
_counter_dobang in counter.o
"_outlet_new", referenced from:
_moog_new in moog~.o
_counter_new in counter.o
"_pd_bang", referenced from:
_fitterstate_dosetup in fitter.o
"_pd_bind", referenced from:
_fitterstate_dosetup in fitter.o
"_pd_error", referenced from:
_loud_error in loud.o
_loudx_error in loud.o
"_pd_free", referenced from:
_counter_free in counter.o
"_pd_new", referenced from:
_moog_new in moog~.o
_fitterstate_dosetup in fitter.o
_counter_new in counter.o
"_pd_typedmess", referenced from:
_fitter_setmode in fitter.o
_fitterstate_bang in fitter.o
_fitterstate_symbol in fitter.o
"_post", referenced from:
_moog_new in moog~.o
_loud_error in loud.o
_loud_errand in loud.o
_loud_warning in loud.o
_loudx_error in loud.o
_loudx_errand in loud.o
_loudx_warning in loud.o
...
(maybe you meant: OBJC_IVAR$_Bridges._postOperation, _loudbug_postatom , _loudbug_post , _loudbug_postbinbuf )
"s", referenced from:
_fitter_setmode in fitter.o
_fitterstate_reply in fitter.o
"_s_anything", referenced from:
_counter_new in counter.o
"_s_float", referenced from:
_loud_checkint in loud.o
_counter_new in counter.o
"_s_signal", referenced from:
_moog_new in moog~.o
"_startpost", referenced from:
_loud_error in loud.o
_loudx_error in loud.o
(maybe you meant: _loudbug_startpost)
ld: symbol(s) not found for architecture x86_64

Ocassional crashes on libpd_queued_receive_pd_messages

Hi.
I've been using the cpp-queued branch of libpd within a QT C++ application compiled with clang in MacOS.

To get messages from PD, I created a receiver class based on the one in the cpp folder, and to actually receive the messages, I am calling PdBase::receiveMessages() from the callback of a QTTimer (which runs in the main thread of the app).

Every once in a while (I have to sit and wait for a few minutes) the app will crash. I ran the app within lldb (clang's debugger) a few times and I found weird behavior in libpd_queued_receive_pd_messages every time before the crash. The stack trace:

(lldb) thread backtrace
* thread #1: tid = 0x726c, 0x00007fff8cf88670 libsystem_c.dylib`strlen + 16, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x00007fff8cf88670 libsystem_c.dylib`strlen + 16
    frame #1: 0x0000000100031e65 Bounces`pd::PdBase::PdContext::_bang(char const*) [inlined] std::__1::char_traits<char>::length(__s=0x0000000000000000) + 8 at string:651
    frame #2: 0x0000000100031e5d Bounces`pd::PdBase::PdContext::_bang(char const*) [inlined] basic_string(this=0x00000001000c0df0) at string:1866
    frame #3: 0x0000000100031e5d Bounces`pd::PdBase::PdContext::_bang(char const*) [inlined] basic_string(this=0x00000001000c0df0) at string:1870
    frame #4: 0x0000000100031e5d Bounces`pd::PdBase::PdContext::_bang(source=0x0000000000000000) + 45 at PdBase.cpp:999
    frame #5: 0x00000001000c15a7 Bounces`libpd_queued_receive_pd_messages [inlined] receive_bang + 18 at z_queued.c:68
  * frame #6: 0x00000001000c1595 Bounces`libpd_queued_receive_pd_messages + 133 at z_queued.c:343
    frame #7: 0x00000001000388b3 Bounces`DBM::PdBridge::qt_static_metacall(_o=0x000000010521d2c0, _c=<unavailable>, _id=<unavailable>, _a=<unavailable>) + 1491 at moc_PdBridge.cpp:148

...

    frame #28: 0x0000000100020ee8 Bounces`main(argv=1, args=<unavailable>) + 344 at main.cpp:18
    frame #29: 0x0000000100006d24 Bounces`start + 52

Playing with the debugger commands, I went to z_queued.c and around line 342:

      case LIBPD_BANG: {
        receive_bang(p, &buffer);
        break;
      }

if I try to print the value of the variable p, I get the following error: error: Couldn't materialize struct: the variable 'p' has no location, it may have been optimized out Errored out in Execute, couldn't PrepareToExecuteJITExpression. Going a couple of steps into the stack, in the PdBase::PdContext::bang(char const) function, I can see that the char_ parameter is Null (0x0000).

This means that Pd is sending a bang with a null "sender name"? doesn't seem likely to me... I added a few "send bang" objects in my patch, to see if the app would crash with other bangs being sent from Pd and received on the c++ side but no problem there, also (perhaps the weirdest part) is I'm not sending any bangs from my original patch, only lists and floats...

How do I investigate this further? I'm no debugger or multi-threading expert...

One thought (perhaps OOT): we are using C++ mutexes to protect sending messages from C++ to Pd, should these be calls to sys_lock() (defined in m_pd.h) instead?

As always, thanks for any the help! :)'

Edit: If it's relevant, I'm compiling with -O3 compiler flag.

eclipse setup problems

The import org.puredata.core cannot be resolved

i get this and dont know how to fix it.
i downloaded libpd for android zip and added it as a library.

any ideas?

thanks

p.s. im new to pdlib and fairly new to android/eclipse

EDIT:
never mind, i found this
http://konkanok.com/2010/11/pure-data-for-android-set-up-guide/
and messed around for a bit to get it working.

now to find out how to actually use this thing :)

update to 0.45-4

puredata has reached 0.45-4.
are there any plans to update libpd?

Crash on arm64 architecture (iOS)

Using libpd on a 64-bit iOS device (and building for the arm64 architecture) results in a segmentation fault during setup.

I have also tried using the pd_045-4 branch of libpd as I was hoping this is perhaps an upstream issue, but that also results in a seg-fault.

A temporary solution is obviously to only build for armv7 and armv7s (32 bit) architectures.

PD Vanilla supports 64-bit on mac so anyone have any ideas why this would be a problem on iOS?

64Bit architecture problem in libpd/puredata/d_ugen.c/ugen_doit() ?

seems to be a problem in libpd/puredata/d_ugen.c/ugen_doit()
when running on iPhone 5s 64bit architecture.
The mess1 macro was messing up the insig param i think.
I hacked it so it works. Not sure what side effects this has. Although mess1 macro only used twice.

//LEE - 64bit architecture prob with mess1 macro. t_gotfn defines a variable arg list which causes prob.
void (_myFunc)(void *x, void *sp);
myFunc = (_getfn((&u->u_obj->ob_pd), (gensym("dsp"))));
myFunc((&u->u_obj->ob_pd), insig);
//EEL

// mess1(&u->u_obj->ob_pd, gensym("dsp"), insig);

How to get the libpdcsharp.dll

Hello,

hope here the right place for my Question.
I want to use the libpd for my C# Project under Windows but i don't know to compile the Dll.
Here is what i tried:

  1. Compile the LibPDBinding Project with VS -> Don't work, Project need the Dll.
  2. Run the Makefile with Cygwin -> Syntax Error: `ifeq ($(UNAME), Darwin) # Mac'
  3. Run the Makefile under OSX -> Error(don't have the Message here)

What else can i try? How to get the Dll?

EXC_BAD_ACCESS in [PdBase closePatch]

Or somewhere in libpd_closefile() (which calls pd_free())

steps to reproduce:

  • Run WaveTables example project on iphone 4s or even in iOS 5 simulator
  • click on the 'Resynthesis' button, selecting the resynthesis.pd patch and closing the other patch.
  • there is an exc_bad_access that leads back to the patch being closed in it's dealloc.

PolyPatch example app also crashes in a similar manner

Seems to be related to the recent commit (SHA: ece36c4) that updated pd core code, closing patches in the example apps works fine with a checkout right before this commit.

libPd "version"

Hi,

Unless I've missed something, libPd doesn't seem to have a "version".

It would be useful if it had a canonical version: .. and even better if this could be queried via the API.

This would enable customers of the API to define compliance against a given API version an programatically verify the version being used is the expected one.

segfault - libpd's 'error' function clobbered by libc's error function

I am using libpd with jMonkeyEngine 3 on Ubuntu Linux (with a mind to go to Android as well).

I have got libpd starting to load my patches, but am getting crashes loading them. Investigating with GDB, I'm getting a call stack that looks like this:

#5  0x00007ffff74f66d5 in error_tail (status=-766945781, errnum=27268384, message=0x10 <Address 0x10 out of bounds>, args=0x7fffe06c58e8)
    at error.c:203
#6  0x00007ffff74f6833 in __error (status=-766945781, errnum=27268384, message=0x10 <Address 0x10 out of bounds>) at error.c:253
#7  0x00007fffd244fbd6 in canvas_objtext (gl=0x1a23980, xpix=449, ypix=336, selected=0, b=0x1a32960) at pure-data/src/g_text.c:102
#8  0x00007fffd244ff7d in canvas_obj (gl=0x1a23980, s=0x18931d0, argc=4, argv=0x1a1d970) at pure-data/src/g_text.c:193
#9  0x00007fffd246a831 in pd_typedmess (x=0x1a23980, s=0x18931d0, argc=4, argv=0x1a1d970) at pure-data/src/m_class.c:685
#10 0x00007fffd2464524 in binbuf_eval (x=0x1a1d020, target=0x1a23980, argc=0, argv=0x0) at pure-data/src/m_binbuf.c:722
#11 0x00007fffd2468baf in binbuf_evalfile (name=0x1a1a760, dir=0x1a00c70) at pure-data/src/m_binbuf.c:1480

The incorrect error function has been called, the one at stack frame 6 is in glibc. The signature for libc's error is error (int status, int errnum, const char *message, ...), but libpd's is error(const char *fmt, ...), so that's the root cause of the segfault.

I've added this to my LDFLAGS in the Makefile -Wl,-Bsymbolic, as recommended here: http://stackoverflow.com/questions/4831856/function-name-collision-in-shared-objects, which has fixed the problem for me though I'm not sure about the other effects of that.

The actual problem I'm having is that it's failing to load the [expr] object. I have run make in pure-data/extra/expr~ and copied the .pd_linux files into my PD search path, but to no avail. Any ideas about that as well?

iOS EXC_BAD_ACCESS on evaluateBangMessage

Hi there,

This seems similar to the issue regarding evaluateFloatMessage that was closed here: #3, however this one is still very much present, for us at least, this time with evaluateBangMessage in PdBase.m.

We get an EXC_BAD_ACCESS when trying to access p on the line:

NSString *src = [[NSString alloc] initWithCString:p->src encoding:NSASCIIStringEncoding];

(or any line that tries to access/print p, for that matter).

Is the fix from the other issue at all transferrable to this? Annoyingly, the bug is very difficult to reproduce. It can occur on both the simulator and device (mainly currently testing on iPhone 5 and iPod 5th Gen both running iOS 7, however we were experiencing this on iOS 6 and a range of other devices, as well), and generally doesn't happen until around 5-10 minutes of having the app running.

We've tried putting checks in to see if p is NULL and returning if so, however we get a crash at that line just the same.

(Btw, what's the easiest way of determining what version of libpd we're using? It would be whichever one was up on the repo roughly 12 months ago).

Really scratching our heads with this one so any help would be much appreciated!

Thanks,
Yuli

External compile issues

Which version of the externals sources should we use with libpd?

Some ofxPd users are running into compile/link issues over things that worked before, so I'm thinking the libpd and pd-extended external versions are out of sync:

In fact the error is related with a duplicate function issue ...
In s_print.c (in libPd) and in zexy.c there is a function :

void verbose(int level, const char *fmt, ...);

That is with the libpd 0.43.2 in ofxPd. I updated to the latest source here (0.43.3) and get different errors, something relating to missing sys_open, etc in zexy (I don't remember exactly).

From the OpenFrameworks forum: http://forum.openframeworks.cc/index.php/topic,6492.msg51276.html#msg51276

Hook-setting functions not included in Makefile

Hi!

I had some problems setting hooks for function calls for Pd, from libpd C API, and the problem was the z_hook_util.h not being included in the PD_FILES tag, in the Makefile.

This gave me access to the libpd_set_(hook) functions, and solved the hook problem I had. Thought I should let you guys know.

errors in Eclipse : newbie starting from "Making Musical Apps" book

Hello -- so I bought this book "Making Musical Apps" and am trying to do the chapter on creating an android app. Pg 62 of the book says to search the Wiki here if the troubleshooting steps listed there do not work.

My problem is that when I imported the pd-for-android projects into Eclipse, they all had red errors. These are the two errors:

  • Project 'AndroidMidi' is missing required source folder: 'gen'
  • The container 'Android Dependencies' references non existing library '/Android/PureData/pd-for-android/midi/AndroidMidi/bin/androidmidi.jar'

Sorry if this has an obvious solution. The authors of the book seem to go out of their way to say you will not possibly encounter errors aside from Eclipse's strange glitches, so I thought I better ask here if anyone knows what the problem is. I'm on a Mac OSX setup.

Thanks!
Bob

objc wrapper should concatenate print messages

I notice the obj wrapper dosen't concatenate the print messages onto a single line,

ie you get this

2013-01-11 21:44:17.077 PdParty[60066:c07] Pd Console: PD: PATCH
2013-01-11 21:44:17.081 PdParty[60066:c07] Pd Console:  
2013-01-11 21:44:17.083 PdParty[60066:c07] Pd Console: OPENED:
2013-01-11 21:44:17.083 PdParty[60066:c07] Pd Console:  
2013-01-11 21:44:17.084 PdParty[60066:c07] Pd Console: 1002
2013-01-11 21:44:17.085 PdParty[60066:c07] Pd Console: 

instead of

2013-01-11 21:44:17.077 PdParty[60066:c07] Pd Console: PD: PATCH OPENED: 1002

I handle this in the CPP wrapper and can add it to the obj wrapper, but maybe this should be done in C on a lower level. Any thoughts?

pollQueue timer in PdBase is blocked during UIScrollView movement

I made a quick test with a UIScrollView along with printing and dreamless' problem does seem to be more to do with the inherent nature of UIScrollView (how it privately handles touches and animations) than I expected. I made a branch with his fix, along with my suggestions, in pdbase_timer. It has been tested in the simulator and on my iphone 4s and I can verify that you can use UIScrollViews, send pd parameters, and receive pd parameters, all at the same time without any hiccup in the timer.

python + libpd problem

Hi everybody,

I tried to get libpd working in python. After some initial problems, the test.py works with python 2.7 (3.3 gives me syntax errors). Also pygame_fun_test.py works fine.... However, when I try to run the echo.py example I get an error message. The message looks like this:

Python 2.7.3 (v2.7.3:70274d53c1dd, Apr 9 2012, 20:52:43)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "copyright", "credits" or "license()" for more information.

================================ RESTART ================================

Traceback (most recent call last):
File "/libpd-master/python/echo.py", line 24, in
data = stream.read(bs)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pyaudio.py", line 605, in read
return pa.read_stream(self._stream, num_frames)
IOError: [Errno Input overflowed] -9981

================================ RESTART ================================

Does anybody have an idea where this error comes from? I would be also interesting to hear more about setups which have been used successfully. I am on a Mac (OS X 10.8), using python 2.7 from python.org.

Thank you so much!
Best regards,
iohanna

iOS 8/ARM64 EXC_BAD_ACCESS (SIGSEGV) @ [PdBase openFile:path:]

Greetings,

I've been tasked to develop a music learning app using libpd. Everything went well until I made an Archive build to test the app on different devices via iTunes before publishing it. It seems that there is some sort of issue when the library attempts to read the pd files when the device has iOS 8 installed. Said issue crashes the app. I've also tested on iOS 7.1.2 devices without any issue, but the most mind-boggling part is that the app has always worked with debug build on iOS 8 devices. By the way, I'm not completely sure if it has anything to do with 64 bytes architecture, since the two devices that I can test with are an iPhone 5s and an iPad Air. I hope someone can confirm this, or if someone has encountered a similar issue, please shed some light for me.

I'm attaching a crash log of the app. Thank you in advance for your time.

Incident Identifier: D6F2EF39-A24C-4F18-A442-182888AA1E96
CrashReporter Key: f7f6b3f6e1ec6a30078e3bc9f24bbfe32e609b70
Hardware Model: iPhone6,1
Process: pdTest [1652]
Path: /private/var/mobile/Containers/Bundle/Application/382D5A2F-0A01-4D1D-BDF7-E004BABD7020/pdTest.app/pdTest
Identifier: net.easysol.pdTest
Version: 1 (1.0)
Code Type: ARM-64 (Native)
Parent Process: launchd [1]

Date/Time: 2014-11-14 09:07:59.329 -0500
Launch Time: 2014-11-14 09:07:59.156 -0500
OS Version: iOS 8.1 (12B411)
Report Version: 105

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000008
Triggered by Thread: 0

Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 pdTest 0x0000000100049d10 tabread4_tilde_dsp + 40
1 pdTest 0x00000001000582c0 ugen_doit + 496
2 pdTest 0x00000001000583fc ugen_doit + 812
3 pdTest 0x0000000100057e4c ugen_done_graph + 976
4 pdTest 0x0000000100061a8c canvas_dodsp + 244
5 pdTest 0x0000000100060404 canvas_start_dsp + 80
6 pdTest 0x000000010008b83c glob_evalfile + 152
7 pdTest 0x00000001000a1f80 +[PdBase openFile:path:] + 88
8 pdTest 0x0000000100046fc4 -ViewController viewDidLoad
9 UIKit 0x000000018a2f4e80 -[UIViewController loadViewIfRequired] + 688
10 UIKit 0x000000018a2f4b90 -[UIViewController view] + 28
11 UIKit 0x000000018a2fb258 -[UIWindow addRootViewControllerViewIfPossible] + 68
12 UIKit 0x000000018a2f89d8 -[UIWindow _setHidden:forced:] + 256
13 UIKit 0x000000018a369a00 -[UIWindow makeKeyAndVisible] + 52
14 UIKit 0x000000018a57d434 -[UIApplication _callInitializationDelegatesForMainScene:transitionContext:] + 2800
15 UIKit 0x000000018a57f9ac -[UIApplication _runWithMainScene:transitionContext:completion:] + 1476
16 UIKit 0x000000018a57e044 -[UIApplication workspaceDidEndTransaction:] + 180
17 FrontBoardServices 0x000000018dda963c __31-[FBSSerialQueue performAsync:]_block_invoke + 24
18 CoreFoundation 0x0000000185afe120 CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK + 16
19 CoreFoundation 0x0000000185afd228 __CFRunLoopDoBlocks + 308
20 CoreFoundation 0x0000000185afb84c __CFRunLoopRun + 1752
21 CoreFoundation 0x0000000185a291f0 CFRunLoopRunSpecific + 392
22 UIKit 0x000000018a35f788 -[UIApplication _run] + 548
23 UIKit 0x000000018a35a780 UIApplicationMain + 1484
24 pdTest 0x000000010004723c main (main.m:14)
25 libdyld.dylib 0x00000001968a6a04 start + 0

P.S.: I'm also linking this blog which I used to be able to archive the build:
http://charlesmartin.com.au/blog/2012/9/10/submitting-apps-with-libpd

What is uuids.h in x_misc.c?

Hi. I was compiling libpd under mingw on windows 7 and I kept getting a compiler error because uuids.h was not found (included from pure-data/src/x_misc.c). I commented out the include and libpd compiled fine and my app seems to be running fine. Am I breaking something by leaving uuids.h out? should I worry about this file?
Thanks.

crashes opening patch

hi everybody,

I'm getting quite a lot of crashes just opening a patch (the patch contains externals I wrote, a couple of crash reports attached), and I'm wondering if I should look for bugs in libpd, or in my app (iOS 6.0), or in my patch, or in the externals used in the patch...

...any idea?

-------------------------------- example 1 --------------------------------

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread:  2

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0:
0   testapp1                          0x000d31c6 dogensym (m_class.c:486)
1   testapp1                          0x000d2ffc gensym (m_class.c:512)
2   testapp1                          0x000cd8b4 binbuf_text (m_binbuf.c:174)
3   testapp1                          0x000cebc4 binbuf_read (m_binbuf.c:801)
4   testapp1                          0x000d23e2 binbuf_evalfile (m_binbuf.c:1468)
5   testapp1                          0x000d346a new_anything (m_class.c:565)
6   testapp1                          0x000d3aba pd_typedmess (m_class.c:769)
7   testapp1                          0x000ce96e binbuf_eval (m_binbuf.c:722)
8   testapp1                          0x000bdb70 canvas_objtext (g_text.c:96)
9   testapp1                          0x000bda44 canvas_obj (g_text.c:194)
10  testapp1                          0x000d36ae pd_typedmess (m_class.c:685)
11  testapp1                          0x000ce96e binbuf_eval (m_binbuf.c:722)
12  testapp1                          0x000d2424 binbuf_evalfile (m_binbuf.c:1480)
13  testapp1                          0x000d2472 glob_evalfile (m_binbuf.c:1496)
14  testapp1                          0x000ee0d8 libpd_openfile (z_libpd.c:341)
15  testapp1                          0x000f010a +PdBase openFile:path:
[...]

-------------------------------- example 2 --------------------------------

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000
Crashed Thread:  0

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   testapp1                          0x00171416 internal_arbitrary_thread_stack_pcs + 106
1   testapp1                          0x00171474 testflight_thread_backtrace + 16
2   testapp1                          0x00155e5e testflight_backtrace + 234
3   testapp1                          0x00156b48 TFSignalHandler + 260
4   libsystem_c.dylib                0x33efbd38 _sigtramp + 40
5   libsystem_c.dylib                0x33ec4506 szone_malloc_should_clear + 1278
6   testapp1                          0x000b3a2e binbuf_eval (m_binbuf.c:722)
7   testapp1                          0x000a2c30 canvas_objtext (g_text.c:96)
8   testapp1                          0x000a2b04 canvas_obj (g_text.c:194)
9   testapp1                          0x000b876e pd_typedmess (m_class.c:685)
10  testapp1                          0x000b3a2e binbuf_eval (m_binbuf.c:722)
11  testapp1                          0x000b74e4 binbuf_evalfile (m_binbuf.c:1480)
12  testapp1                          0x000b852a new_anything (m_class.c:565)
13  testapp1                          0x000b8b7a pd_typedmess (m_class.c:769)
14  testapp1                          0x000b3a2e binbuf_eval (m_binbuf.c:722)
15  testapp1                          0x000a2c30 canvas_objtext (g_text.c:96)
16  testapp1                          0x000a2b04 canvas_obj (g_text.c:194)
17  testapp1                          0x000b876e pd_typedmess (m_class.c:685)
18  testapp1                          0x000b3a2e binbuf_eval (m_binbuf.c:722)
19  testapp1                          0x000b74e4 binbuf_evalfile (m_binbuf.c:1480)
20  testapp1                          0x000b7532 glob_evalfile (m_binbuf.c:1496)
21  testapp1                          0x000d3198 libpd_openfile (z_libpd.c:341)
22  testapp1                          0x000d51ca +PdBase openFile:path:
[...]

(testflight is a framework to help testing apps on iOS)

Makefile for cppTest on linux

it would be great to have a linux Makefiles to build "all" samples (well, those that make sense anyhow) on linux.

LibPD with MIDI on iOS

Hi, I don't if its the right place for my question.
My Question is, how to setup the MIDI routing for libPD
especially for Wifi or iRig Connection.

Thanks a lot

On branch pd_045-4, error building for 64-bit (using Xcode 5.1 Beta 5B90f)

This is more of a heads up that there seems to be a bug when building with the newest beta Xcode, which defaults to 64 bit architecture. Using the latest Xcode beta, building for 64 bit on branch pd_045-4 I get this error:

Error: /libpd/pure-data/src/x_array.c:608:5: Implicit declaration of function 'alloca' is invalid in C99

screen shot 2014-02-10 at 19 25 56

mic feedback/no audio processing in iOS

After working on other stuff for the last 2 months, I'm back to an iOS app using libpd. Something seems to have happened in the meantime, and any iOS app I make with libpd+the objc layer doesn't seem to process audio. When I enable input, I get direct mic feedback. It's weird, it wasn't doing this before.

autotools ?

as mentioned in #53, it might be good to use some complex build-system for building libraries, e.g. autotools.

since i do like autotools, i'm happy to help here

gem support

Hello,

Just wondering if liPid can be used with gem?

Problem with "z_queued.h"

In trying to set-up an iOS project with libpd, I keep getting an error that "z_queued.h" is not included....I have set up the project exactly as described in the "Making Musical Apps" book...very confused!

PdAudioUnit plays input audio buffers on output hardware when working without a dac~ (iOS)

Patches that contain an adc~ object without a dac~ object (or an active signal path to the dac~) cause input audio buffers to be played on output hardware. In addition to this being incorrect behaviour, it can also lead to acoustic feedback. The cause of this issue is related to the way in which PdAudioUnit passes audio buffers to PD.

Observe the audio render callback of PdAudioUnit.
(source: https://github.com/libpd/libpd/blob/master/objc/PdAudioUnit.m#L86-103)

static OSStatus AudioRenderCallback(void *inRefCon,
                                    AudioUnitRenderActionFlags *ioActionFlags,
                                    const AudioTimeStamp *inTimeStamp,
                                    UInt32 inBusNumber,
                                    UInt32 inNumberFrames,
                                    AudioBufferList *ioData) {

    PdAudioUnit *pdAudioUnit = (PdAudioUnit *)inRefCon;
    Float32 *auBuffer = (Float32 *)ioData->mBuffers[0].mData;

    if (pdAudioUnit->inputEnabled_) {
        AudioUnitRender(pdAudioUnit->audioUnit_, ioActionFlags, inTimeStamp, kInputElement, inNumberFrames, ioData);
    }

    int ticks = inNumberFrames >> pdAudioUnit->blockSizeAsLog_; // this is a faster way of computing (inNumberFrames / blockSize)
    [PdBase processFloatWithInputBuffer:auBuffer outputBuffer:auBuffer ticks:ticks];
    return noErr;
}

PdAudioUnit passes the same audio buffer, auBuffer, to PD for input and output. When input is enabled, this audio buffer contains input samples rendered directly from the input hardware. In the event that no output signal processing is done in PD (i.e. no active signal path to a dac~ object), the output audio buffer will be left unaffected resulting in input samples being mapped directly to output samples. This causes the input buffers to be heard via the output hardware and can lead to acoustic feedback.

A simple way to reproduce this is to run a patch containing just one adc~ object, with no other objects or connections, on iOS. You will hear captured mic audio being passed through directly to the speaker. Give it enough amplitude and you'll get feedback.

I'm not sure of the best solution here. I believe we need two distinct buffers for input and output, which would require pre-allocating an additional buffer to hold input samples during setup. A ring buffer would be robust to potential system changes to buffer durations.

This seems like quite a large change though so I initially wanted to get other people's opinions on this issue? For now I'm just using a little hack/workaround by adding a dac~ with zero amplitude in my input analysis patches.

Error while building on windows

Hello,

I'm trying to build libpd on Windows using mingw and the mingw_build.bat. Everything seems to be going fine until it tries to build the x_misc.c file.

Here is the error I get :

libpd_wrapper/util -DWINVER=0x502 -DWIN32 -D_WIN32 -DPD_INTERNAL -O3 -I"/include
" -I"/include/win32" -c -o pure-data/src/x_misc.o pure-data/src/x_misc.c
In file included from c:\mingw\include\objbase.h:95:0,
from c:\mingw\include\ole2.h:31,
from c:\mingw\include\windows.h:101,
from c:\mingw\include\rpc.h:27,
from c:\mingw\include\wtypes.h:29,
from pure-data/src/x_misc.c:13:
c:\mingw\include\objidl.h:69:2: error: unknown type name 'LPOLESTR'
LPOLESTR pwcsName;
^
c:\mingw\include\objidl.h:113:1: error: unknown type name 'OLECHAR'
typedef OLECHAR *SNB;
^
c:\mingw\include\objidl.h:259:2: error: unknown type name 'OLECHAR'
OLECHAR rgString[1];
^
c:\mingw\include\objidl.h:302:2: error: unknown type name 'CY'
CY *pElems;
^
c:\mingw\include\objidl.h:306:2: error: unknown type name 'DATE'
DATE *pElems;
^
c:\mingw\include\objidl.h:310:2: error: unknown type name 'BSTR'
BSTR *pElems;
^
c:\mingw\include\objidl.h:314:2: error: unknown type name 'BSTRBLOB'
BSTRBLOB *pElems;
^
c:\mingw\include\objidl.h:318:2: error: unknown type name 'VARIANT_BOOL'
VARIANT_BOOL *pElems;
^
c:\mingw\include\objidl.h:322:2: error: unknown type name 'SCODE'
SCODE *pElems;
^
c:\mingw\include\objidl.h:346:2: error: unknown type name 'CLIPDATA'
CLIPDATA *pElems;
^
c:\mingw\include\objidl.h:358:2: error: unknown type name 'VARTYPE'
VARTYPE vt;
^
c:\mingw\include\objidl.h:367:3: error: unknown type name 'VARIANT_BOOL'
VARIANT_BOOL boolVal;
^
c:\mingw\include\objidl.h:376:3: error: unknown type name 'SCODE'
SCODE scode;
^
c:\mingw\include\objidl.h:380:3: error: unknown type name 'CY'
CY cyVal;
^
c:\mingw\include\objidl.h:381:3: error: unknown type name 'DATE'
DATE date;
^
c:\mingw\include\objidl.h:384:3: error: unknown type name 'BLOB'
BLOB blob;
^
c:\mingw\include\objidl.h:385:3: error: unknown type name 'CLIPDATA'
CLIPDATA *pclipdata;
^
c:\mingw\include\objidl.h:388:3: error: unknown type name 'BSTR'
BSTR bstrVal;
^
c:\mingw\include\objidl.h:389:3: error: unknown type name 'BSTRBLOB'
BSTRBLOB bstrblobVal;
^
c:\mingw\include\objidl.h:419:3: error: unknown type name 'LPOLESTR'
LPOLESTR lpwstr;
^
c:\mingw\include\objidl.h:423:2: error: unknown type name 'LPOLESTR'
LPOLESTR lpwstrName;
^
c:\mingw\include\objidl.h:425:2: error: unknown type name 'VARTYPE'
VARTYPE vt;
^
c:\mingw\include\objidl.h:433:2: error: unknown type name 'OLECHAR'
OLECHAR
pwcsElementName;
^
c:\mingw\include\objidl.h:440:5: error: unknown type name 'OLECHAR'
OLECHAR *pPrincipalName;

[...]

In file included from pure-data/src/x_misc.c:13:0:
c:\mingw\include\wtypes.h:110:18: error: 'BSTR' redeclared as different kind of
symbol
typedef OLECHAR BSTR;
^
In file included from c:\mingw\include\rpcdce.h:33:0,
from c:\mingw\include\rpc.h:65,
from c:\mingw\include\windows.h:82,
from c:\mingw\include\rpc.h:27,
from c:\mingw\include\wtypes.h:29,
from pure-data/src/x_misc.c:13:
c:\mingw\include\oleauto.h:231:1: note: previous declaration of 'BSTR' was here
WINOLEAUTAPI
(BSTR) SysAllocStringByteLen(const char_,unsigned int);
^
make: *** [pure-data/src/x_misc.o] Error 1

Achieve better timing for MIDI events?

Recently I've been working on a sequenced synth iOS app and ran into a problem.
What I have is basically a polyphonic synth Pd patch that is receiving MIDI notes. The notes are being sequenced outside of Pd and sent via +[PdBase sendNoteOn:pitch:velocity:].
The problem I experienced was inconsistent timing of those notes. E.g. a succession of 10 or so notes of the same duration, then some shorter ones and so on. After checking that the timer is OK, I though that this may be somehow related to the buffer size (I was using 16 ticks per buffer). I tried simplifying the patch so the device would be able to run it at 1 or 2 ticks per buffer, and the timing became a lot better. Running the same simplified patch at 16 ticks per buffer was again leading to very noticeable timing inconsistency.
So it seems to me like libpd is not able to receive any events while it's doing DSP processing, and therefore notes will be fired only at integer multiples of buffer size. Is this correct? If so, can there be a workaround?

Thanks!

Segfault scenario.

Hello.
I'm using libpd here: https://github.com/rvega/XookyNabox.
When I load this patch:

N canvas 278 223 857 419 10;

X obj 154 36 loadbang;

X obj 154 322 dac~;

X obj 154 77 random 10;

X obj 154 96 * 200;

X obj 154 116 + 200;

X obj 154 160 phasor~;

X obj 154 57 metro 2000;

X obj 155 283 *~;

X obj 155 249 vcf~ 2;

X obj 181 214 *~ 2;

X obj 181 192 sig~;

X obj 154 136 t f f;

X obj 228 227 osc~ 0.5;

X obj 229 286 *~;

X obj 229 250 clip~ 0 1;

X msg 254 188 0.75;

X connect 0 0 6 0;

X connect 2 0 3 0;

X connect 3 0 4 0;

X connect 4 0 11 0;

X connect 5 0 8 0;

X connect 6 0 2 0;

X connect 7 0 1 0;

X connect 7 0 1 1;

X connect 8 0 7 0;

X connect 9 0 8 1;

X connect 10 0 9 0;

X connect 11 0 5 0;

X connect 11 1 10 0;

X connect 11 1 15 0;

X connect 12 0 14 0;

X connect 13 0 7 1;

X connect 14 0 13 0;

X connect 14 0 13 1;

X connect 15 0 12 1;

I get a segfault:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
[Switching to process 4771 thread 0x1f03]
0x0000000000000000 in ?? ()
(gdb) backtrace
#0 0x0000000000000000 in ?? ()
#1 0x000000010005e89e in outlet_float (x=0x1002289a0, f=8.83757463e-39) at m_obj.c:385
#2 0x0000000100057711 in binbuf_eval (x=0x1002289a0, target=0x100228bb0, argc=6306896, argv=0x100603c50) at m_binbuf.c:725
#3 0x00000001000491f0 in message_float (x=0x1002289a0, f=0) at g_text.c:353
#4 0x000000010005e89e in outlet_float (x=0x1002289a0, f=8.83793336e-39) at m_obj.c:385
#5 0x000000010006ed85 in trigger_list (x=0x1002289a0, s=0x100228bb0, argc=1, argv=0x100603ce0) at x_connective.c:988
#6 0x000000010006ee94 in trigger_float (x=0x1002289a0, f=0) at x_connective.c:1034
#7 0x000000010005e89e in outlet_float (x=0x1002289a0, f=8.83811273e-39) at m_obj.c:385
#8 0x000000010005e89e in outlet_float (x=0x1002289a0, f=8.83815757e-39) at m_obj.c:385
#9 0x000000010005e89e in outlet_float (x=0x1002289a0, f=8.83820241e-39) at m_obj.c:385
#10 0x000000010005ea99 in outlet_bang (x=0x1002289a0) at m_obj.c:359
#11 0x0000000100077cbc in metro_tick (x=Cannot access memory at address 0x0

) at x_time.c:87
#12 0x000000010006004d in sched_tick (next_sys_time=2.1251120013319739e-314) at m_sched.c:372
#13 0x0000000100079459 in libpd_process_float (inBuffer=0x1002289a0, outBuffer=0x100228bb0) at z_libpd.c:143
#14 0x0000000100001a2e in process (nframes=256, arg=0x0) at main.cpp:206
#15 0x00000001000f83bc in Jack::JackClient::Execute ()
#16 0x00000001001057ee in Jack::JackPosixThread::ThreadHandler ()
#17 0x00007fff8fda58bf in _pthread_start ()
#18 0x00007fff8fda8b75 in thread_start ()

Other patches seem to work okay except for patches that use line and line~.

This is just in case this scenario is usefull for you guys since I'm just playing around.

iOS PdBase evaluateFloatMessage crash

This bug only happens on the device, reproducable on an iPhone 4s running iOS 5.0.

Steps using PdSettings example project:

  • add the following delegate method to PdSettingsViewController (it is already set as the PdReceiverDelegate):
  • (void)receiveFloat:(float)received fromSource:(NSString *)source {
    }
  • start the app on device, you'll get an EXC_BAD_ACCESS in the evaluateFloatMessage() function when trying to access p->x

Strange enough, memcpy'ing the float first works fine. To make the bug disappear in a most incorrect way, replace the existing evaluateFloatMessage() function with:

static void evaluateFloatMessage(params *p, void **buffer) {
  if ([delegate respondsToSelector:@selector(receiveFloat:fromSource:)]) {
    NSString *src = [[NSString alloc] initWithCString:p->src encoding:NSASCIIStringEncoding];
    float f;
    memcpy(&f, &p->x, sizeof(float));
    [delegate receiveFloat:f fromSource:src];
    [src release];
  }
}

How to build libpd with visual studio?

I've started researching how to do this and it appears others (@bgbotond) have had success, indicated by this repo: https://github.com/bgbotond/libpd

Though I can't see what changes were required from any diffs. Can anyone point me in a good direction?

I'm pretty sure it is something to do with HAVE_UNISTD_H needing to not be defined, but I don't know the details.

Question about versions of libpd, pure-data and pd-extended and the t_blob type.

Hi.

I'm trying to use the [hoa.map~] external from https://github.com/CICM/HoaLibrary with libpd. In cicm's code, they use the t_blob type which I can see is defined in pd-extended's m_pd.h file and not in libpd's m_pd.h.

I'm using libpd on branch pd_045-4 and reading pd-extended code from http://sourceforge.net/p/pure-data/pd-extended/ci/master/tree/, which has a version number of 0.44.0. As far as I understand these are both the latest versions of pd-extended and libpd. What's with the version number differences? what's the logic for the numbering?

Since libpd's version number is higher, am I correct in assuming that the t_blob type has been deliberately removed? If so, what should be used instead?

Debian package

i'd be willing to package libpd for Debian (and derivatives like Ubuntu), but would like to ask first whether this makes actual sense.

  • are there releases?
    • at least the git repository does not have any (release) tags at all.
  • how stable is the API?
    • what are the "public" headers of libpd? z_libpd.h & util/z_hook_util.h or is there (planned to have) a libpd.h header?
    • judging from issue #44, i figure that there might still be some fundamental changes to the API (i don't know how fundamental the proper functioning of these hooks are in "real world")
    • since i only had a look at the low-level C-style API, how stable is the API for binding foo?
  • how stable is the ABI?
    • for a Debian package i would package an ordinary shared system library (libpd.so.1).
    • it seems that as of now, this is not the most common use-case of libpd. instead it seems that whoever uses libpd, just drops a static copy into their project, rather than using a shared library. this might make sense on restrictive platforms like iOS, though it's probably bad practice.
    • judging from a quick glance at the top-level Makefile, it seems that the build-system is totally ignorant of consistent versioning via soname. is this by intention?
  • how do you test for regressions?
  • upstream
    • how closely does libpd follow development of puredata? the current 'master' branch is still Pd-0.43-3 whereas Pd-vanilla currently has 0.45-4. i'm mainly asking because i think that libpd and puredata should be able to share the same set of externals (dlopen() is supported on Debian), which might become problematic if the versions diverge too much.

please do not get me wrong (some questions might sound a bit rude), i'm mainly asking to figure out whether it makes sense to create Debian packages

  • is this something that some/many users would like to have
  • is it feasible to maintain such a package on the long run

PdDispatcher dealloc bug

I think there's a bug at line 26 of PdDispatcher.m:
the fast enumeration of a NSDictionary returns the keys (NSString) , not the values (NSValue) ... sending a pointerValue message to a string will make the app crash.

see
morellid@f4fd204
for a fix

Error with python3

Got an error in s_file.c:142

error: format not a string literal and no format arguments [-Werror=format-security]

FIxed it by changing how pd_error is called.

diff --git a/pure-data/src/s_file.c b/pure-data/src/s_file.c
index c5a4f76..a7ba8ea 100644
--- a/pure-data/src/s_file.c
+++ b/pure-data/src/s_file.c
@@ -139,7 +139,7 @@ static void sys_initsavepreferences( void)
     if ((sys_prefsavefp = fopen(filenamebuf, "w")) == NULL)
     {
         snprintf(errbuf, MAXPDSTRING, "%s: %s",filenamebuf, strerror(errno));
-        pd_error(0, errbuf);
+        pd_error(0, "%s", errbuf);
     }
 }

Libpd master, python3..3 (3.3.3-3 amd64) Debian Jessie

legacy BSD math functions deprecated on iOS6

The following math functions in libpd are deprecated on iOS6:

  • finite -> use isfinite instead
  • drem -> use remainder

It seems like the pd core dosen't use these, but expr~ does vexp_fun.c. Of course I see the GPL header there so I can't use it anyway, but maybe not a bad idea to update it since it should build fine anyway.

build issue on Ubuntu 12.04

Using the latest version of libpd, ofxPd dosen't build on Ubuntu 12.04 due to a

storage size of 'statbuf' isn't known

in pure-data/src/s_file.c, line 51

libpd itself builds fine and the c test works, so I can't tell yet if it's something to do with the openframeworks makefile / build settings or an issue with compiling libpd with a C++ compiler. It works fine on Win with miniGW and OSX.

[Discussion] should we add a ringbuffer to send messages from the host code to libpd?

Hi, I was testing the code discussed in
9c21f62 and I noticed that sending a large amount of messages from the host code to libpd, with PdBase::sendFloat, for example, causes audio buffer underruns.
This is because there is no ringbuffer in place for host to libpd communication and locks are used.

Is it worth the hassle to implement ringbuffer communication for this use-case? I can take a stab at it but I can move to more useful tasks if someone else´s experience shows this is not really needed for musical apps.

My use case is to create GUIs in QT for PD patches running in libpd in the same QT app.

Cheers!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.