Hi,
I created a plugin that loads Pure Data patches so I had to use several
instances of Pure Data in a multi thread context. I managed to solve the
problems using t_pdinstance and locks (so I needed to create my own wrapper
like libpd). I think it would be great to integrate some of these
improvements to libpd. Before sending a pull request or opening another
issue on the repository about it, I thought that it would be better to
present how I did this here.
I'm assuming that several instances can't run in parallel for 3 main
reasons:
1 - The clocks can be created on the fly, so if the current instance is not
the right one, the clocks can be integrated in a wrong list. This problem
implies that all the methods that can create a clock (so potentially all
the messages sent to Pure Data) and the sched_tick method must be called
sequentially. I tried to find a solution (
https://sourceforge.net/p/pure-data/patches/559/) but there are always some
specific cases that can’t be thread safe. The only real solution is (by a
way or another) to set up the instance of the clock at its creation but
this implies to change the interface of Pure Data and potentially (surely)
a lot of externals would be deprecated.
2 - The vectors of audio input and output are global and the dsp_add method
is global. So the DSP method must be called with the right instance. Here
again, the only real solution would be to change the interface of Pure
Data, to receive the instance in the dsp method and to add the perform
methods to this instance. The dac and adc objects would also be able to
retrieve the the vector of audio input and output specific to the instance.
3 - The MIDI methods are global. That implies that most the methods must be
called sequentially if you don’t want to receive or send MIDI events to the
wrong instance.
So the best solution is simply to use t_pdinstance. If the interface is
opaque and before calling any method you set the instance and lock it, you
should not have any problem. Basically, my interface is like this: First,
initialize Pure Data and after you can call
- Create an instance (lock – create the instance – unlock). Each instance
has its own vectors of audio input and output, MIDI methods, print method.
- Create a patch (lock, set the instance, create the patch, unlock).
- Prepare the dsp (lock, set the instance, reallocate the vectors of audio
if the sample rate or the number of inputs or outputs changed, send dsp
start message, unlock). In the DAWs like Reaper you must be able to have
two instances running with two different sample rates.
- All the other methods are called like this:
- Lock and set the instance
- Send the MIDI events, send the messages, process the DSP
- Unlock
When you set the instance it also sets the current vectors of audio, the
print method and the MIDI methods so the instance receives all the MIDI
output event, output messages, posts, etc. It seems better to gather the
methods for the messages, MIDI and DSP together. You can avoid this but in
practise, I don’t see any reason.
The instance management is mostly in the c wrapper and the lock feature is
in the C++ wrapper. Here the code: (
https://github.com/pierreguillot/Camomile/tree/master/Source/Pd). Most of
the important stuff are in z_pd.c/.h (and PdInstance.cpp/.hpp). Of course,
I have my own programming style, if you are interested I'll submit merge
requests trying to respect the libPD programming style.
Cheers
Curious about a couple clang warnings for fiddle~.c:
pure-data/extra/fiddle~/fiddle~.c:1120:20: warning: comparison of constant 0 with boolean expression is always false [-Wtautological-constant-out-of-range-compare]
if (!npeakanal < 0) npeakanal = 0;
~~~~~~~~~~ ^ ~
pure-data/extra/fiddle~/fiddle~.c:1122:19: warning: comparison of constant 0 with boolean expression is always false [-Wtautological-constant-out-of-range-compare]
if (!npeakout < 0) npeakout = 0;
~~~~~~~~~ ^ ~
Since both npeakanal & npeakout are longs, the ! operator is basically checking if they are 0 right by converting to a bool. I follow that. I’m just not sure how a bool can be less than 0 and I guess clang isn’t either :)
--------
Dan Wilcox
@danomatika <https://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
Howdy all,
I put the proposed changes in the previous patches into a couple WIP branches on GH.
https://github.com/pure-data/pure-data/pull/11 <https://github.com/pure-data/pure-data/pull/11>
https://github.com/pure-data/pure-data/pull/12 <https://github.com/pure-data/pure-data/pull/12>
--------
Dan Wilcox
@danomatika <https://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
> On Mar 26, 2016, at 5:41 PM, pd-dev-request(a)lists.iem.at wrote:
>
> Message: 2
> Date: Sun, 27 Mar 2016 10:41:06 +1100
> From: Tobias Brodel <brittlehaus(a)gmail.com <mailto:brittlehaus@gmail.com>>
> To: Dan Wilcox <danomatika(a)gmail.com <mailto:danomatika@gmail.com>>
> Cc: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>
> Subject: Re: [PD-dev] Pd-dev Digest, Vol 132, Issue 15
> Message-ID: <56F71E12.80604(a)gmail.com <mailto:56F71E12.80604@gmail.com>>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> that would be ace.
>
> happy easter all.
>
> On 03/27/16 10:17, Dan Wilcox wrote:
>> I can change stddef.h to stdlib.h in that proposed include update.
>>
>> --------
>> Dan Wilcox
>> @danomatika <https://twitter.com/danomatika <https://twitter.com/danomatika>>
>> danomatika.com <http://danomatika.com/> <http://danomatika.com <http://danomatika.com/>>
>> robotcowboy.com <http://robotcowboy.com/> <http://robotcowboy.com <http://robotcowboy.com/>>
>>
>>> On Mar 26, 2016, at 5:00 AM, pd-dev-request(a)lists.iem.at <mailto:pd-dev-request@lists.iem.at>
>>> <mailto:pd-dev-request@lists.iem.at <mailto:pd-dev-request@lists.iem.at>> wrote:
>>>
>>> Message: 2
>>> Date: Sat, 26 Mar 2016 13:32:06 +1100
>>> From: Tobias Brodel <brittlehaus(a)gmail.com <mailto:brittlehaus@gmail.com>
>>> <mailto:brittlehaus@gmail.com <mailto:brittlehaus@gmail.com>>>
>>> To:pd-dev@lists.iem.at <mailto:dev@lists.iem.at> <mailto:pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at>>
>>> Subject: Re: [PD-dev] clang warning fixes, was: Memory leaks?
>>> Message-ID: <56F5F4A6.3070001(a)gmail.com <mailto:56F5F4A6.3070001@gmail.com>
>>> <mailto:56F5F4A6.3070001@gmail.com <mailto:56F5F4A6.3070001@gmail.com>>>
>>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>>
>>> hi dan, list.
>>>
>>> i have some patches i've been meaning to submit relating to the alloca.h
>>> ifdef hell.
>>>
>>> i'm a FreeBSD user and the stddef.h else clause is wrong and actually
>>> gets patched out downstream. Free/Net/Open and DragonFly BSD all have
>>> alloca() in stdlib.h.
>>>
>>> i'll can review my patches now and upload them but they retain the old
>>> style, not your proposed changes.
>>>
>>> cheers,
>>> t.
>
I can change stddef.h to stdlib.h in that proposed include update.
--------
Dan Wilcox
@danomatika <https://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
> On Mar 26, 2016, at 5:00 AM, pd-dev-request(a)lists.iem.at wrote:
>
> Message: 2
> Date: Sat, 26 Mar 2016 13:32:06 +1100
> From: Tobias Brodel <brittlehaus(a)gmail.com <mailto:brittlehaus@gmail.com>>
> To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>
> Subject: Re: [PD-dev] clang warning fixes, was: Memory leaks?
> Message-ID: <56F5F4A6.3070001(a)gmail.com <mailto:56F5F4A6.3070001@gmail.com>>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> hi dan, list.
>
> i have some patches i've been meaning to submit relating to the alloca.h
> ifdef hell.
>
> i'm a FreeBSD user and the stddef.h else clause is wrong and actually
> gets patched out downstream. Free/Net/Open and DragonFly BSD all have
> alloca() in stdlib.h.
>
> i'll can review my patches now and upload them but they retain the old
> style, not your proposed changes.
>
> cheers,
> t.
The last patch fixed some of the warnings. The rest I’m seeing from clang are simple stuff:
warning: using the result of an assignment as a condition without parentheses [-Wparentheses]
aka
assignments in for loops & if/while statements should be wrapped in parens
warning: '&&' within '||' [-Wlogical-op-parentheses], so added paren wraps
switch statement not handling all enumerations, so added default: break;
Note: this is only for sources used by libpd.
Here’s a patch:
>> On Mar 22, 2016, at 10:39 AM, Miller Puckette <msp(a)ucsd.edu <mailto:msp@ucsd.edu>> wrote:
>>
>> It's already in and up - check away :)
>>
>> M
>> On Tue, Mar 22, 2016 at 10:37:20AM -0600, Dan Wilcox wrote:
>>> Sweet. clang on OSX gives me about 100+ warnings when building the pure-data sources for libpd, most of which involve simple things like suggested paren wraps, “implicit conversion loses integer precision,” etc. These might be related to what iOhannes is seeing. I’ll wait to see if this bugfix work is accepted and then I can make a similar patch for the warnings.
>>>
>>> --------
>>> Dan Wilcox
>>> @danomatika <https://twitter.com/danomatika <https://twitter.com/danomatika>>
>>> danomatika.com <http://danomatika.com/> <http://danomatika.com/ <http://danomatika.com/>>
>>> robotcowboy.com <http://robotcowboy.com/> <http://robotcowboy.com/ <http://robotcowboy.com/>>
>>>> On Mar 22, 2016, at 5:00 AM, pd-dev-request(a)lists.iem.at <mailto:pd-dev-request@lists.iem.at> wrote:
>>>>
>>>> From: IOhannes m zmölnig <zmoelnig(a)iem.at <mailto:zmoelnig@iem.at> <mailto:zmoelnig@iem.at <mailto:zmoelnig@iem.at>>>
>>>> Subject: Re: [PD-dev] Memory leaks?
>>>> Date: March 21, 2016 at 3:29:25 PM MDT
>>>> To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at> <mailto:pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at>>
>>>>
>>>>
>>>> On 03/21/2016 09:51 PM, Miller Puckette wrote:
>>>>> Yep, thanks. Fixing it now...
>>>>
>>>> since you seem to be in bug-squashing mode: there are about 100 more
>>>> bugs waiting to be fixed :-)
--------
Dan Wilcox
@danomatika <https://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
---
** [bugs:#1236] Tcl trace in console while configuring ALSA midi**
**Status:** open
**Group:** v0.46
**Created:** Wed Mar 23, 2016 07:51 PM UTC by electrickery
**Last Updated:** Wed Mar 23, 2016 07:51 PM UTC
**Owner:** nobody
Pd-0.47.0 ("test") compiled 19:15:29 Mar 23 2016
Pre-condition: MIDI device present, activated within ALSA.
While opening Media > MIDI Settings...
opened 0 MIDI input device(s) and 0 MIDI output device(s).
(Tcl) UNHANDLED ERROR: bad side "top-fill": must be top, bottom, left, or right
while executing
"pack $id.buttonframe -side top-fill x -pady 2m"
(procedure "pdtk_alsa_midi_dialog" line 48)
invoked from within
"pdtk_alsa_midi_dialog .gfxstub1021230 0 0 0 0 0 0 0 0 0 1"
("uplevel" body line 4)
invoked from within
"uplevel #0 $docmds"
Same configuration works ok with 0.46.7.
System: Xubuntu 14.04 x86-64
---
Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Sweet. clang on OSX gives me about 100+ warnings when building the pure-data sources for libpd, most of which involve simple things like suggested paren wraps, “implicit conversion loses integer precision,” etc. These might be related to what iOhannes is seeing. I’ll wait to see if this bugfix work is accepted and then I can make a similar patch for the warnings.
--------
Dan Wilcox
@danomatika <https://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
> On Mar 22, 2016, at 5:00 AM, pd-dev-request(a)lists.iem.at wrote:
>
> From: IOhannes m zmölnig <zmoelnig(a)iem.at <mailto:zmoelnig@iem.at>>
> Subject: Re: [PD-dev] Memory leaks?
> Date: March 21, 2016 at 3:29:25 PM MDT
> To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>
>
>
> On 03/21/2016 09:51 PM, Miller Puckette wrote:
>> Yep, thanks. Fixing it now...
>
> since you seem to be in bug-squashing mode: there are about 100 more
> bugs waiting to be fixed :-)