Re: [PD] include libpd? (Re: plans for Pd 0.48)

2017-01-05 Thread Dan Wilcox 
> On Jan 5, 2017, at 2:08 AM, pd-list-requ...@lists.iem.at wrote:
> 
> From: IOhannes m zmölnig <zmoel...@iem.at <mailto:zmoel...@iem.at>>
> Subject: Re: [PD] include libpd? (Re: plans for Pd 0.48)
> Date: January 4, 2017 at 12:51:31 PM MST
> To: pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>
> 
> 
> On 01/04/2017 04:02 PM, Dan Wilcox wrote:
>> 
>> 
>> 
>>> On Jan 4, 2017, at 4:00 AM, pd-list-requ...@lists.iem.at 
>>> <mailto:pd-list-requ...@lists.iem.at> wrote:
>>> 
>>> the important question is of course, whether the various language
>>> wrappers would be able to use a common libpd.so - if not, the entire
>>> exercise might be moot.
>> 
>> On platforms with dynamic linking (*nix, non-iOS), this should be no problem.
> 
> yes of course.
> btw, i thought that iOS does have dynamic linking (you surely don't
> statically link in libc, do you?), it's only dlopen() that is missing.

Yeah. I mean more you 

>> 
>>> afaict, the wrappers currently use static linking, but that might just
>>> be for convenience reasons.
>> 
>> Yes. I want to add building dynamic libs but thought to do so with a move to 
>> autotools.
> 
> right.
> 
>> 
>>> it would be interesting to hear peter and dan (or some other libpd
>>> experts) on this.
>> 
>> I see two options:
>> 
>> 1. Have the pd core, as required by libpd, built as a separate dynamic lib.
>> We could do this with the recent autotools updates relatively easily. Then
>> vanilla as well as libpd and it's wrappers all link to the same lib. Downside
>> is you’re required to install the puredata package to use libpd. This then
>> brings up the idea of could the core be it’s own separate package that the
>> others all use?
> 
> i'm not entirely sure what you mean with "package" in this context.

I mean more a Debian package.

> there would be a "libpd" binary package and a separate "puredata-core" binary 
> package. the latter might use the former.
> (and it might as well not; the only relation the two debs ought to have
> is that they are built from the same source package)

Ok. My thinking is we just add a configure option to build the core as a 
separate lib. That would be the easiest approach in the short term.

>> This leads to option 2.
>> 
>> 2. The pd core is split out as a separate library which the gui and the 
>> libpd wrappers all use.
>> At that point, it’s basically libpd. Downside here of course is figuring out 
>> what makes the most
>> sense in regards to future development (ie. is this desired?) and plainly 
>> doing the work. This is
>> probably the best overall approach going forward and was touched upon
> by some of the discussions
>> at the pd con, but I might be afraid of “breaking things that work.” :)
> 
> isn't this the same as what i proposed "on the long run”?

Yeah. Just confirming.


Dan Wilcox
@danomatika <https://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>


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

Re: [PD] include libpd? (Re: plans for Pd 0.48)

2017-01-05 Thread Miller Puckette 
Aha, thanks for pointing that out... 

I think it will be necessary to make various "ifdef" differences between
pdlib and Pd vanilla.  Even if this socket problem could be fixed with a
runtime flag, there remain thread-safety changes that I believe can't be
resolved without breakng binary compatibility with Pd vanilla.

So to return to Iohannes's question, yes, I think there could be a pd.so
compile target added to Pd vanilla - but I can't tell in advance if Pd can
me made multi-thread-capable and maintain binary compatible with existing
externs.  I think I or somebody will just have to try to code it and see
what's possible.

cheers
Miller


On Thu, Jan 05, 2017 at 10:02:36AM +, Giulio Moro via Pd-list wrote:
> Speaking of Bela, we have also been using libpd for the past nine months or 
> so. Some modifications were necessary to allow Xenomai to perform at its 
> best.  https://github.com/BelaPlatform/libpd/
> The most important was to take the `sys_microsleep()` out of PROCESS(_x, _y) 
> in z_libpd.c : this was performing socket I/O in the audio thread, and this 
> is bad practice in general, but particularly dangerous when using 
> Xenomai.This broke [netreceive] and until recently we relied on the libpd API 
> to replace it.I did some work last month for a threaded [netreceive] which 
> uses a ringbuffer. https://github.com/giuliomoro/pure-data/tree/Bela-net 
> (still work-in-progress)I think this is a reasonable solution (surely for us, 
> perhaps for others?) in that network communication is by definition not 
> deterministic, so having it in the audio thread did not make it any better.
> Other modifications involved taking the minimum blocksize down to 8 samples 
> and implement threading for [sigmund~] (still hacky). In the future I'll want 
> to implement threading for all vanilla objects which process large blocks of 
> samples at a time (e.g.: fft~, fiddle~), as previously discussed on this 
> list: https://lists.puredata.info/pipermail/pd-list/2016-09/116224.html
> 
> 
> 
> 
>  
>   From: Scott R. Looney <scottrloo...@gmail.com>
>  To: pd-list <pd-list@lists.iem.at> 
>  Sent: Thursday, 5 January 2017, 9:07
>  Subject: Re: [PD] include libpd? (Re: plans for Pd 0.48)
>
> actually, i was curious about that myself but sort of on both tangents. at 
> the higher end i'm using Unity and PD vanilla via Kalimba and would 
> definitely like to use it without involving too much extra as it is in that 
> situation. 
> but the embedded factor is pretty important too. i've been checking out Bela 
> which has to compile PD patches using Heavy as well as using Xenomai to make 
> PD work efficiently (and Heavy doesn't support a lot of objects at the 
> moment). i would imagine that Johannes Taelmann was considering something 
> like PD for his Axoloti but couldn't make it work performance wise and so 
> decided to roll his own graphic patching setup instead.
> best,scott
> On Wed, Jan 4, 2017 at 10:17 AM, Peter Nyboer <p...@nbor.us> wrote:
> 
> 
> > another wishlist from my side (which I wanted to address at PdCon16~ but
> > somehow didn't manage).
> > would it be possible to include the libpd glue into the proper Pd sources?
> 
> Funny - I had a somewhat tangential thought this morning. Something to the 
> effect of it being easier to deploy libpd on embedded devices. I haven’t 
> really looked into it very deeply, hence my uncertainly about whether or not 
> it’s easy, but I know it’s not “juzt 1 klik!” (oh, yeah, I went there).
> 
> Peter
> __ _
> 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] include libpd? (Re: plans for Pd 0.48)

2017-01-05 Thread Scott R. Looney 
actually, i was curious about that myself but sort of on both tangents. at
the higher end i'm using Unity and PD vanilla via Kalimba and would
definitely like to use it without involving too much extra as it is in that
situation.

but the embedded factor is pretty important too. i've been checking out
Bela which has to compile PD patches using Heavy as well as using Xenomai
to make PD work efficiently (and Heavy doesn't support a lot of objects at
the moment). i would imagine that Johannes Taelmann was considering
something like PD for his Axoloti but couldn't make it work performance
wise and so decided to roll his own graphic patching setup instead.

best,
scott

On Wed, Jan 4, 2017 at 10:17 AM, Peter Nyboer  wrote:

>
> > another wishlist from my side (which I wanted to address at PdCon16~ but
> > somehow didn't manage).
> > would it be possible to include the libpd glue into the proper Pd
> sources?
>
> Funny - I had a somewhat tangential thought this morning. Something to the
> effect of it being easier to deploy libpd on embedded devices. I haven’t
> really looked into it very deeply, hence my uncertainly about whether or
> not it’s easy, but I know it’s not “juzt 1 klik!” (oh, yeah, I went there).
>
> Peter
> ___
> 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] include libpd? (Re: plans for Pd 0.48)

2017-01-04 Thread Peter Nyboer 

> another wishlist from my side (which I wanted to address at PdCon16~ but
> somehow didn't manage).
> would it be possible to include the libpd glue into the proper Pd sources?

Funny - I had a somewhat tangential thought this morning. Something to the 
effect of it being easier to deploy libpd on embedded devices. I haven’t really 
looked into it very deeply, hence my uncertainly about whether or not it’s 
easy, but I know it’s not “juzt 1 klik!” (oh, yeah, I went there).

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

Re: [PD] include libpd? (Re: plans for Pd 0.48)

2017-01-04 Thread IOhannes m zmölnig 
On 01/04/2017 04:02 PM, Dan Wilcox wrote:
> 
> 
> 
>> On Jan 4, 2017, at 4:00 AM, pd-list-requ...@lists.iem.at wrote:
>>
>> the important question is of course, whether the various language
>> wrappers would be able to use a common libpd.so - if not, the entire
>> exercise might be moot.
> 
> On platforms with dynamic linking (*nix, non-iOS), this should be no problem.

yes of course.
btw, i thought that iOS does have dynamic linking (you surely don't
statically link in libc, do you?), it's only dlopen() that is missing.

> 
>> afaict, the wrappers currently use static linking, but that might just
>> be for convenience reasons.
> 
> Yes. I want to add building dynamic libs but thought to do so with a move to 
> autotools.

right.

> 
>> it would be interesting to hear peter and dan (or some other libpd
>> experts) on this.
> 
> I see two options:
> 
> 1. Have the pd core, as required by libpd, built as a separate dynamic lib.
> We could do this with the recent autotools updates relatively easily. Then
> vanilla as well as libpd and it's wrappers all link to the same lib. Downside
> is you’re required to install the puredata package to use libpd. This then
> brings up the idea of could the core be it’s own separate package that the
> others all use?

i'm not entirely sure what you mean with "package" in this context.

in case you are talking about Debian packages (but i might be blinded,
and you are talking about something completely different), then your
fear is ungrounded. there would be a "libpd" binary package and a
separate "puredata-core" binary package. the latter might use the former.
(and it might as well not; the only relation the two debs ought to have
is that they are built from the same source package)

> This leads to option 2.
> 
> 2. The pd core is split out as a separate library which the gui and the libpd 
> wrappers all use.
> At that point, it’s basically libpd. Downside here of course is figuring out 
> what makes the most
> sense in regards to future development (ie. is this desired?) and plainly 
> doing the work. This is
> probably the best overall approach going forward and was touched upon
by some of the discussions
> at the pd con, but I might be afraid of “breaking things that work.” :)

isn't this the same as what i proposed "on the long run"?


gfmrdsa
IOhannes



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

Re: [PD] include libpd? (Re: plans for Pd 0.48)

2017-01-04 Thread Dan Wilcox 



> On Jan 4, 2017, at 4:00 AM, pd-list-requ...@lists.iem.at wrote:
> 
> the important question is of course, whether the various language
> wrappers would be able to use a common libpd.so - if not, the entire
> exercise might be moot.

On platforms with dynamic linking (*nix, non-iOS), this should be no problem.

> afaict, the wrappers currently use static linking, but that might just
> be for convenience reasons.

Yes. I want to add building dynamic libs but thought to do so with a move to 
autotools.

> it would be interesting to hear peter and dan (or some other libpd
> experts) on this.

I see two options:

1. Have the pd core, as required by libpd, built as a separate dynamic lib. We 
could do this with the recent autotools updates relatively easily. Then vanilla 
as well as libpd and it's wrappers all link to the same lib. Downside is you’re 
required to install the puredata package to use libpd. This then brings up the 
idea of could the core be it’s own separate package that the others all use? 
This leads to option 2.

2. The pd core is split out as a separate library which the gui and the libpd 
wrappers all use. At that point, it’s basically libpd. Downside here of course 
is figuring out what makes the most sense in regards to future development (ie. 
is this desired?) and plainly doing the work. This is probably the best overall 
approach going forward and was touched upon by some of the discussions at the 
pd con, but I might be afraid of “breaking things that work.” :)

> on the long run, i'm dreaming of pd-vanilla using libpd directly (that
> is, dynamically linking against libpd.so like other applications, rather
> than statically including it). but that's probably for 0.48-1 :-)

Yeah. Thats more of a major change I could see in a possible 0.49. Also, we 
have some thoughts on updating the API with regards to figuring out the 
multiple instances problem, so I see needing more time in the roadmap.


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

[PD] include libpd? (Re: plans for Pd 0.48)

2017-01-04 Thread IOhannes m zmoelnig 
On 2017-01-01 21:32, Miller Puckette wrote:
> This is a long list [...]

another wishlist from my side (which I wanted to address at PdCon16~ but
somehow didn't manage).
would it be possible to include the libpd glue into the proper Pd sources?
i'm only talking about the C-part of libpd as found in the folder
[libpd_wrapper], not about the various language bindings.

the idea is:
- to be able to build the core libpd.so from the Pd-vanilla sources
- from the libpd perspective nothing would change (apart from adjusting
the paths to some files in the main Makefile)
- the various language wrappers (C++, C#, ...) *could* be built as
(very) thin libraries that dynamically link against libpd.so

the main reasoning is, that i would like to have libpd in
Debian/Ubuntu/... proper, and they are very peculiar about code
duplication, that is: it's forbidden by policy to include the same
non-trivial sources twice in the archives; however, the current model of
libpd source distribution does exactly this.
being able to build libpd directly from pd-vanilla would greatly
simplify things for me.


the important question is of course, whether the various language
wrappers would be able to use a common libpd.so - if not, the entire
exercise might be moot.
afaict, the wrappers currently use static linking, but that might just
be for convenience reasons.
it would be interesting to hear peter and dan (or some other libpd
experts) on this.


on the long run, i'm dreaming of pd-vanilla using libpd directly (that
is, dynamically linking against libpd.so like other applications, rather
than statically including it). but that's probably for 0.48-1 :-)


asdfmr
IOhannes



[libpd_wrapper] https://github.com/libpd/libpd/tree/master/libpd_wrapper



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