Sorry to necro this thread, but I finally found out how to run PureData under Pulseaudio (which otherwise results with "ALSA output error (snd_pcm_open): Device or resource busy").

First of all, run:

pd -alsa -listdev

PD will start, and in the message window you'll see:

audio input devices:
1. HDA Intel PCH (hardware)
2. HDA Intel PCH (plug-in)
audio output devices:
1. HDA Intel PCH (hardware)
2. HDA Intel PCH (plug-in)
API number 1

no midi input devices found
no midi output devices found

... or something similar.

Now, let's add the pulse ALSA device, and run -listdev again:

pd -alsa -alsaadd pulse -listdev

The output is now:

audio input devices:
1. HDA Intel PCH (hardware)
2. HDA Intel PCH (plug-in)
3. pulse
audio output devices:
1. HDA Intel PCH (hardware)
2. HDA Intel PCH (plug-in)
3. pulse
API number 1

no midi input devices found
no midi output devices found

Notice, how from the original two ALSA devices, now we got three - where the third one is pulse!

Now, the only thing we want to do, is that at startup (so, via the command line), we set pd to run in ALSA mode, we add the pulse ALSA device, and then we choose the third (3) device (which is to say, pulse) as the audio output device - and the command line argument for that in pd is -audiooutdev:

pd -alsa -alsaadd pulse -audiooutdev 3 ~/Desktop/mypatch.pd

Yup, now when you enable DSP, the patch mypatch.pd should play through Pulseaudio, which means it will play (and mix) with other applications that may be playing sound at the time! You can confirm that the correct output device has been selected from the command line, if you open Media/Audio Settings... once pd starts:

As the screenshot shows, now "Output device 1" is set to "pulse", which is what we needed.

Hope this helps someone!

EDIT: I had also done changes to /etc/pulse/default.pa as per https://wiki.archlinux.org/index.php/PulseAudio#ALSA.2Fdmix_without_grabbing_hardware_device beforehand, not sure whether that makes a difference or not (in any case, trying to add dmix as a PD device and playing through it, doesn't work on my Ubuntu 14.04)

Dear PD community
I am happy to announce the beta release of Context, a powerful new sequencer for PD. Context is a modular sequencer that re-imagines musical compositions as a networks. It combines traditional step sequencing and timeline playback with non-linear and algorithmic paradigms, all in a small but advanced GUI.

Unlike most other sequencing software, Context is not an environment. It is a single abstraction which may be replicated and interconnected to create an environment in the form of a network. There are literally endless possibilities in creating Context networks, and the user has a great deal of control over how their composition will function.

From a technical perspective, Context features a lot of things that you don't often see in PD, such as click + drag canvas resizing, dynamic menus, embeddable timelines, and fully automatic state saving. It also boasts its own language, parsed entirely within PD.

Context is work in progress--there are still lots of bugs in the software and lots of holes in the documentation. However, I have gotten it to a place where I feel it is coherent enough for others to use it, and where it would benefit from wider feedback. I am especially looking for people who can help me with proof reading and bug tracking. Please let me know if you want to join the team! Even if you can't commit to much, pointing out typos or bits of the documentation that are confusing will be very helpful to me.

Some notes on the documentation: I have been putting 90% of my efforts recently into writing the manual, and only 9% into writing the .pd help files (the remaining 1% being sleep). The help files are pretty, but the information in them is not very useful. This will be corrected as soon as I have more time and better perspective. In the mean time, please don't be put off by the confusing help files, and treat the manual as the main resource.

Context is available now at https://github.com/LGoodacre/context-sequencer.

A few other links:

• The debut performance of Context at PDCon16~:

• An explanation of this performance: http://newblankets.org/liam_context/context-patch.webm

• A small demo video:

• My paper from PDCon16~: https://contextsequencer.files.wordpress.com/2016/11/goodacre-context.pdf

Finally, I should say that this project has been my blood sweat and tears for the past 18 months, and it would mean a great deal to me to see other people using it. Please share your patches with me! And also share your questions--I will always be happy to respond.

Context only works on PD Vanilla 0.47, and it needs the following externals:

zexy
cyclone
moocow
flatgui
list-abs
iemguts (v 0.2.1 or later)

Hopefully one day it will work on L2Ork and Purr Data, but not yet.

I would like to thank the PD community for their support and inspiration, in particular Joe Deken and the organizers of PDCon16.

@Pierre-Guillot said:

You still don't use the realloc method properly. The method is for reallocation, so you should give it the pointer to the memory you want to resize.
In your code, you allocate new memory each time you resize the arrays without releasing them thus you have a lot of memory leaks.

Sorry, I can't see my error. I think, lines 116-119 do free the allocated memory:

if (x->matrix) free(x->matrix);
    if (x->vector) free(x->vector);
    x->vector = temp_vector;
    x->matrix = temp_matrix;

VS shows me the process memory. When I do produce memory leaks, the process memory should raise, I guess. But with my code it corresponds to the size of the matrix. So lowering the sample length lowers the memory also.

With the first, x->vector should be set to NULL, this way the method will acts like malloc.

OK. I added x->matrix = NULL; x->vector = NULL; to the method average_init_arrays

My updated code is here:
https://github.com/XRoemer/puredata/blob/master/average%7E/C/r_average%7E2.h
(I also changed the method average_resize_arrays from:

void average_resize_arrays(t_average_tilde *x, t_floatarg f) {

    x->row = 0;
    x->len_avg = f;

    average_resize_avg(x, f);
    average_resize_matrix(x, f);

    if (!x->avg && !x->matrix) {
        x->matrix = NULL;
        pd_error(x, "allocation failed");
    }
}

to:

void average_resize_arrays(t_average_tilde *x, t_floatarg f) {

    x->row = 0;
    x->len_avg = f;

    average_resize_avg(x, f);
    average_resize_matrix(x, f);

    if (!x->avg || !x->matrix) {
        if (x->matrix) free(x->matrix);
        if (x->vector) free(x->vector);
        x->matrix = NULL;
        x->vector = NULL;
        pd_error(x, "allocation failed");
    }
}

Do I really have to free the colums before reallocating the rows?

Normally, but a good practice in C is:
Allocation:

t_sample ** matrix = (t_sample**)getbytes(nrows * sizeof(t_sample *));
if(matrix)
{
    t_sample * vector = (t_sample*)getbytes(nrows * ncols * sizeof(t_sample));
    if(vector)
    {
       for(int i = 0; i <  nrows; ++i)
       {
          matrix[i] = vector+i*ncols;
       }
    }
    else
    {
        freebytes(matrix, nrows * sizeof(t_sample *));
        matrix = NULL;
        pd_error(x, "allocation failed");
    }
}
else
{
    vector = NULL;
    pd_error(x, "allocation failed");
}

Release:

if(matrix)
freebytes(matrix, nrows * sizeof(t_sample *));
matrix = NULL;
if(vector)
freebytes(vector, nrows * ncols * sizeof(t_sample));
vector = NULL;

Reallocation:

temp_matrix = resizebytes(matrix, nrows * sizeof(t_sample *), new_nrows * sizeof(t_sample *));
if(temp_matrix)
{
        temp_vector = resizebytes(vector, nrows * ncols * sizeof(t_sample *), new_ncols * new_nrows * sizeof(t_sample));
        if(temp_vector)
        {
            vector = temp_vector;
            matrix = temp_matrix;
            nrows = new_nrows;
            ncols = new_ncols;
            for(int i = 0; i < nrows; ++i)
            {
                matrix[i] = vector+i*ncols;
            }
        }
        else
        {
            freebytes(temp_matrix, new_nrows * sizeof(t_sample *));
            freebytes(vector, nrows * ncols * sizeof(t_sample));
            vector = NULL;
            matrix = NULL;
            pd_error(x, "allocation failed");
        }
 }
else
{
    freebytes(matrix, nrows * sizeof(t_sample *));
    freebytes(vector, nrows * ncols * sizeof(t_sample));
    vector = NULL;
    matrix = NULL;
    pd_error(x, "allocation failed");
}

@francis666 Hello Francis.......
Have you looked at [mux~-help] or [multiplex~-help] ?
If you right click on the [mux~] object and select help then it will open the help file (like most objects in Pd).
Personally I prefer [matrix~] ..... (It will not create without arguments though!............)
[matrix~ 10 10 1 100] gives you 10 ins and 10 outs fading over 100ms (which avoids clicks when you switch between inputs). You have to give it a slightly more complicated message, but that is well worth the extra work!
For [matrix~]
A message ....... [0 3 1] would connect input 1 to output 4 at full. (inputs and outputs are always numbered starting at 0 in Pd).
A message ....... [0 3 0.5] would do the same at 50%.
A message ...... [0 3 0] would connect them at 0 (i.e. disconnect)
[matrix~ 1 4 1 500] will give you 1 input and 4 outputs with a fade time of 500ms.........
David.

This is a collection of abstractions that generate bandlimited oscillators. They include:

[bl-saw.mmb~] - bandlimited sawtooth waveform
[bl-pulse.mmb~] - bandlimited pulse wave with PWM
[bl-tri.mmb~] - bandlimited triangle wave
[bl-asymtri.mmb~] - bandlimited asymmetrical triangle wave (sort of...see below)

There is also an object called [bl-init.mmb]. This is the object that initializes all the waveforms and at least one instance MUST be included in order for the others to work.

There are also help patches included.

IMPORTANT!
Before you can use these, you must do the following steps.

1. Open [bl-init.mmb]
2. There is a message box that says [44100(. This is the maximum sampling rate that these will work at (running at lower sampling rates will be fine). If you plan on using higher sampling rates, change this message box and click it. Technically, it will still work at a higher sampling rate, but it won't generate harmonics above the sampling rate in this box.
3. Click the [bang( to fill the wave tables. This patch actually creates a wavetable for EVERY harmonic between 30Hz and the Nyquist frequency. So it will take a few minutes. Be patient! You will get a message in the Pd window when it is done.
4. Save the patch.

Once you do this, [bl-init.mmb] will simply load with the tables already generated, so you don't have to wait every time you instantiate it. I didn't have this already done for you in order to keep the upload small, and so you can see how to adjust it if you need to.

So, I guess I'll go ahead and try to explain how these work. As stated above, every harmonic is generated in [bl-init.mmb] for the oscillators. It doesn't create a table for each set of harmonics however (e.g., there isn't a saw table with two harmonics, a saw table with three harmonics, etc.). Instead, each of these individual tables are tacked on to the end of each other to create one long wave table. So, for each set of 1027 samples in the sawtooth wavetable, there is one cycle with a set amount of harmonics.

When the oscillators read the frequency input, it is divided into the Nyquist frequency to determine how many harmonics are needed. It then uses this (* 1027) as the offset for the table. This is how I got around the problem of table switching at block boundaries. By doing this way, the "switching" is done at audio rate.

There are actually two [tabread4~]s. One has one less harmonic than the other. As the frequency changes it crossfades between these tables. When one table goes completely silent, that's when it "switches." Below 30Hz, they switch to geometrically perfect waveforms.

[bl-saw.mmb~] and [bl-tri.mmb~] just read through the tables. Nothing really interesting about them.

[bl-pulse.mmb~] is actually the difference between to sawtooths. In other words, there are two bandlimited sawtooth oscillators inside of it. Adjusting the pulse width cause the phase of one of the sawtooths to shift. When you subtract this phase-shifted sawtooth from the other, it creates a bandlimited pulse wave...without oversampling! This is the same Phase Offset Modulation method used in Reason's SubTractor.

[bl-asymtri.mmb~] uses the same technique as [bl-pulse.mmb~], except it uses bandlimited parabola waves instead of sawtooths. Adjust the phase offset sets where the top vertex is. This doesn't really generate true triangle or saw waves, though. They still have the parabolic curve in them, so the harmonics seem to come out a little more. It's more of a "reasonable approximation." But, it is bandlimited, and it does sound pretty cool to modulate the shape. I don't have the scaling quite right yet, but I'll get to it later...maybe.

I should also mention that these use my [vphasor.mmb~] abstraction, so the phase reset is sample accurate.

I'll eventually set these up to allow frequency and pulse-width arguments, but I'm currently in the process of moving to another country, so it may be a little bit before I get around to it.

Didn't any of that make any sense?

http://www.pdpatchrepo.info/hurleur/bl-mmb.zip

I successfully compiled the pdj lib
placed the whole dir in the /usr/lib/pd/extra dir
set a path to it in pd-extended
tried to open a help file for the 'help class' and got
a red outline around the [pdj help class] external
and this error in the console:

pdj help_class
... couldn't create
pdj: unable to use the JVM specified at pdj.JAVA_HOME
pdj: using JVM from the LD_LIBRARY_PATH
error: pdj: libjava.so: cannot open shared object file: No such file or directory
pdj help_class @attr1 10
... couldn't create
tried text-help.pd and failed
tried /usr/lib/pd/doc/5.reference/text-help.pd and succeeded

I'm reading through the 'pdj.properties' file but not sure of what to modify

any help is appreciated!
??

===================

my Linux audio config:
Dell Studio 15 Core2 Duo 2.0GHz 3G-RAM
Ubuntu 9.04
kernel 2.6.28.18-generic

I had this idea while driving to work...

Imagine if the dsp side of pd was multidemensional. If every tilde~ object's first two arguments described a matrix of objects, [osc~ x y] would be (x*y) sin oscillators, each with a unique ID (0-0, 0-1, 0-2, 1-0, 1-1, etc...). The entire matrix could be addressed with a control matrix, or a message/list of (x*y) components. Each matrixed object could be individually called or controlled by a specific message depending on it's location in the grid. Each matrix~ objects would have to have some sort of multiplexed or mixed i/o, as well as individual ins and outs.

A central object would be a matrix mixer, both 1d(x=1) and 2d. I feel that this kind of dataflow would help to easily bridge the gap between generative audio and video, as well as standard(16*n) sequencing; both of which work with matrices.

A quick hack could be accomplished with Pd's shaky-at-best dynamic object allocation, but the real answer is something I am incapable of creating at this time. Maybe the answer lies in another language?

hi, it's not too difficult. You are right, there is no help for Pd but only for MAX/MSP.
Anyway, it is not too difficult to figure out the meaning of the inlets from the howto.txt file provided together with
the .dll and I produced a small help file (attached to this post) for pd.
To use, for example, the atari_2600~.dll from the mmonoplayer site:

1. place the attached file (help_atari_2600~.pd) in the same folder where you placed the atari_2600~.dll
2. open the help_atari_2600~.pd patch and everything should work fine (just play with the numbers and the volume)

Hope that helps...

AlbertoZ

http://www.pdpatchrepo.info/hurleur/help_atari_2600~.pd

Hi Hardoff,

[mtx] works, i can print out the matrix message. [matrix~] doesn't, I can't control the coefficients. The helpfile für [matrix~] sucks.

For example, if I have a [matrix~ 2 2] object i'd expect a message like [1 0 0 1] but in most cases the matrix doesn't do anything.

Ok, to make it more precise. What I want to do is to play multiple VBAP-panned sources on a 16-speaker array. At the moment i work with [*~] and [throw~ ch01] [throw~ ch02]... for each source. This seems to be not very smart and my system goes down with more than 3 sources. I hope to implement VBAP for at least 8 sources.

So I'm looking for a way to process the signals more efficiently, theat means that only those channels are calculated which are really used (max. 3 channels per source , without Spreading). I thought [matrix~] to be a better way than [throw~]&[catch~].

Maybe there's another, better solution?

Bastian