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)

Many thanks for the prompt answer, @LiamG:

@LiamG said:

It seems to me that you are confusing the difference between a subpatch and an abstraction.

Indeed I was - many thanks for the great explanation, it was exactly what I needed!

An abstraction is a unique object that can take creation arguments. You have done the right thing by saving it as a pd file "mysubpatch.pd" in the same directory, but to initiate it you just need to create the object [mysubpatch]. If you create [pd mysubpatch.pd], as you have reported above, then you will get a subpatch, which is not the same thing.

I cannot believe I had forgotten this, even if just last year I was doing patches with abstractions :) Great to have this as reference, for the next time it happens :)

Anyways - indeed, it works great - once the (sub)patch is loaded as an abstraction proper, then the patch "sleeps" (as in, no reported warnings), even with DSP on and two abstractions (and even the window title bar tells you that the abstraction now sees argument (A)):

Great to have this solved - thanks again, cheers!

Consider the following trivial patch (testing on Pd 0.45.4 on Ubuntu 14.04):

In it, I have a [pd mysubpatch A]. As far as I remember, the A is now an argument of/to the subpatch, in particular it is the first argument - and references to $1 inside the subpatch should expand to A.

So, I've decided to place an array inside the subpatch, and call it $1-array, similar to how in abstractions, arrays are/can be called $0-array - except there the $0 doesn't expand to any arguments, but instead expands to a random number (Dollar signs in objects and messages | PURE DATA forum~). My expectation is that the $1 in my case would expand to the first argument, A, and thus the array name at instantiation time of the object [pd mysubpatch A] would expand to A-array.

The idea is thus to be able to put multiple subpatches in a patch, and control their internal arrays' names by supplying unique arguments. So, I try to copy/duplicate the [pd mysubpatch A] into a [pd mysubpatch B], expecting its array would ultimately be called B-array. So far so good, because I can do this without any problems.

Now consider a slightly more complicated case where I also have a tabwrite~ in the subpatch:

Now that I have [tabwrite~ $1-array] referencing the $1-array in the subpatch, as soon as I turn on DSP/audio, I get a ton of warning: $1-array: multiply defined messages. As I don't get this message when I have only the $1-array in the subpatch, I'm assuming it is not the logic in naming the arrays $1-array via subpatch arguments that is the problem, but instead it is the reference in the [tabwrite~ $1-array] which is causing the warning message.

Note that exactly the same happens, if I save the subpatch as an abstraction mysubpatch.pd, and use it as two objects [pd mysubpatch.pd A] and [pd mysubpatch.pd B]:

But then, in this case, how would I reference such a subpatch/abstraction array, named through an argument, from inside the subpatch/abstraction itself? Note that I need fixed, explicit, known names of arrays, so a workaround like $0-$1-array wouldn't work for me, since the $0 would expand to a random number, which I in principle do not know from the outside (and I'm not sure $0 even applies to subpatches).

@gsagostinho Thanks for the report, - btw my video is taken on Ubuntu Linux 11.04, not Windows So this is definitely something to do with Linux - my guess is, I think in most Linuces, it is X Windows which is the main arbiter of GUI events to user-space programs, so this probably has to do with the interaction of X Windows and Pure Data. (I seem to recall that X Windows, if it cannot deliver a GUI event in time, it queues it for later; and thus at a certain point, I have two events - the current one; and the previous one that was late, so requeued for the current time - reporting in a quick succession - but I am not 100% sure about this). In any case, if this is the root cause of the issue, I guess there is not much Pure Data can do about it... (apart from tricks like thresholding). But hopefully someone will come up with a more accurate understanding of the problem - and even a possible solution Cheers!

@LandonPD Many thanks for reporting - it seems now confirmed that this behavior does not occur under Windows. Would be nice to hear a report from a Linux user, or a Mac user as well (although I suspect Mac should work fine too).

(Actually, a possible workaround for this in PD would be simply to set a threshold, something like 0.5 ms (= 500 μs); if [timer]/[realtime] measures delta t any less than this, we simply refuse to bang the expr for velocity calculation; the timer keeps on measuring, and next time a slider event is received, we should have the most current value at the time, and definitely a delta t > 0 - which should provide a more accurate velocity measure, than if the short measurements are included. But I do not have the time ATM to develop a test for this; I hope to get back to this once I do).

Cheers!

Thanks to [PD-dev] [ pure-data-Patches-3380575 ] [makefilename] patch reliably segfaults and Symbol to float conversion | PURE DATA forum~, I found that [makefilename] actually supports C-style printf format specifier (but only one of them per object!), so that can actually be used for the purpose - for example like in this patch, formatspec.pd:

The format specifier %.4g reduces the number of decimals - and it will even print out a plain integer '5' in case of 5.000000 ; but careful, g will also kick in with scientific notation for very small numbers, so for 0.0000345345234 you'd get '3.45345e-05'; alternatively, try %.3f.

@gsagostinho, @xbarbie - many thanks for the comments!

that a line object, for instance, makes the output be constant.

That is not the issue here; to clarify better, I made a new patch, test_slider2.pd:

And to show what I get on my system, I made a video capture:

test_slider2.ogv

Notice how I drag the mouse slowly, and the other fader generally follows - but then suddenly, it jumps? That is because of the very small times occasionally provided by [realtime] - which would be the zeros if [timer] is used. So it cannot be "that any fluctuation is due to your control of the mouse, how fast you click and drag".

I don't know what causes problem on your system, because on my (Pd-extended on Win7 x64) it's working OK: ...
IMHO the question was, why he got those zero times, which I could not reproduce.

Thanks for this - this helps narrow down the issue; would you mind running test_slider2.pd and reporting if you get the jumps like I do in the video?

Now I think probably the problem is in the behavior of X windows event queuing (at least the version on my old Ubuntu 11.04), and possibly the way it interacts with pd-extended-0.43.4; would be nice to read reports of the behavior on newer Linuces too, if the "jumpiness" occurs there too.

Thanks all for the discussion - cheers!

Thanks for the comments, @LandonPD , @gsagostinho - indeed, if I cross the wires:

... I do get a string of zeroes:

...
print: 0 0.291457
print: 0 0.286432
print: 0 0.281407
print: 0 0.271357
print: 0 0.266332
...

... but I'm afraid there has been a misunderstanding: that is not the correct result: the correct result is not to have any zeroes at all! (and so, the wiring in the OP should be correct: first you output the current measurement, then you reset the timer - so by next time it is banged, it would have measured some elapsed time). What I want to do it, as @gsagostinho put it, "actually measuring the time it takes you to drag between numbers".

Say at time t1, the slider is at value v1. Say I move the slider, and after time Δt - at time t2 - the slider is at value v2. Then, I could calculate relative velocity of value change as

(v2-v1)/(t2-t1) = (v2-v1)/Δt

But, if Δt is zero - then I'd get "division by zero" error (theoretically, infinity for the value change velocity - which is impossible, since I have moved the slider only by a finite amount in finite time).

This means, that whenever I get a zero as time elapsed between two GUI events, the measurement has been inaccurate/unreliable. A reliable measurement would give always a time difference > 0 for two different values. In fact, [realtime] shows that in the original example, the zeroes are result of truncating 0.00XX float type of values, so the system does in fact register that Δt is not really 0 - however, as I mentioned in the OP, that isn't really all that accurate either (if you use [realtime] to derive slider value change velocity, it will still be jumpy, even if you drag the slider with as even speed as you can). What I wanted to know is, if there is a better way of obtaining the timing between slider events - in the sense that the calculated value change velocity would accurately describe the actual slider movement.

As @seb-harmonik.ar pointed out, this is likely due to message queuing - and as far as I can see, there is no way of getting rid of that artifact (at least not in PD vanilla) - unless someone knows a better way...

Cheers!

@seb-harmonik.ar thanks for that; I am unaware of the Pure Data internals - such as whether the GUI runs in a separate process - so it's great to have this noted down; cheers!

Thought I might as well repost this here: Measuring the elapsed time for GUI (hsl slider) object events in Puredata? - Stack Overflow:

Consider this patch (code below, tested on pd-extended_0.43.4-1, Ubuntu 11.04):

I basically just drag the slider about, and want to see what is the time difference between two consecutive values emitted by the [hsl] slider. The [trigger] help (Triggering_messages_with_trigger) notes that: "the messages sent from [trigger]'s outlets occur in ZERO time with no delay between the events...". Thus, a bang goes first into the right inlet of [timer] which outputs "elapsed logical time", and then a bang goes into left inlet of [timer], which resets the timer. I collect the elapsed time and the slider value with [pack], and I [print] those values. The problem, as the screenshot shows, is that I get values like this:

...
print: 10.1587 0.462312
print: 43.5374 0.396985
print: 0 0.341709
print: 0 0.306533
print: 0 0.276382
print: 23.22 0.271357
...

This tells me that the slider changed e.g. from 0.396985 to 0.341709 in 0 ms, which should not be possible: there must have been some time elapsed for me to move the mouse (which would trigger the required handlers in the OS and PureData) in order to set a new value for the slider?!

So, why does this happen; is it expected; - and is there a PD object (or external) that would allow me accurate measurement of time elapsed between two consecutive output values of [hsl] slider during dragging with the mouse (accurate in the sense that all elapsed times measured should be greater than zero)?

EDIT: just found [realtime], which is like [timer] (and can be used as a drop-in replacement in this patch), but outputs floating point values; so I get plain zeroes no longer - however, I get prints like this:

...
print: 0.029 0.361809 
print: 0.025 0.366834 
print: 47.714 0.376884 
print: 0.022 0.386935 
print: 14.988 0.39196 
print: 36.526 0.396985 
print: 40.294 0.40201 
...

... which is still kind of unrealistic: e.g. slider changed from 0.361809 to 0.366834 (approx 0.005) in 25 microsec; and then changed from 0.366834 to 0.376884 (approx for 0.01, twice the change from previous) in 47 millisec - 1880 times longer than previous interval! So I'm not sure this is all that accurate, either...

The code: test_slider.pd