Re: [PD] loading Camomile plug-ins using vstplugin~

[JTG III]

Seems to work on MacOS Sierra.

On Sun, Jan 20, 2019, 1:55 PM Christof Ressi,  wrote:

> BTW, I recommend compiling vstplugin~ from the develop branch because I've
> fixed a bug on Linux where closing JUCE plugins (like Camomile) with the
> GUI enabled would sometimes crash X11. I can't merge into master yet
> because the commits are entangled with SuperCollider code which is still
> under review...
>
> Christof
>
> > Gesendet: Sonntag, 20. Januar 2019 um 18:07 Uhr
> > Von: "Miller Puckette" 
> > An: "Christof Ressi" 
> > Cc: cla...@mathr.co.uk, Pd-List 
> > Betreff: Re: Re: [PD] loading Camomile plug-ins using vstplugin~
> >
> > Bingo!  I added the RTLD_DEEPBIND flag to the dlopen() call in
> vstplugin~ and
> > my Camomile plug-in sprang to life.
> >
> > Now, as to _why_ anyone migth want to do this, here's my use case:  I'm
> > working with a musician who uses Abelton on a Mac, so I want to write
> him a
> > plug-in.  But I have no usable real-time VST hosts on my old Mac (I keep
> an
> > old MACOS so I can compile Pd back-compatibly).  I also don't have any
> > real-time VST hosting software on linux where I'm developing the patch
> for
> > the plug-in.  I could learn Ardour (maybe it's time I did that anyhow)
> but
> > the fastest way I could see to be able to host my plug-in is from Pd,
> which
> > is a piece of software I know well.
> >
> > cheers
> > Miller
> >
> > On Sun, Jan 20, 2019 at 05:18:56PM +0100, Christof Ressi wrote:
> > > maybe the RTLD_DEEPBIND flag to dlopen() could do the trick?
> > >
> > > http://man7.org/linux/man-pages/man3/dlopen.3.html
> > >
> > > if I understand correctly, with this flag the shared object should
> prefer its own symbols, in this case pd_init() from the statically linked
> libpd, not from the Pd app. I don't have time right now to test this,
> though.
> > >
> > > and guess what: [vstplugin~] + Camomile actually seems to work on
> Windows :-D :-D :-D. See attached picture.
> > >
> > > Christof
> > >
> > > > Gesendet: Sonntag, 20. Januar 2019 um 14:55 Uhr
> > > > Von: "Christof Ressi" 
> > > > An: Pd-List 
> > > > Betreff: Re: [PD] loading Camomile plug-ins using vstplugin~
> > > >
> > > > > Maybe static linking of libpd in Camomile would fix this?
> > > >
> > > > I think Camomile already links statically against libpd.
> > > >
> > > >
> > > > > Gesendet: Sonntag, 20. Januar 2019 um 14:35 Uhr
> > > > > Von: "Claude Heiland-Allen" 
> > > > > An: pd-list@lists.iem.at
> > > > > Betreff: Re: [PD] loading Camomile plug-ins using vstplugin~
> > > > >
> > > > > Hi,
> > > > >
> > > > > On 20/01/2019 01:52, Miller Puckette wrote:
> > > > > > I don't think it works.  Unless I'm misreading things, once
> Camomile calls
> > > > > > pd_init(), that call doesn't go to the pd_init that's compiled
> into
> > > > > > Camomile (via libpd) but instead calls pd_init from the Pd that
> called
> > > > > > vstplugin~ that called Camomile.  This does nothing, and the
> next thing libpd
> > > > > > tries to access in the Pd instance fails.
> > > > > Maybe static linking of libpd in Camomile would fix this??? But
> that
> > > > > would just postpone the issue until the first dynamically-linked
> > > > > external is loaded by the deeper Pd, which tries to access eg
> > > > > class_new(): does it get the one in Pd host or Camomile .pd_linux?
> > > > >
> > > > > On GNU glibc systems, dlmopen() may be relevant?
> > > > >
> > > > >
> > > > > Claude
> > > > > --
> > > > > https://mathr.co.uk
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ___
> > > > > Pd-list@lists.iem.at mailing list
> > > > > UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
> > > > >
> > > >
> > > >
> > > >
> > > > ___
> > > > Pd-list@lists.iem.at mailing list
> > > > UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
> > > >
> >
> >
> >
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] loading Camomile plug-ins using vstplugin~

[JTG III]

I was just thinking about this about an hour ago and was literally just
going to try it out right now!
In, uh, unrelated news, my plans for tonight fell through, so, uh, my
schedule is pretty wide open...

On Jan 19, 2019 8:57 PM, "Miller Puckette"  wrote:

To Pd list -

In case anyone else thought they could use vstplugin~ (By Hannes, available
from https://git.iem.at/pd/vstplugin) to load Camomile
(https://github.com/pierreguillot/Camomile) -

I don't think it works.  Unless I'm misreading things, once Camomile calls
pd_init(), that call doesn't go to the pd_init that's compiled into
Camomile (via libpd) but instead calls pd_init from the Pd that called
vstplugin~ that called Camomile.  This does nothing, and the next thing
libpd
tries to access in the Pd instance fails.

Here, Pure Data itself (the calling program) is compiled single-thread, and
libpd is compiled multi-thread; this means data structures in the two are
different so they can't call back and forth; anything in libpd had better
refer to its own version of things and not the calling program's.

Perhaps there's a way vstplugin~ could load the VST in such a way as to have
it only make calls back into vstplugin~ but not into Pd?  It's all a bit
confusing to me.  Anyhow, who would ever want to do this?  (Except actually
for complicated reasons I would :)

Miller



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Pd Vanilla donecanvasdialog GOP starts edit mode

[JTG III]

yeah, I brought this up when pd-0.49,  or whatever it's going by these
days, was released, it seems to be something that was imported from L2ork
along with the infinite undo, perhaps, or maybe some other new, uh, smart
editing feature,  which I seem to be too simple to get much out of except
frustration, though I'm still using 0.48-2 and maybe I haven't given it a
chance yet.

On Thu, Dec 13, 2018, 9:09 PM João Pais,  wrote:

> Hello list,
>
> I just noticed something new: when sending a donecanvasdialog message to a
> subpatch in a GOP, it starts editmode in the parent patch. Afaik, this
> wasn't the previous behaviour (it still isn't in pd extended).
>
> Here is a patch to illustrate the problem. Doesn't happen with coords,
> though.
>
> Best,
>
> Joao
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] bug with edit-mode (was Re: [PD-announce] PD 0.49-0test1 released)

[JTG III]

I am on Mac, yes, sorry I forgot to mention that. For me the problem is
happening whenever a donecanvasdialog message is sent to a canvas, so I'd
imagine that is triggering the same thing as the properties menu would?
Also, if the donecanvasdialog message happens in an abstraction, it puts
whatever patch the abstraction was created in into edit mode, and this
seems to be where it's going into edit mode sort of silently, as in, it
doesn't say [edit] at the top of the screen and there's no checkmark next
to edit mode in the edit menu, but if you try to click anywhere inside the
patch its obviously in edit mode as you are able to select/resize/etc.
items in the patch but aren't able to click on a bang, for example, or
anything else--but I've only been able to reliably reproduce this when
first opening a patch that sends a donecanvasdialog message upon opening.
It's happened occasionally after the patch has been opened, but usually the
top of the pd window will indicate [edit] at least when a donecanvasdialog
message is sent. The crash upon closing the patch happens every time,
though. I realize that the donecanvasdialog thing is an unsupported method
or whatever, but it seems like the crashing might be part of a more general
problem somewhere, maybe?

I've just tested 0.49-0test2-i386 just now and the crash and everything
preceding it is still happening. I've attached a patch demonstrating how
the problem is being triggered for me, if maybe someone with a mac wants to
check it out to confirm. It should open in edit mode without the [edit]
message appearing in the title bar or whatever its called or the edit mode
option in the edit dropdown menu being checked, and then make the patch go
into edit mode again each time the donecanvasdialog message is sent, and
finally it should crash pd when the window is closed.

ps - I seem to have mostly gotten around the issue by using coords instead
of donecanvasdialog, which I normally do anyway, however it seems the crash
is  happening regardless, but I'm not completely sure that I didn't miss
anything so please take that as a very tentative statement. It might just
be too early yet for my brain to have come online.

On Tue, Sep 11, 2018 at 9:13 PM Miller Puckette  wrote:

> I bet this is related to the "save as" crash bug.  Are you on Mac OSX?
> And... am I reading this correctly that you (1) open any patch; (2) open
> the
> "properties" dialog for the canvas; (3) hit "OK" on the dialog, and then
> you find out that the patch went into edit mode?
>
> (And that it then crashes Pd to close the patch?)
>
> thanks
> Miller
>
> On Tue, Sep 11, 2018 at 07:08:30PM -0400, JTG III wrote:
> > Okay I can can confirm that using donecanvasdialog is triggering the edit
> > mode thing, though I'm not sure why there is no indication from pd upon
> > loading a patch on startup that it is, in fact, in edit mode. I tried
> some
> > patches made by other people, such as waveform.mmb or whatever it is
> > called, and a couple of others and they all toggled edit mode on the
> parent
> > patch.
> > They also all cause pd to crash when the parent patch is closed. I didn't
> > get any hints from the terminal but the script I usually use to start pd
> > wasn't working for some reason and I have to head out again for an hour
> or
> > two but I'll look into it more when I get back.
> >
> > On Sep 11, 2018 6:01 PM, "JTG III" 
> wrote:
> >
> > > Well I know that the canvas is in edit mode as anytime I try to click
> > > anything I end up grabbing something and resizing it instead, and
> toggling
> > > edit mode on and off in the edit menu makes it behave as expected. The
> > > thing with having no indication of currently being in edit mode was
> only
> > > happening when I would first open the patch, and as mentioned I could
> tell
> > > that it was in fact on because whenever I would try to click on
> anything in
> > > the PD window with the mouse the cursor would instead select or start
> > > resizing whatever was beneath it.
> > > Thinking about it now I figure it must have something to do with
> > > donecanvasdialog, would that make sense? I'm not using any gui plugins
> and
> > > no externals are interacting with the gui, but I am using a number of
> > > structs. I'll check that in a couple of hours when I'm back at home.
> > >
> > > On Sep 11, 2018 9:11 AM, "IOhannes m zmoelnig" 
> wrote:
> > >
> > >> hi.
> > >>
> > >> thanks for the bug-report.
> > >>
> > >> unfortunately it indeed doesn't contain much information about what
> > >> could be the actual problem you are experiencing.
> > >>

Re: [PD] bug with edit-mode (was Re: [PD-announce] PD 0.49-0test1 released)

[JTG III]

Okay I can can confirm that using donecanvasdialog is triggering the edit
mode thing, though I'm not sure why there is no indication from pd upon
loading a patch on startup that it is, in fact, in edit mode. I tried some
patches made by other people, such as waveform.mmb or whatever it is
called, and a couple of others and they all toggled edit mode on the parent
patch.
They also all cause pd to crash when the parent patch is closed. I didn't
get any hints from the terminal but the script I usually use to start pd
wasn't working for some reason and I have to head out again for an hour or
two but I'll look into it more when I get back.

On Sep 11, 2018 6:01 PM, "JTG III"  wrote:

> Well I know that the canvas is in edit mode as anytime I try to click
> anything I end up grabbing something and resizing it instead, and toggling
> edit mode on and off in the edit menu makes it behave as expected. The
> thing with having no indication of currently being in edit mode was only
> happening when I would first open the patch, and as mentioned I could tell
> that it was in fact on because whenever I would try to click on anything in
> the PD window with the mouse the cursor would instead select or start
> resizing whatever was beneath it.
> Thinking about it now I figure it must have something to do with
> donecanvasdialog, would that make sense? I'm not using any gui plugins and
> no externals are interacting with the gui, but I am using a number of
> structs. I'll check that in a couple of hours when I'm back at home.
>
> On Sep 11, 2018 9:11 AM, "IOhannes m zmoelnig"  wrote:
>
>> hi.
>>
>> thanks for the bug-report.
>>
>> unfortunately it indeed doesn't contain much information about what
>> could be the actual problem you are experiencing.
>>
>> things i could establish:
>> - your patches switch to edit-mode when they shouldn't
>> - there is no indication of being in edit-mode
>> - you accidentally resize GOPs
>> - abstractions/subpatches send "messages"
>> - you are using a number of externals
>> - Pd sometimes crashes
>> - the problem appears under Pd-0.49-0test1
>> - everything works with Pd-0.48-2
>> (i hope this is correct).
>>
>> so:
>>
>> how do you know that you are in edit-mode? what are the clues that make
>> you believe that you end up in edit mode; what are the clues that are
>> missing (so you don't immediately realize you are in edit mode)?
>>
>> what are these ominous "messages" being sent from abstractions/subpatches?
>> in Pd you are always sending messages between objects; so there must be
>> something special to yours. e.g. do they do some weirdo dynamic patching
>> things?
>>
>> what externals are you using? do these externals interact with the GUI?
>> are there any GUI-plugins involved?
>>
>> ghs,dr
>> IOhannes
>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
>> listinfo/pd-list
>>
>>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] bug with edit-mode (was Re: [PD-announce] PD 0.49-0test1 released)

[JTG III]

Well I know that the canvas is in edit mode as anytime I try to click
anything I end up grabbing something and resizing it instead, and toggling
edit mode on and off in the edit menu makes it behave as expected. The
thing with having no indication of currently being in edit mode was only
happening when I would first open the patch, and as mentioned I could tell
that it was in fact on because whenever I would try to click on anything in
the PD window with the mouse the cursor would instead select or start
resizing whatever was beneath it.
Thinking about it now I figure it must have something to do with
donecanvasdialog, would that make sense? I'm not using any gui plugins and
no externals are interacting with the gui, but I am using a number of
structs. I'll check that in a couple of hours when I'm back at home.

On Sep 11, 2018 9:11 AM, "IOhannes m zmoelnig"  wrote:

> hi.
>
> thanks for the bug-report.
>
> unfortunately it indeed doesn't contain much information about what
> could be the actual problem you are experiencing.
>
> things i could establish:
> - your patches switch to edit-mode when they shouldn't
> - there is no indication of being in edit-mode
> - you accidentally resize GOPs
> - abstractions/subpatches send "messages"
> - you are using a number of externals
> - Pd sometimes crashes
> - the problem appears under Pd-0.49-0test1
> - everything works with Pd-0.48-2
> (i hope this is correct).
>
> so:
>
> how do you know that you are in edit-mode? what are the clues that make
> you believe that you end up in edit mode; what are the clues that are
> missing (so you don't immediately realize you are in edit mode)?
>
> what are these ominous "messages" being sent from abstractions/subpatches?
> in Pd you are always sending messages between objects; so there must be
> something special to yours. e.g. do they do some weirdo dynamic patching
> things?
>
> what externals are you using? do these externals interact with the GUI?
> are there any GUI-plugins involved?
>
> ghs,dr
> IOhannes
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] PD 0.49-0test1 released

[JTG III]

So, this seems to be a thing: Something i'm doing in this patch/system of
patches I've been working on for the last year or so keeps making the
canvas switch into edit mode automatically, including right when I open it
up in which case the window gives no indication of actually being in edit
mode--I had to go turn it on in the edit menu first because it's not
reporting being in edit mode there either, before I can turn it off. It's
possible that I could have been able to toggle it off from the keyboard
menu, I didn't really think to try because I was confused as to what was
happening as I couldn't see any indication that edit mode was on, yet I
kept resizing/breaking gop and data structure canvases whenever I'd click
on anything.
My patch is way too big and confusing to share, but it seems to be somehow
related to messages sent from various subpatches/abstractions when whatever
task is being performed inside is completed. I don't have the time to try
to figure anything out right now, and my attempts to do so in the last hour
or so kept on getting foiled by PD crashing periodically. That could be
related to externals I'm using or something, maybe, but the automatic
switching into edit mode seemed to be originating from something more
Vanilla.
To avoid any further outbursts directed against the mouse or keyboard, I've
switched back to 0.48-2 and things are working normally again, but if need
be I could try to pinpoint the source of the issues some more--preferably
with some sort of hint as to what I should be looking for--when I get back
home later today.

On Tue, Sep 11, 2018 at 1:24 AM Miller Puckette  wrote:

> The first test version of Pd 0.49-0 is available on
> http://msp.ucsd.edu/software.htm
> or (source only) via github: https://github.com/pure-data/pure-data
>
> cheers
> Miller
>
>
>
> ___
> Pd-announce mailing list
> pd-annou...@lists.iem.at
> https://lists.puredata.info/listinfo/pd-announce
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] pd 0.48-0test1 released

[JTG III]

I also got rid of the plots, which also solved my problem, I may have
deleted mine, though.I'll check when I get back home in an hour or so, but
off the top of my head, there would have been Gem and iemlib, and really I
think that's about it, so maybe it's Gem?

On Jul 15, 2017 1:30 PM, "me.grimm" <megr...@gmail.com> wrote:

> >> dans retina changes
>
> ah i see now there is a specific branch for this. can the 
> osx-retina-support
> branch be merged with master?
>
> thanks!
> m
>
> On Sat, Jul 15, 2017 at 1:23 PM, me.grimm <megr...@gmail.com> wrote:
>
>> also i wonder if its possible to compile with dans retina changes. i can
>> not remember off tip of head but i "think" this was using tc/tcl 8.6? I
>> attached image. bottom is old 0.47.1 compile and top is recent compile. i
>> did not see anything specific to this in pull requests.
>>
>> On Sat, Jul 15, 2017 at 1:19 PM, me.grimm <megr...@gmail.com> wrote:
>>
>>> yeah sure. old plist:
>>>
>>> // !!! BINARY PROPERTY LIST WARNING !!!
>>> //
>>> // The pretty-printed property list below has been created
>>> // from a binary version on disk and should not be saved as
>>> // the ASCII format is a subset of the binary representation!
>>> //
>>> { audioapi = "4";
>>> audiobuf = "5";
>>> "audioindev1" = "0 2";
>>> "audioindevname1" = "Built-in Microph";
>>> "audiooutdev1" = "0 2";
>>> "audiooutdevname1" = "Built-in Output";
>>> blocksize = "64";
>>> callback = "0";
>>> defeatrt = "0";
>>> flags = "";
>>> "loadlib1" = "Gem";
>>> nloadlib = "1";
>>> noaudioin = "False";
>>> noaudioout = "False";
>>> nomidiin = "True";
>>> nomidiout = "True";
>>> npath = "1";
>>> "path1" = "/Users/megrimm/Library/Pd/Gem";
>>> rate = "44100";
>>> standardpath = "1";
>>> verbose = "0";
>>> zoom = "1";
>>> }
>>>
>>> On Sat, Jul 15, 2017 at 1:12 PM, Miller Puckette <m...@ucsd.edu> wrote:
>>>
>>>> OK, so my guess is that Pd is crashing when it tries to load
>>>> preferences.
>>>> You didn't by any chance keep a copy of the old "plist" files did you?
>>>>
>>>> Perhaps it's an attempt to load external libraries that are no longer
>>>> compatible for some reason.  I need to find a way to get Pd to survive
>>>> when "bad" binaries get oaded into it :)
>>>>
>>>> M
>>>>
>>>> On Sat, Jul 15, 2017 at 01:05:51PM -0400, me.grimm wrote:
>>>> > hmmm bot seem to start fine now (after I removed
>>>> org.puredata.pd.plist
>>>> > and org.puredata.pd.pd-gui.plist)... although cli output is
>>>> different with
>>>> > error from 64bit:
>>>> >
>>>> > megrimm-mbp:Desktop megrimm$ Pd-0.48-0test1.app/Contents/Re
>>>> sources/bin/pd
>>>> >
>>>> > Pt_Start() called
>>>> >
>>>> > pdsend errorname: >>error writing "sock6": broken pipe<<
>>>> >
>>>> > megrimm-mbp:Desktop megrimm$
>>>> > Pd-0.48-0test1-32bit.app/Contents/Resources/bin/pd
>>>> >
>>>> > Pt_Start() called
>>>> >
>>>> > ^CPd: signal 2
>>>> >
>>>> > gui socket 4 - closing audio...
>>>> >
>>>> > closing MIDI...
>>>> >
>>>> > ... done.
>>>> >
>>>> > On Sat, Jul 15, 2017 at 1:00 PM, Miller Puckette <m...@ucsd.edu>
>>>> wrote:
>>>> >
>>>> > > Hmm...  CAn either or both of you try it from a terminal window and
>>>> show me
>>>> > > what error messages you're getting?  To do that, open a "terminal"
>>>> window
>>>> > > and type a command like:
>>>> > >
>>>> > > /Users/msp/build/Pd-0.48-0test1.app/Contents/Resources/bin/pd
>>>> > >
>>>> > > (substituting your local path to Pd for the one I used above)
>>>> > &

Re: [PD] [PD-announce] pd 0.48-0test1 released

[JTG III]

The 32 but Mac version just keeps crashing as it opens for me. The 64bits
version seems to work fine.

I'll try it out on a windows machine in a little while.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] csoundapi~.pd

[JTG III]

You'll get a rather old version of it that way, I think 6.02, while the
current version is 6.09.1.
Luckily it's rather simple to compile from source

On Jun 27, 2017 4:59 PM, "IOhannes m zmölnig"  wrote:

> On 06/27/2017 10:14 PM, Pagano, Patrick wrote:
> > i would like to use csoundapi~ if it still exists?
> >
> > I am using debian on raspberry pi and arch linux for organelle,
> >
> >
> > can someone point me to the place to find it?
>
> # aptitude install pd-csound
>
> gmsadr
> IOhannes
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Formant from SC in Pd?

[JTG III]

Filters version of FOF synthesis technique (Chant, etc.).
On Apr 13, 2017 12:22 AM, "Alexandre Torres Porres" 
wrote:

> Howdy, you people have an idea of what that Formant UGen from
> SuperCollider is? I'm wondering how to recreate it in a Pd patch, or at
> least find some references to what it is.
>
>
> thanks
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list