[PD-dev] Shipping & using DejaVu Font on Ms-Windows

[Lucas Cordiviola]

Hi,

This is a refined attempt to ship & use DejaVu font on Ms-Windows via TWAPI.
I have prepared an readme.hml here:

http://lucarda.com.ar/x/dejavu/readme.html

I think is the most easy for Miller's build, the ONLY w32 release, btw.

♥pd
Lucarda.

-- 
Mensaje telepatico asistido por maquinas.

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] DejaVU font on w32 for 0.48-1

[Lucas Cordiviola]

Hi Miller,

I've put some work on shipping & loading DejaVu font on w32 for the new 
nice cross-platform gui.

Can you review this PR? : https://github.com/pure-data/pure-data/pull/270

The branch can be downloaded from: 
https://github.com/Lucarda/pure-data/tree/Using-DejaVu-font-on-Ms-Windows-II

I have tested it on windows machines without the font and it loads it fine.

Is there anything I can do?



-- 
Mensaje telepatico asistido por maquinas.

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] how to configure PD to find ASIO when compiling with mingw?

[Lucas Cordiviola]

Looks that --enable-asio must be passed to ./configure.

I have no experience on cross-compiling but when compiling on windows 
ASIO is included by default with no need to specify it on ./configure.

This is verbatim from 
https://github.com/pure-data/pure-data/blob/master/INSTALL.txt#L327-L338 :



Once the packages are installed, you should now be ready to build Pd.

The following audio APIS are available on Windows and can be 
enabled/disabled
via their configure flags:

* MMIO: --enable-mmio or --disable-mmio (default enabled)
* ASIO: --enable-asio or --disable-asio (default enabled, if found)
* JACK: --enable-jack or --disable-jack

For example, to build Pd without MMIO support:

     ./configure --disable-mmio







Mensaje telepatico asistido por maquinas.

On 5/8/2018 12:46 AM, Miller Puckette wrote:
> TO Pd dev:
>
> I'm able to cross-compile Pd for Windows using Dan's excellent automake
> setup... but can't so far figure out how to get it to include portaudio's
> ASIO bindings.  In fact, it doesn't look to me as if the portaudio auomake
> system is in turn being called (there's no "configure" in portaudio source,
> just configure.in and such.  But I do find a "Makefile" that is dated today
> that someone must have created.)
>
> Os there some magic I need to point portaudio at my ASIO SDK copy, or do
> I need to put that in some magic place for Pd's build sytstem to find it?
>
>
> thanks
> Miller
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] how to configure PD to find ASIO when compiling with mingw?

[Lucas Cordiviola]

Also there where changes on the "name" of the ASIOSDK folder.

verbatim from https://github.com/pure-data/pure-data/tree/master/asio :



# Windows ASIO Support

In order to build ASIO support into Pd on Windows, you need to download the
ASIO sources from Steinberg directly. Their license does not let us
redistribute their source files.

Install the ASIO SDK by doing the following:

1. Download the ASIO SDK: 
https://www.steinberg.net/en/company/developer.html
2. Uncompress asiosdk2.3.zip (or higher) into this directory
3. remove the version number so that you get pure-data/asio/ASIOSDK

Now build Pd and it should include ASIO as one of the audio backends.

---

Mensaje telepatico asistido por maquinas.

On 5/8/2018 2:18 AM, Lucas Cordiviola wrote:
> Looks that --enable-asio must be passed to ./configure.
>
> I have no experience on cross-compiling but when compiling on windows
> ASIO is included by default with no need to specify it on ./configure.
>
> This is verbatim from
> https://github.com/pure-data/pure-data/blob/master/INSTALL.txt#L327-L338 :
>
>
> 
> Once the packages are installed, you should now be ready to build Pd.
>
> The following audio APIS are available on Windows and can be
> enabled/disabled
> via their configure flags:
>
> * MMIO: --enable-mmio or --disable-mmio (default enabled)
> * ASIO: --enable-asio or --disable-asio (default enabled, if found)
> * JACK: --enable-jack or --disable-jack
>
> For example, to build Pd without MMIO support:
>
>       ./configure --disable-mmio
>
>
>
> 
>
>
>
> Mensaje telepatico asistido por maquinas.
>
> On 5/8/2018 12:46 AM, Miller Puckette wrote:
>> TO Pd dev:
>>
>> I'm able to cross-compile Pd for Windows using Dan's excellent automake
>> setup... but can't so far figure out how to get it to include portaudio's
>> ASIO bindings.  In fact, it doesn't look to me as if the portaudio auomake
>> system is in turn being called (there's no "configure" in portaudio source,
>> just configure.in and such.  But I do find a "Makefile" that is dated today
>> that someone must have created.)
>>
>> Os there some magic I need to point portaudio at my ASIO SDK copy, or do
>> I need to put that in some magic place for Pd's build sytstem to find it?
>>
>>
>> thanks
>> Miller
>>
>> ___
>> Pd-dev mailing list
>> Pd-dev@lists.iem.at
>> https://lists.puredata.info/listinfo/pd-dev
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] distributing a collection of externals and abstractions using deken

[Lucas Cordiviola]

Keep in mind that once you've uploaded something it might take 12 (or 
24) hours until deken updates the database. So don't be impatient if it 
doesn't show up on Pd's Deken.


:)

Mensaje telepatico asistido por maquinas.

On 6/17/2018 9:28 AM, Joseph Larralde wrote:
> No, I've been reading this already and it doesn't mention abstractions.
> But you're right, I should try deken first and come back with more 
> precise questions.
> I just wanted to make sure not to push broken things online.
>
> Cheers
> Joseph
>
> Le 17/06/18 à 13:53, Lucas Cordiviola a écrit :
>> Is this what your a looking for? :
>>
>> https://github.com/pure-data/deken/blob/master/developer/README.md
>>
>> -- 
>>
>> Mensaje telepatico asistido por maquinas.
>>
>> On 6/17/2018 8:17 AM, Joseph Larralde wrote:
>>> Hi list,
>>>
>>> Apologies if I didn't browse the archives enough before coming here,
>>> but I remain with a stupid question.
>>>
>>> I have a couple of externals I'd like to publish using deken, and the
>>> doc is explicit enough to allow me to do this.
>>> But, along with these externals, I have some abstractions I've been
>>> using for a while and I'd like to "bundle" them with my library.
>>>
>>> What is the cleanest way to organize my stuff in this case ?
>>> For example, I looked at cyclone's repo, where I found a nice way to
>>> organize my code, its dependencies and the built objects, as well as a
>>> collection of abstractions, but there is neither a .dek file nor an
>>> objectlist in there, and I'm not sure about how one would proceed to
>>> package it with deken.
>>>
>>> I guess there must be scripts to achieve this in other existing
>>> libraries ...
>>> Could anyone please point me to a good example or give me a simple
>>> answer ?
>>>
>>> Thanks,
>>> Joseph
>>>
>>> ___
>>> Pd-dev mailing list
>>> Pd-dev@lists.iem.at
>>> https://lists.puredata.info/listinfo/pd-dev
>> ___
>> Pd-dev mailing list
>> Pd-dev@lists.iem.at
>> https://lists.puredata.info/listinfo/pd-dev
>
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] distributing a collection of externals and abstractions using deken

[Lucas Cordiviola]

Is this what your a looking for? :

https://github.com/pure-data/deken/blob/master/developer/README.md

--

Mensaje telepatico asistido por maquinas.

On 6/17/2018 8:17 AM, Joseph Larralde wrote:
> Hi list,
>
> Apologies if I didn't browse the archives enough before coming here, 
> but I remain with a stupid question.
>
> I have a couple of externals I'd like to publish using deken, and the 
> doc is explicit enough to allow me to do this.
> But, along with these externals, I have some abstractions I've been 
> using for a while and I'd like to "bundle" them with my library.
>
> What is the cleanest way to organize my stuff in this case ?
> For example, I looked at cyclone's repo, where I found a nice way to 
> organize my code, its dependencies and the built objects, as well as a 
> collection of abstractions, but there is neither a .dek file nor an 
> objectlist in there, and I'm not sure about how one would proceed to 
> package it with deken.
>
> I guess there must be scripts to achieve this in other existing 
> libraries ...
> Could anyone please point me to a good example or give me a simple 
> answer ?
>
> Thanks,
> Joseph
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] pdlibbuilder and static linking pthread by default on Windows.

[Lucas Cordiviola]

We have been working on pdlibbuilder and I've proposed static linking 
pthread by default.


https://github.com/pure-data/pd-lib-builder/issues/42

https://github.com/pure-data/pd-lib-builder/issues/36


My motivation on doing such thing is to prevent people from forgetting 
to ship libwinpthread-1.dll when needed.

There are many chances for this to happen as when we test an compiled 
[external] it will be working with Pd's libwinpthread-1.dll so we might 
think that everything is OK. Also people from linux & osx are not really 
aware that on Windows/MinGW pthread is an specific file.

This in turn will let the [external] survive when Pd, in some future, 
will start using a future MinGW pthread implementation.

We discussed this but IOhannes & Dan see static linking as something 
horrible.
I see that there's no difference in shipping the file or statically 
include it in the [external].
I also tested that [externals] that don't use pthread are immune to the 
-static flag.

Is there something I'm missing?
Why not putting a "lifebuoy" by default ?

If a dev does not want -static he/she can override it.

Some thoughts?
community ?

I ask this because I care about Windows Pd and [externals].

-- 
Mensaje telepatico asistido por maquinas.

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pdlibbuilder and static linking pthread by default on Windows.

[Lucas Cordiviola]

There are upcoming compilations for w64 and not-too-soon the 
"double-precision" ones.

This will avoid missing pthreads.

"-static by default" will also help to not make a mistake and ship an 
w32 pthread on a w64 pkg.


Mensaje telepatico asistido por maquinas.

On 2/6/2018 12:43 PM, IOhannes m zmoelnig wrote:
> these two have been re-uploaded since (fwiw, both have been uploaded by
> me), but miss the libpthread*.dll.
> - bsaylor
> - iemnet

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] cross-compiling linus-to-windows 64 bit using automake

[Lucas Cordiviola]

> I guess it's working fine for you - and I guess you're compiling it
> on windows (not cross-compiling form linux, correct)?
Yes.

> I should have mentioned that not only do I get garbage but also it
> doesn't work in the first place (no GUI appears) when I compile it.
Very strange.

If you could do it with "wish85.exe 64 bit", why not with 86?

I leave this for the experts.

:)

Mensaje telepatico asistido por maquinas.

On 2/19/2018 8:15 PM, Miller Puckette wrote:
> I guess it's working fine for you - and I guess you're compiling it
> on windows (not cross-compiling form linux, correct)?
>
> I should have mentioned that not only do I get garbage but also it
> doesn't work in the first place (no GUI appears) when I compile it.
>
> cheers
> Miller
>
> On Mon, Feb 19, 2018 at 10:23:42PM +, Lucas Cordiviola wrote:
>> It all builds fine and I'm able to run wish86.exe all right; but when I try
>> to test it as in:
>>
>> wine pd-0.48-1test2-ia64/bin/wish86.exe 
>> `pwd`/pd-0.48-1test2-ia64/tcl/pd-gui.tcl
>>
>> I get signs of memory corruption that I haven't been able to track down (my
>> debugging statements in pd-gui.tcl generate binary garbage).  This seems to
>> be an interaction between wine and tcl/tk and is almost certainly too deep
>> for me to figure out.
>>
>>
>> I have a Windows MinGW64 build using "wish86.exe" (64-bit) --> 
>> http://lucarda.com.ar/x/Pd-0.48-1-all-w64.zip
>>
>> What do I have to type in the cmd to test if i get "binary garbage"?
>>
>> Note: building on Windows with Msys2 I get the correct 64bit 
>> "libwinpthread-1.dll" copied to pd/bin.
>>
>>
>> --
>>
>> Mensaje telepatico asistido por maquinas.
>>
>> On 2/19/2018 6:42 PM, Miller Puckette wrote:
>>
>> I'm able to sucessfuilly cross-compile 64-bit windows targets from linux
>> now, albeit a bit shakily.  Here's what I've found so far:
>>
>> 'libtool' has a library dependency, -lmsvcrt , which breaks compilation.  It
>> works just to delete it.
>>
>> Somehow a 32-bit version of libwinpthread-1.dll gets installed - I have to
>> manually replace it with a 64-bit one.
>>
>> and... try as I might I still can't get it working with tcl/tk 8.6 - I have 
>> to
>> yse 8.5.  More on that later.
>>
>> My compilation steps currently look like this (after making a clean directory
>> to put it in, /home/msp/bis/work/pd-versions/build-dirs/test85):
>>
>> v=0.48-1test3-ia64
>> tkversion=8.5.19
>> s=/home/msp/tmp/clean-pd-source
>>
>> git clone ~/pd $s
>> cd $s
>> ./autogen.sh
>> cd /home/msp/bis/work/pd-versions/build-dirs/test85
>> $s/configure --host=x86_64-w64-mingw32 CPPFLAGS='-DPD_LONGINTTYPE=__int64'
>> sed -i '/-lmsvcrt/s/-lmsvcrt//g' libtool
>> make
>> cd msw
>> cp -a /home/msp/bis/work/pd-versions/build-tk-on-win64/msw/tcltk-$tkversion .
>> /home/msp/bis/work/pd-versions/build-tk-on-win64/msw/msw-app.sh \
>> --builddir ..  --tk tcltk-$tkversion $v
>> cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libwinpthread-1.dll \
>> pd-$v/bin/
>>
>> (note: I make the clone of the Pd source so I don't have to run automake in 
>> my
>> 'clean' source tree).
>>
>> When I try this for 8.6.8 I change the configuration line as follws:
>> $s/configure --host=x86_64-w64-mingw32 \
>>  --with-wish=wish86.exe \
>>  CPPFLAGS='-DPD_LONGINTTYPE=__int64 -DWISH=\"wish86.exe\"'
>>
>> It all builds fine and I'm able to run wish86.exe all right; but when I try
>> to test it as in:
>>
>> wine pd-0.48-1test2-ia64/bin/wish86.exe 
>> `pwd`/pd-0.48-1test2-ia64/tcl/pd-gui.tcl
>>
>> I get signs of memory corruption that I haven't been able to track down (my
>> debugging statements in pd-gui.tcl generate binary garbage).  This seems to
>> be an interaction between wine and tcl/tk and is almost certainly too deep
>> for me to figure out.
>>
>> This doesn't seem to be a fatal problem though - if my "test" 64-bit build 
>> works
>> OK I can live with that for at least until 8.7 comes out (and who knows what
>> problems that might fix and/or introduce)
>>
>> cheers
>> Miller
>>
>>
>> ___
>> Pd-dev mailing list
>> Pd-dev@lists.iem.at<mailto:Pd-dev@lists.iem.at>
>> https://lists.puredata.info/listinfo/pd-dev
>>
>>

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] cross-compiling linus-to-windows 64 bit using automake

[Lucas Cordiviola]

@ Miller:

Can you try deleting this 32bit files from your pd/bin (from your tk/tcl 
8.6.8 test).

pthreadVC.lib
msvcr90.dll
msvcrt.dll
pthreadVC.dll

it could be that "msvcrt.dll" is making troubles to Wine.

I'm not sure why is not the case with wish85 builds. :/


--

Mensaje telepatico asistido por maquinas.

On 2/19/2018 9:04 PM, Lucas Cordiviola wrote:
>> I guess it's working fine for you - and I guess you're compiling it
>> on windows (not cross-compiling form linux, correct)?
> Yes.
>
>> I should have mentioned that not only do I get garbage but also it
>> doesn't work in the first place (no GUI appears) when I compile it.
> Very strange.
>
> If you could do it with "wish85.exe 64 bit", why not with 86?
>
> I leave this for the experts.
>
> :)
>
> Mensaje telepatico asistido por maquinas.
>
> On 2/19/2018 8:15 PM, Miller Puckette wrote:
>> I guess it's working fine for you - and I guess you're compiling it
>> on windows (not cross-compiling form linux, correct)?
>>
>> I should have mentioned that not only do I get garbage but also it
>> doesn't work in the first place (no GUI appears) when I compile it.
>>
>> cheers
>> Miller
>>
>> On Mon, Feb 19, 2018 at 10:23:42PM +, Lucas Cordiviola wrote:
>>> It all builds fine and I'm able to run wish86.exe all right; but when I try
>>> to test it as in:
>>>
>>> wine pd-0.48-1test2-ia64/bin/wish86.exe 
>>> `pwd`/pd-0.48-1test2-ia64/tcl/pd-gui.tcl
>>>
>>> I get signs of memory corruption that I haven't been able to track down (my
>>> debugging statements in pd-gui.tcl generate binary garbage).  This seems to
>>> be an interaction between wine and tcl/tk and is almost certainly too deep
>>> for me to figure out.
>>>
>>>
>>> I have a Windows MinGW64 build using "wish86.exe" (64-bit) --> 
>>> http://lucarda.com.ar/x/Pd-0.48-1-all-w64.zip
>>>
>>> What do I have to type in the cmd to test if i get "binary garbage"?
>>>
>>> Note: building on Windows with Msys2 I get the correct 64bit 
>>> "libwinpthread-1.dll" copied to pd/bin.
>>>
>>>
>>> --
>>>
>>> Mensaje telepatico asistido por maquinas.
>>>
>>> On 2/19/2018 6:42 PM, Miller Puckette wrote:
>>>
>>> I'm able to sucessfuilly cross-compile 64-bit windows targets from linux
>>> now, albeit a bit shakily.  Here's what I've found so far:
>>>
>>> 'libtool' has a library dependency, -lmsvcrt , which breaks compilation.  It
>>> works just to delete it.
>>>
>>> Somehow a 32-bit version of libwinpthread-1.dll gets installed - I have to
>>> manually replace it with a 64-bit one.
>>>
>>> and... try as I might I still can't get it working with tcl/tk 8.6 - I have 
>>> to
>>> yse 8.5.  More on that later.
>>>
>>> My compilation steps currently look like this (after making a clean 
>>> directory
>>> to put it in, /home/msp/bis/work/pd-versions/build-dirs/test85):
>>>
>>> v=0.48-1test3-ia64
>>> tkversion=8.5.19
>>> s=/home/msp/tmp/clean-pd-source
>>>
>>> git clone ~/pd $s
>>> cd $s
>>> ./autogen.sh
>>> cd /home/msp/bis/work/pd-versions/build-dirs/test85
>>> $s/configure --host=x86_64-w64-mingw32 CPPFLAGS='-DPD_LONGINTTYPE=__int64'
>>> sed -i '/-lmsvcrt/s/-lmsvcrt//g' libtool
>>> make
>>> cd msw
>>> cp -a /home/msp/bis/work/pd-versions/build-tk-on-win64/msw/tcltk-$tkversion 
>>> .
>>> /home/msp/bis/work/pd-versions/build-tk-on-win64/msw/msw-app.sh \
>>>  --builddir ..  --tk tcltk-$tkversion $v
>>> cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libwinpthread-1.dll \
>>>  pd-$v/bin/
>>>
>>> (note: I make the clone of the Pd source so I don't have to run automake in 
>>> my
>>> 'clean' source tree).
>>>
>>> When I try this for 8.6.8 I change the configuration line as follws:
>>> $s/configure --host=x86_64-w64-mingw32 \
>>>   --with-wish=wish86.exe \
>>>   CPPFLAGS='-DPD_LONGINTTYPE=__int64 -DWISH=\"wish86.exe\"'
>>>
>>> It all builds fine and I'm able to run wish86.exe all right; but when I try
>>> to test it as in:
>>>
>>> wine pd-0.48-1test2-ia64/bin/wish86.exe 
>>> `pwd`/pd-0.48-1test2-ia64/tcl/pd-gui.tcl
>>>
>>> I get signs of memory corruption that I haven't been able to track down (my
>>> debugging statements in pd-gui.tcl generate binary garbage).  This seems to
>>> be an interaction between wine and tcl/tk and is almost certainly too deep
>>> for me to figure out.
>>>
>>> This doesn't seem to be a fatal problem though - if my "test" 64-bit build 
>>> works
>>> OK I can live with that for at least until 8.7 comes out (and who knows what
>>> problems that might fix and/or introduce)
>>>
>>> cheers
>>> Miller
>>>
>>>
>>> ___
>>> Pd-dev mailing list
>>> Pd-dev@lists.iem.at<mailto:Pd-dev@lists.iem.at>
>>> https://lists.puredata.info/listinfo/pd-dev
>>>
>>>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] osx -stdlib path

[Lucas Cordiviola]

I'm not sure but -lib might also work on linux.

Mensaje telepatico asistido por maquinas.

On 2/21/2018 2:39 PM, Alex wrote:
[declare -lib jit_expr] worked on my osx machine.

On Wed, Feb 21, 2018 at 9:27 AM, Lucas Cordiviola 
<lucard...@hotmail.com<mailto:lucard...@hotmail.com>> wrote:

Can you try on you osx [declare -lib jit_expr] or [declare -lib 
full/path/to/jit_expr]?

I'm not sure if -stdlib is currently covering the .../documents/pd/externals/* 
on all platforms.

see https://puredata.info/docs/faq/how-do-i-install-externals-and-help-files 
for the paths that -stdlib covers.

there's a discussion here : https://github.com/pure-data/pure-data/pull/205

---

I think there will be no name clashes if you keep your [jit_expr] naming. If 
you use [expr] it will clash with Pd's [expr].



--

Mensaje telepatico asistido por maquinas.

On 2/21/2018 1:50 PM, Alex wrote:
I have an external I've created that I've put into: 
/Users/alex/Documents/Pd/externals/jit_expr/
the binary is called "jit_expr.pd_darwin"

xnor-work:~/projects/perfect/center$ ls 
/Users/alex/Documents/Pd/externals/jit_expr/
LICENSE-parser LICENSE-pd LICENSE-xnor   jit_expr-help.pd   
jit_expr.pd_darwin

In the binary, the externals themselves are named "jit/expr" "jit/expr~" and 
"jit/fexpr~"

On my work, osX machine, when I [declare -stdlib jit_expr] I then fail to 
create [jit/expr]
On my home, linux machine, where my external folder is located at 
/home/alex/.local/lib/pd/externals/jit_expr and appropriately named 
jit_expr.pd_linux
I succeed to create [jit/expr] after [declare -stdlib jit_expr]

Is this a bug am I not following some naming convention that I should be?

I could see wanting to put my external in a folder called "jit" and then naming 
them "expr", "expr~" etc but I could imagine "jit" is more likely to collide 
and so "jit_expr" seemed more reasonable.
maybe I should just call the whole thing "jit_expr", and just call the objects 
"expr" etc without the prefix in the code and then be able to create 
[jit_expr/expr] with no declare because it'll be in the stdlib already?
Am I confusing conventions that exist for single binary libraries with multiple 
objects and binaries with only one?

Either way, should I file a bug that the behavior isn't the same on osx and 
linux?

thanks,
Alex



___
Pd-dev mailing list
Pd-dev@lists.iem.at<mailto:Pd-dev@lists.iem.at>
https://lists.puredata.info/listinfo/pd-dev




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] osx -stdlib path

[Lucas Cordiviola]

Can you try on you osx [declare -lib jit_expr] or [declare -lib 
full/path/to/jit_expr]?

I'm not sure if -stdlib is currently covering the .../documents/pd/externals/* 
on all platforms.

see https://puredata.info/docs/faq/how-do-i-install-externals-and-help-files 
for the paths that -stdlib covers.

there's a discussion here : https://github.com/pure-data/pure-data/pull/205

---

I think there will be no name clashes if you keep your [jit_expr] naming. If 
you use [expr] it will clash with Pd's [expr].



--

Mensaje telepatico asistido por maquinas.

On 2/21/2018 1:50 PM, Alex wrote:
I have an external I've created that I've put into: 
/Users/alex/Documents/Pd/externals/jit_expr/
the binary is called "jit_expr.pd_darwin"

xnor-work:~/projects/perfect/center$ ls 
/Users/alex/Documents/Pd/externals/jit_expr/
LICENSE-parser LICENSE-pd LICENSE-xnor   jit_expr-help.pd   
jit_expr.pd_darwin

In the binary, the externals themselves are named "jit/expr" "jit/expr~" and 
"jit/fexpr~"

On my work, osX machine, when I [declare -stdlib jit_expr] I then fail to 
create [jit/expr]
On my home, linux machine, where my external folder is located at 
/home/alex/.local/lib/pd/externals/jit_expr and appropriately named 
jit_expr.pd_linux
I succeed to create [jit/expr] after [declare -stdlib jit_expr]

Is this a bug am I not following some naming convention that I should be?

I could see wanting to put my external in a folder called "jit" and then naming 
them "expr", "expr~" etc but I could imagine "jit" is more likely to collide 
and so "jit_expr" seemed more reasonable.
maybe I should just call the whole thing "jit_expr", and just call the objects 
"expr" etc without the prefix in the code and then be able to create 
[jit_expr/expr] with no declare because it'll be in the stdlib already?
Am I confusing conventions that exist for single binary libraries with multiple 
objects and binaries with only one?

Either way, should I file a bug that the behavior isn't the same on osx and 
linux?

thanks,
Alex



___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Bug when saving the patch with Pd 0.48-1

[Lucas Cordiviola]

Can't reproduce the bug on Windows. (Tk 8.5.10 32bit), (Tk 8.5.19 64bit) and 
(Tk 8.6.8 64bit)

ctl+s on-focus @ [array define x] or @ menu/put/array on focus.


--

Mensaje telepatico asistido por maquinas.

On 2/21/2018 4:38 PM, Pierre Guillot wrote:
Hi,

I don't know if anybody already encountered this bug. If the focus is on the 
window of an array object (displayed by clicking on the object) and you save 
the patch (via the menu or via cmd+s), the patch closes instantly after.
On MacOS 10.13.3 with Pd 0.48-1 - Tk 8.6.6 and Tk 8.5.19

PS: The problem doesn't occur with the text object so I guess it could be 
solved.
PPS: I'll create a PR on Github but I prefer to be sure that's not a known 
problem that I missed.

Cheers,
Pierre



___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] osx -stdlib path

[Lucas Cordiviola]

On 2/21/2018 2:47 PM, Alex wrote:
> Considering this should be a drop in replacement for the expr family, 
> a clash wouldn't actually be problematic if we can define which one is 
> preferred, though I'm not sure if that is possible so maybe I'll just 
> stick with the "jit" prefix.

Please try to avoid name clash. Once you prefer one you can't get the other.


--

Mensaje telepatico asistido por maquinas.


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] cross-compiling linus-to-windows 64 bit using automake

[Lucas Cordiviola]

It all builds fine and I'm able to run wish86.exe all right; but when I try
to test it as in:

wine pd-0.48-1test2-ia64/bin/wish86.exe `pwd`/pd-0.48-1test2-ia64/tcl/pd-gui.tcl

I get signs of memory corruption that I haven't been able to track down (my
debugging statements in pd-gui.tcl generate binary garbage).  This seems to
be an interaction between wine and tcl/tk and is almost certainly too deep
for me to figure out.


I have a Windows MinGW64 build using "wish86.exe" (64-bit) --> 
http://lucarda.com.ar/x/Pd-0.48-1-all-w64.zip

What do I have to type in the cmd to test if i get "binary garbage"?

Note: building on Windows with Msys2 I get the correct 64bit 
"libwinpthread-1.dll" copied to pd/bin.


--

Mensaje telepatico asistido por maquinas.

On 2/19/2018 6:42 PM, Miller Puckette wrote:

I'm able to sucessfuilly cross-compile 64-bit windows targets from linux
now, albeit a bit shakily.  Here's what I've found so far:

'libtool' has a library dependency, -lmsvcrt , which breaks compilation.  It
works just to delete it.

Somehow a 32-bit version of libwinpthread-1.dll gets installed - I have to
manually replace it with a 64-bit one.

and... try as I might I still can't get it working with tcl/tk 8.6 - I have to
yse 8.5.  More on that later.

My compilation steps currently look like this (after making a clean directory
to put it in, /home/msp/bis/work/pd-versions/build-dirs/test85):

v=0.48-1test3-ia64
tkversion=8.5.19
s=/home/msp/tmp/clean-pd-source

git clone ~/pd $s
cd $s
./autogen.sh
cd /home/msp/bis/work/pd-versions/build-dirs/test85
$s/configure --host=x86_64-w64-mingw32 CPPFLAGS='-DPD_LONGINTTYPE=__int64'
sed -i '/-lmsvcrt/s/-lmsvcrt//g' libtool
make
cd msw
cp -a /home/msp/bis/work/pd-versions/build-tk-on-win64/msw/tcltk-$tkversion .
/home/msp/bis/work/pd-versions/build-tk-on-win64/msw/msw-app.sh \
   --builddir ..  --tk tcltk-$tkversion $v
cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libwinpthread-1.dll \
   pd-$v/bin/

(note: I make the clone of the Pd source so I don't have to run automake in my
'clean' source tree).

When I try this for 8.6.8 I change the configuration line as follws:
$s/configure --host=x86_64-w64-mingw32 \
--with-wish=wish86.exe \
CPPFLAGS='-DPD_LONGINTTYPE=__int64 -DWISH=\"wish86.exe\"'

It all builds fine and I'm able to run wish86.exe all right; but when I try
to test it as in:

wine pd-0.48-1test2-ia64/bin/wish86.exe `pwd`/pd-0.48-1test2-ia64/tcl/pd-gui.tcl

I get signs of memory corruption that I haven't been able to track down (my
debugging statements in pd-gui.tcl generate binary garbage).  This seems to
be an interaction between wine and tcl/tk and is almost certainly too deep
for me to figure out.

This doesn't seem to be a fatal problem though - if my "test" 64-bit build works
OK I can live with that for at least until 8.7 comes out (and who knows what
problems that might fix and/or introduce)

cheers
Miller


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Current GIT master builds are unable to load Gem on Windows

[Lucas Cordiviola]

I did some tests and research:

This has changed since 0.48.1:

https://github.com/pure-data/pure-data/commit/fee700b3b35caddab2ab4a48a726a6cdbf78e0ce#diff-98b033bba3f6874800b909fd8d6d97b2

For some unknown reason Gem.dll fails to load but other old dlls loads fine.

So I tried to compile Gem to see what happened. It turned that my compiled 
Gem.dll loads fine on my compiled >0.48.1 Pd.


To compile gem I use the current git master branch and did on Msys2:

./autogen.sh
./configure --with-pd=C:/pd-sources/32 
--prefix=E:/win10onexthd/gem-test/Gem-master/out-luc --without-ftgl


I get:

*

Result:
  Target : Gem.dll
  Objects:
  default window : gemw32window

Configuration:
  Compiler   : g++
  CXXFLAGS   : -g -O2 -freg-struct-return -mms-bitfields -O3 
-falign-loops -falign-functions -falign-jumps -funroll-loops -ffast-math -mmmx
 :
  DEFINES:

  LIBS   : -lgdi32 -lws2_32 -lmsvcrt -lz -lm
 : -lvfw32
  LDFLAGS:
 :

  Install path   : E:/win10onexthd/gem-test/Gem-master/out-luc

 RTE (Pure Data):
  external-extension : dll
  CFLAGS : -DPD -IC:/pd-sources/32/src
  LIBS   : -LC:/pd-sources/32/bin -Xlinker -l:pd.dll

 used optional libraries:

  font-rendering :
 default font:

  image-support
use ImageMagick  : no
use QuickTime: no
use AVFoundation : no
use TIFF : no
use JPEG : no
  moviefile-support
use PLUGINS  : yes
use mpeg : no
use mpeg-3   : no
use QuickTime: no
use AVFoundation :
use aviplay  : no
use gmerlin  : no
  capture-support
use PLUGINS  : yes
use v4l  : no
use v4l2 : no
use ieee1394 : no
use DV   : no
use Unicap   : yes
use Video-for-WinDOS : yes
use QuickTime: no
use AVFoundation : no

*

It took 2hs to compile and Gem.dll is 81.9 MB

I copied "libwinpthread-1.dll" & "libstdc++-6.dll" from the compiler to the Gem 
folder.

Gem loads but can't create the [gemwin].



--

Mensaje telepatico asistido por maquinas.

On 3/20/2018 5:50 AM, IOhannes m zmoelnig wrote:

On 2018-03-20 05:48, Lucas Cordiviola wrote:



Oliver and I did some tests on compiling Pd for windows.

We found that the current master branch can't load Gem.

We can load it with Miller's build or with self builds from
"pure-data-mingw-autotools2" branch from January ‎9, ‎2018.

We are sure this is not an "msvcr71.dll" issue or a "-lib" issue.

We get:

C:\\Users\\Lucarda\\Documents\\Pd\\externals\\gem\\gem.dll: couldn't load




ouch.
good catch.
do you have the failing binaries available?

since i'm not a w32 guy, any help is much appreciated.

fgmasdr
IOhannes





___
Pd-dev mailing list
Pd-dev@lists.iem.at<mailto:Pd-dev@lists.iem.at>
https://lists.puredata.info/listinfo/pd-dev


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Current GIT master builds are unable to load Gem on Windows

[Lucas Cordiviola]

I'm starting pd with

pd -noprefs -font 12 -path C:\Users\Lucarda\Documents\Pd\externals\Gem 
-lib Gem

I get the warning in the console:


***

GEM: Graphics Environment for Multimedia
GEM: ver: 0.93.
GEM: compiled  on Mar 24 2018
GEM: maintained by IOhannes m zmoelnig
GEM: Authors :    Mark Danks (original version)
GEM:        Chris Clepper
GEM:        Cyrille Henry
GEM:        IOhannes m zmoelnig
GEM: with help by Guenter Geiger, Daniel Heckenberg, James Tittle, 
Hans-Christoph Steiner, et al.
GEM: found a bug? miss a feature? please report it:
GEM:     homepage https://gem.iem.at/
GEM:     bug-tracker https://bugs.gem.iem.at/
GEM:     mailing-list https://lists.puredata.info/listinfo/gem-dev/


---> GEM: please manually add Gem path 
'C:/Users/Lucarda/Documents/Pd/externals/Gem' to Pd's search path


GEM: compiled for MMX architecture
GEM: using MMX optimization
GEM: detected 4 CPUs
GEM: image loading support: SGI
GEM: image saving support: SGI


***

But when I go to add it is already there because of the  "-path 
C:\Users\Lucarda\Documents\Pd\externals\Gem"

On the mail below there is output from the config:

default window : gemw32window



--

Mensaje telepatico asistido por maquinas.

On 3/25/2018 8:29 PM, Christof Ressi wrote:
> did you add GEM to your path? in recent GEM, [gemwin] is an abstraction.
>   
>
> Gesendet: Montag, 26. März 2018 um 00:55 Uhr
> Von: "Lucas Cordiviola" <lucard...@hotmail.com>
> An: "IOhannes m zmoelnig" <zmoel...@iem.at>, "pd-dev@lists.iem.at" 
> <pd-dev@lists.iem.at>
> Betreff: Re: [PD-dev] Current GIT master builds are unable to load Gem on 
> Windows
>
> I did some tests and research:
>
> This has changed since 0.48.1:
>
> https://github.com/pure-data/pure-data/commit/fee700b3b35caddab2ab4a48a726a6cdbf78e0ce#diff-98b033bba3f6874800b909fd8d6d97b2
>
> For some unknown reason Gem.dll fails to load but other old dlls loads fine.
>
> So I tried to compile Gem to see what happened. It turned that my compiled 
> Gem.dll loads fine on my compiled >0.48.1 Pd.
>
>
> To compile gem I use the current git master branch and did on Msys2:
>
> ./autogen.sh
> ./configure --with-pd=C:/pd-sources/32 
> --prefix=E:/win10onexthd/gem-test/Gem-master/out-luc --without-ftgl
>
>
> I get:
>
> *
>
> Result:
>    Target : Gem.dll
>    Objects    :
>    default window : gemw32window
>
> Configuration:
>    Compiler   : g++
>    CXXFLAGS   : -g -O2 -freg-struct-return -mms-bitfields -O3 
> -falign-loops -falign-functions -falign-jumps -funroll-loops -ffast-math -mmmx
>   :
>    DEFINES    :
>
>    LIBS   : -lgdi32 -lws2_32 -lmsvcrt -lz -lm
>   : -lvfw32
>    LDFLAGS    :
>   :
>
>    Install path   : E:/win10onexthd/gem-test/Gem-master/out-luc
>
>   RTE (Pure Data):
>    external-extension : dll
>    CFLAGS : -DPD -IC:/pd-sources/32/src
>    LIBS   : -LC:/pd-sources/32/bin -Xlinker -l:pd.dll
>
>   used optional libraries:
>
>    font-rendering :
>   default font    :
>
>    image-support
>      use ImageMagick  : no
>      use QuickTime    : no
>      use AVFoundation : no
>      use TIFF : no
>      use JPEG : no
>    moviefile-support
>      use PLUGINS  : yes
>      use mpeg : no
>      use mpeg-3   : no
>      use QuickTime    : no
>      use AVFoundation :
>      use aviplay  : no
>      use gmerlin  : no
>    capture-support
>      use PLUGINS  : yes
>      use v4l  : no
>      use v4l2 : no
>      use ieee1394 : no
>      use DV   : no
>      use Unicap   : yes
>      use Video-for-WinDOS : yes
>      use QuickTime    : no
>      use AVFoundation : no
> 
> *****
>
> It took 2hs to compile and Gem.dll is 81.9 MB
>
> I copied "libwinpthread-1.dll" & "libstdc++-6.dll" from the compiler to the 
> Gem folder.
>
> Gem loads but can't create the [gemwin].
>   
>   
> --
> Mensaje telepatico asistido por maquinas.
>
> On 3/20/2018 5:50 AM, IOhannes m zmoelnig wrote:
> On 2018-03-20 05:48, Lucas Cordiviola wrote:
> Oliver and I did some tests on compiling Pd for windows.
>
> We found that the current master branch can't load Gem.
>
> We can load it with Mi

Re: [PD-dev] Current GIT master builds are unable to load Gem on Windows

[Lucas Cordiviola]

@Christof

For some reason I didn't had the gemwin.pd. I copied it and now it works.

:)

Mensaje telepatico asistido por maquinas.

On 3/25/2018 8:59 PM, Lucas Cordiviola wrote:
> I'm starting pd with
>
> pd -noprefs -font 12 -path C:\Users\Lucarda\Documents\Pd\externals\Gem
> -lib Gem
>
> I get the warning in the console:
>
>
> ***
>
> GEM: Graphics Environment for Multimedia
> GEM: ver: 0.93.
> GEM: compiled  on Mar 24 2018
> GEM: maintained by IOhannes m zmoelnig
> GEM: Authors :    Mark Danks (original version)
> GEM:        Chris Clepper
> GEM:        Cyrille Henry
> GEM:        IOhannes m zmoelnig
> GEM: with help by Guenter Geiger, Daniel Heckenberg, James Tittle,
> Hans-Christoph Steiner, et al.
> GEM: found a bug? miss a feature? please report it:
> GEM:     homepage https://gem.iem.at/
> GEM:     bug-tracker https://bugs.gem.iem.at/
> GEM:     mailing-list https://lists.puredata.info/listinfo/gem-dev/
>
>
> ---> GEM: please manually add Gem path
> 'C:/Users/Lucarda/Documents/Pd/externals/Gem' to Pd's search path
>
>
> GEM: compiled for MMX architecture
> GEM: using MMX optimization
> GEM: detected 4 CPUs
> GEM: image loading support: SGI
> GEM: image saving support: SGI
>
>
> ***
>
> But when I go to add it is already there because of the  "-path
> C:\Users\Lucarda\Documents\Pd\externals\Gem"
>
> On the mail below there is output from the config:
>
> default window : gemw32window
>
>
>
> --
>
> Mensaje telepatico asistido por maquinas.
>
> On 3/25/2018 8:29 PM, Christof Ressi wrote:
>> did you add GEM to your path? in recent GEM, [gemwin] is an abstraction.
>>
>>
>> Gesendet: Montag, 26. März 2018 um 00:55 Uhr
>> Von: "Lucas Cordiviola" <lucard...@hotmail.com>
>> An: "IOhannes m zmoelnig" <zmoel...@iem.at>, "pd-dev@lists.iem.at" 
>> <pd-dev@lists.iem.at>
>> Betreff: Re: [PD-dev] Current GIT master builds are unable to load Gem on 
>> Windows
>>
>> I did some tests and research:
>>
>> This has changed since 0.48.1:
>>
>> https://github.com/pure-data/pure-data/commit/fee700b3b35caddab2ab4a48a726a6cdbf78e0ce#diff-98b033bba3f6874800b909fd8d6d97b2
>>
>> For some unknown reason Gem.dll fails to load but other old dlls loads fine.
>>
>> So I tried to compile Gem to see what happened. It turned that my compiled 
>> Gem.dll loads fine on my compiled >0.48.1 Pd.
>>
>>
>> To compile gem I use the current git master branch and did on Msys2:
>>
>> ./autogen.sh
>> ./configure --with-pd=C:/pd-sources/32 
>> --prefix=E:/win10onexthd/gem-test/Gem-master/out-luc --without-ftgl
>>
>>
>> I get:
>>
>> *
>>
>> Result:
>>     Target : Gem.dll
>>     Objects    :
>>     default window : gemw32window
>>
>> Configuration:
>>     Compiler   : g++
>>     CXXFLAGS   : -g -O2 -freg-struct-return -mms-bitfields -O3 
>> -falign-loops -falign-functions -falign-jumps -funroll-loops -ffast-math 
>> -mmmx
>>    :
>>     DEFINES    :
>>
>>     LIBS   : -lgdi32 -lws2_32 -lmsvcrt -lz -lm
>>    : -lvfw32
>>     LDFLAGS    :
>>    :
>>
>>     Install path   : E:/win10onexthd/gem-test/Gem-master/out-luc
>>
>>    RTE (Pure Data):
>>     external-extension : dll
>>     CFLAGS : -DPD -IC:/pd-sources/32/src
>>     LIBS   : -LC:/pd-sources/32/bin -Xlinker -l:pd.dll
>>
>>    used optional libraries:
>>
>>     font-rendering :
>>    default font    :
>>
>>     image-support
>>       use ImageMagick  : no
>>       use QuickTime    : no
>>       use AVFoundation : no
>>       use TIFF : no
>>       use JPEG : no
>>     moviefile-support
>>       use PLUGINS  : yes
>>       use mpeg : no
>>       use mpeg-3   : no
>>       use QuickTime    : no
>>       use AVFoundation :
>>       use aviplay  : no
>>       use gmerlin  : no
>>     capture-support
>>       use PLUGINS  : yes
>>       use v4l  : no
>>       use v4l2 : no
>>       use ieee1394 : no
>>       use DV   : no

[PD-dev] Current GIT master builds are unable to load Gem on Windows

[Lucas Cordiviola]

Oliver and I did some tests on compiling Pd for windows.

We found that the current master branch can't load Gem.

We can load it with Miller's build or with self builds from 
"pure-data-mingw-autotools2" branch from January ‎9, ‎2018.

We are sure this is not an "msvcr71.dll" issue or a "-lib" issue.

We get:

C:\\Users\\Lucarda\\Documents\\Pd\\externals\\gem\\gem.dll: couldn't load


What could have changed in Pd code since 0.48.1 release?

PS: I can load other -lib s with no problem (cyclone, iemlib, ofelia)



Mensaje telepatico asistido por maquinas.

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Current GIT master builds are unable to load Gem on Windows

[Lucas Cordiviola]

Here --> http://lucarda.com.ar/x/Gem-not-loading-w32.zip


--

Mensaje telepatico asistido por maquinas.

On 3/20/2018 5:50 AM, IOhannes m zmoelnig wrote:

On 2018-03-20 05:48, Lucas Cordiviola wrote:



Oliver and I did some tests on compiling Pd for windows.

We found that the current master branch can't load Gem.

We can load it with Miller's build or with self builds from
"pure-data-mingw-autotools2" branch from January ‎9, ‎2018.

We are sure this is not an "msvcr71.dll" issue or a "-lib" issue.

We get:

C:\\Users\\Lucarda\\Documents\\Pd\\externals\\gem\\gem.dll: couldn't load




ouch.
good catch.
do you have the failing binaries available?

since i'm not a w32 guy, any help is much appreciated.

fgmasdr
IOhannes





___
Pd-dev mailing list
Pd-dev@lists.iem.at<mailto:Pd-dev@lists.iem.at>
https://lists.puredata.info/listinfo/pd-dev


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Current GIT master builds are unable to load Gem on Windows

[Lucas Cordiviola]

On 3/20/2018 8:56 PM, oliver wrote:

> i am definitely no developer ;-)
>
> but, yes include me and i will participate in any testing necessary ! 

Thanxs for joining Oliver!

We are not so many with a win machine/Msys2 to do tests. The more we are 
we can speed/double-check the hole thing.

If this is what i think, IOhannes will make a branch for testing. Our 
part is only to build it and try to load Gem. The same thing that you 
already did yesterday.

:)


--

Mensaje telepatico asistido por maquinas.



___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win

[Lucas Cordiviola]

> Is pdlibbuilder/mingw statically linking in its own msvcr*?
Yes. --> 
https://github.com/pure-data/pd-lib-builder/blob/master/Makefile.pdlibbuilder#L638

I guess you don't want to hear the nightmares of the C-runtimes that are 
needed to ship if compiling with MSVS. (latest VS compiled stuff running 
on windows machines without updates, etc)

:)

Mensaje telepatico asistido por maquinas.

On 1/22/2019 7:36 PM, Miller Puckette wrote:
> Would this mean that anyone shipping a binary external for Windows would
> have to put it in a separate directory with its own msvcrt.dll/msvcr90.dll?
> Sounds like a nightmare to me.
>
> I don't understand the issues yet... in particular, since pdlibbuilder uses
> mingw on Windows, how does it work with Pd if mingw and msvcr*dll aren't
> compatible?  Is pdlibbuilder/mingw statically linking in its own msvcr*?
>
> cheers
> Miller
>
> On Tue, Jan 22, 2019 at 10:51:45PM +0100, Christof Ressi wrote:
>> I agree and I've already suggested this: 
>> https://lists.puredata.info/pipermail/pd-dev/2018-09/021721.html
>>
>> BTW, I got linker errors because of msvcrt.dll when I compiled Dan's 
>> pdfontloader. this left me scratching my head for quite a while. removing 
>> the DLL solved the problem.
>> https://lists.puredata.info/pipermail/pd-dev/2018-09/021709.html
>>
>> Christof
>>
>>> Gesendet: Dienstag, 22. Januar 2019 um 22:16 Uhr
>>> Von: "IOhannes m zm??lnig" 
>>> An: "PureData developer's list" 
>>> Betreff: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
>>>
>>> hi,
>>>
>>> TL;DR: i'd like to suggest to remove the "msvcr90.dll" and " msvcrt.dll"
>>> files from the pd\bin\ folder of all (future) windows releases.
>>>
>>> rationale
>>> =
>>>
>>> # usage by Pd
>>> first of all, these files are not used by Pd at all.
>>> they are only provided as a courtesy for externals that happen to
>>> require a dyamically linked libc implementation but fail to provide one
>>> themselves.
>>> most likely this is a leftover from the days, where any dynamic
>>> dependencies of an external would only be looked up in the Pd\bin\
>>> folder (and not in the folder of the external itself), making it
>>> impossible to ship externals in a self-contained folder.
>>> luckily, these days are gone.
>>>
>>> # incompatibility
>>> for whatever reasons (personally i blame redmont, but i might be
>>> biased), "msvcrt.dll" is not a well defined library. especially it does
>>> not guarantee any binary compatibility.
>>> in practice, the "msvcrt.dll" as shipped with Pd is *incompatible* with
>>> msvcrt.dll as used by mingw when compiling. (it might also be
>>> incompatible with a file of the same name shipped with the latest
>>> release of MS Visual Studio, but i haven't checked).
>>>
>>> that means: the provided msvcrt.dll simply will not work with any
>>> mingw-compiled external.
>>> if the
>>>
>>> # compiling
>>> i noticed that i cannot compile/link externals for windows/32bit using
>>> mingw, if their build-system uses autotools/libtool.
>>>
>>> the linking stage fails in catastrophic ways, only because the linker
>>> picks up the
>>>
>>> here's an example log-file of such a failed build:
>>>https://git.iem.at/pd/Gem/-/jobs/3230
>>>
>>> 
>>> it took me a while to figure out what went wrong, because pd-lib-builder
>>> based externals compile just fine.
>>> it turned out, that the difference was that pd-lib-builder would link
>>> against "${PDPATH}\bin\pd.dll" (that is: it uses the full path as the
>>> library file to link against) whereas libtool based builds would link
>>> against "pd.dll" and add "${PDPATH\bin\" to the library search path (the
>>> actual linker flags being "-L${PDPATH}\bin\ -l:pd.dll").
>>> since explicit library search paths take precedence over built-ins,
>>> adding "-L${PDPATH}\bin\" would make the linker find the "msvcrt.dll"
>>> file in ${PDPATH}\bin\, which happens to be incompatible with mingw, and
>>> thus an error is raised.
>>> 
>>>
>>> the *only* way i found to fix the linker flag, is by removing the
>>> "msvcrt.dll" file from ${PDPATH}\bin\ before starting the build-process.
>>> in practice i also removed the "msvcr90.dll" file.
>>>
>>> incidentally, there are no problem with the w64 version of Pd, as this
>>> ships 32bit versions of "msvcr*.dll", which will be ignored by the
>>> compiler/linker/runtimelinker, because of a non-matching architecture.
>>>
>>>
>>>
>>> # conclusion
>>> afaics, there are currently **no** benefits in shipping the msvcr*.dll
>>> files.
>>> however, they do create a number of issues.
>>> (and in the case of Pd/W64 they are of the wrong architecture anyhow)
>>>
>>> i don't see a reason to keep them.
>>>
>>> fgmdsar
>>> IOhannes
>>>
>>> ___
>>> Pd-dev mailing list
>>> Pd-dev@lists.iem.at
>>> https://lists.puredata.info/listinfo/pd-dev
>>>
>>
>>
>> ___
>> Pd-dev mailing list
>> Pd-dev@lists.iem.at
>> https://lists.puredata.info/listinfo/pd-dev
>
>
> 

Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win

[Lucas Cordiviola]

I also agree.

I will try to find out if any of the old extended externals actually 
needs these dlls. Probably msvcrt.dll comes from the Msys1 era.

I'll check ASAP with the list of old externals (attached).

Mensaje telepatico asistido por maquinas.

On 1/22/2019 6:51 PM, Christof Ressi wrote:
> I agree and I've already suggested this: 
> https://lists.puredata.info/pipermail/pd-dev/2018-09/021721.html
>
> BTW, I got linker errors because of msvcrt.dll when I compiled Dan's 
> pdfontloader. this left me scratching my head for quite a while. removing the 
> DLL solved the problem.
> https://lists.puredata.info/pipermail/pd-dev/2018-09/021709.html
>
> Christof
>
>> Gesendet: Dienstag, 22. Januar 2019 um 22:16 Uhr
>> Von: "IOhannes m zmölnig" 
>> An: "PureData developer's list" 
>> Betreff: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
>>
>> hi,
>>
>> TL;DR: i'd like to suggest to remove the "msvcr90.dll" and " msvcrt.dll"
>> files from the pd\bin\ folder of all (future) windows releases.
>>
>> rationale
>> =
>>
>> # usage by Pd
>> first of all, these files are not used by Pd at all.
>> they are only provided as a courtesy for externals that happen to
>> require a dyamically linked libc implementation but fail to provide one
>> themselves.
>> most likely this is a leftover from the days, where any dynamic
>> dependencies of an external would only be looked up in the Pd\bin\
>> folder (and not in the folder of the external itself), making it
>> impossible to ship externals in a self-contained folder.
>> luckily, these days are gone.
>>
>> # incompatibility
>> for whatever reasons (personally i blame redmont, but i might be
>> biased), "msvcrt.dll" is not a well defined library. especially it does
>> not guarantee any binary compatibility.
>> in practice, the "msvcrt.dll" as shipped with Pd is *incompatible* with
>> msvcrt.dll as used by mingw when compiling. (it might also be
>> incompatible with a file of the same name shipped with the latest
>> release of MS Visual Studio, but i haven't checked).
>>
>> that means: the provided msvcrt.dll simply will not work with any
>> mingw-compiled external.
>> if the
>>
>> # compiling
>> i noticed that i cannot compile/link externals for windows/32bit using
>> mingw, if their build-system uses autotools/libtool.
>>
>> the linking stage fails in catastrophic ways, only because the linker
>> picks up the
>>
>> here's an example log-file of such a failed build:
>>https://git.iem.at/pd/Gem/-/jobs/3230
>>
>> 
>> it took me a while to figure out what went wrong, because pd-lib-builder
>> based externals compile just fine.
>> it turned out, that the difference was that pd-lib-builder would link
>> against "${PDPATH}\bin\pd.dll" (that is: it uses the full path as the
>> library file to link against) whereas libtool based builds would link
>> against "pd.dll" and add "${PDPATH\bin\" to the library search path (the
>> actual linker flags being "-L${PDPATH}\bin\ -l:pd.dll").
>> since explicit library search paths take precedence over built-ins,
>> adding "-L${PDPATH}\bin\" would make the linker find the "msvcrt.dll"
>> file in ${PDPATH}\bin\, which happens to be incompatible with mingw, and
>> thus an error is raised.
>> 
>>
>> the *only* way i found to fix the linker flag, is by removing the
>> "msvcrt.dll" file from ${PDPATH}\bin\ before starting the build-process.
>> in practice i also removed the "msvcr90.dll" file.
>>
>> incidentally, there are no problem with the w64 version of Pd, as this
>> ships 32bit versions of "msvcr*.dll", which will be ignored by the
>> compiler/linker/runtimelinker, because of a non-matching architecture.
>>
>>
>>
>> # conclusion
>> afaics, there are currently **no** benefits in shipping the msvcr*.dll
>> files.
>> however, they do create a number of issues.
>> (and in the case of Pd/W64 they are of the wrong architecture anyhow)
>>
>> i don't see a reason to keep them.
>>
>> fgmdsar
>> IOhannes
>>
>> ___
>> Pd-dev mailing list
>> Pd-dev@lists.iem.at
>> https://lists.puredata.info/listinfo/pd-dev
>>
>
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
(deken
http://puredata.info/Members/avilleret/software/Jamoma/1.0-beta3/Jamoma-v1.0-beta3-(Windows-i386-32)-externals.zip
 nottested
http://puredata.info/Members/chr15m/freeverb~(Windows-i386-32)-externals.zip ok
http://puredata.info/Members/chr15m/pdlua(Windows-i386-32)-externals.zip ok
http://puredata.info/Members/chr15m/plugin~(Windows-i386-32)-externals.zip 
libdl.dll
http://puredata.info/Members/chr15m/software/v0-0extended/adaptive/adaptive-v0.0.extended-(Windows-i386-32)-externals.zip
 ok
http://puredata.info/Members/chr15m/software/v0-0extended/arraysize/arraysize-v0.0.extended-(Windows-i386-32)-externals.zip
 ok
http://puredata.info/Members/chr15m/software/v0-0extended/bassemu~/bassemu~-v0.0.extended-(Windows-i386-32)-externals.zip
 ok

Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win

[Lucas Cordiviola]

Here's a full dependency-walker analysis of all w32 v00-extended Deken:

http://lucarda.com.ar/x/dep-walk-00extended-deken-w32-report.zip

It's one text file per .dll. We can Grep/Findstring to get results that mainly 
boils down to:

msvcr90.dll -> no match.

msvcr71.dll -> Gem and friends.

pthread ->  splits to:

PTHREADGC2.DLL --> some objects.

PTHREADVC.DLL --> Gem and friends. We must consider Oliver's discoveries on 
this: https://lists.puredata.info/pipermail/pd-list/2018-12/124086.html as 
there's something strange with this file.

As of "msvcrt.dll" I think Christof had explained everything. My tests deleting 
this file showed no trouble.

As of "msvcr90.dll" I will randomly search tomorrow on non Pd-extended-era but 
it could be the case that is not needed, ...

Here are the Pd patches I used to generate batch files for dependency-walker 
and also to serialize opening and closing *-help.pd files:

http://lucarda.com.ar/x/w32DekenPKGdepWalkCHECK1.zip

@Christof

since 2015 there are new runtime libraries, e.g. UCRTBASE.DLL and 
VCRUNTIME140.DLL 
(https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL,_MSVCP*.DLL_and_CRTDLL.DLL)


I helped Zack Lee's [ofelia] in the early stage a year ago. Basically there's 
the normal vc_redist.x86.exe but it does not work on machines that don't 
receive updates (a minority anyway) but theres is work around shipping a lot of 
dlls. :)


Mensaje telepatico asistido por maquinas.

On 1/22/2019 10:56 PM, Christof Ressi wrote:

sorry for spamming, but I think this SO question and the given answers shed 
some more light on the issue:

https://stackoverflow.com/questions/1073509/should-i-redistribute-msvcrt-dll-with-my-application

TL;DR: programs built with VS can either link statically against the MSVCRT or 
they have to install the appropiate redistributable package.
msvcrt.dll is very old and was declared a private system library which 
applications should not link against (didn't know that!), but MinGW does anyway.
You should certainly *not* redistribute msvcrt.dll.

Christof

PS: since 2015 there are new runtime libraries, e.g. UCRTBASE.DLL and 
VCRUNTIME140.DLL 
(https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL,_MSVCP*.DLL_and_CRTDLL.DLL)





Gesendet: Mittwoch, 23. Januar 2019 um 02:17 Uhr
Von: "Christof Ressi" 
An: pd-dev 
Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win

to sum it up: msvcrt.dll is always present on the system anyway, so there's no 
need to ship it with Pd. if an externals relies on msvcr90.dll in pd/bin I 
would consider this a bug.




Gesendet: Mittwoch, 23. Januar 2019 um 01:54 Uhr
Von: "Christof Ressi" 
An: "Miller Puckette" 
Cc: pd-dev@lists.iem.at
Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win

@Miller:

neither Pd nor any externals built with MinGW (basically every external using 
pd-lib-builder) depend on the msvcrt.dll (or the msvcr90.dll or pthreadVC.dll) 
included in pd/bin. externals built with pd-lib-builder don't link against the 
runtime DLLs shipped with Pd anyway. I've deleted them from the Pd bin folder 
and everything works fine on several machines.

apart from that, Pd and pure C externals (no matter if compiled with MinGW or 
VS) only use C functions from the MSVC runtime and this doesn't cause troubles 
because memory or handles don't cross module boundaries and data structures are 
well defined. e.g. you must never malloc in one module and free in another 
because there might be different runtimes involved.

C++ externals compiled with MinGW usually link statically against libstdc++ (or 
ship the DLL) so there are no missing symbols. C++ externals compiled with VS 
would ideally link statically (see below), but they should *not* rely on a 
runtime DLL shipped with Pd. if they do, I would reach out to the maintainer or 
recompile and upload to Deken. so I would say let's get rid of the runtime DLLs 
in pd/bin.

@IOhannes:



On 1/22/19 11:36 PM, Miller Puckette wrote:


Would this mean that anyone shipping a binary external for Windows would
have to put it in a separate directory with its own msvcrt.dll/msvcr90.dll?
Sounds like a nightmare to me.



but i think that's really the only sane way.
unless you can guarantee that Pd and all externals are built with the
same compiler.



or they can link statically. This is what most VST plugins seem to do. 
Dependency Walker doesn't show any open dependencies on MSVC runtime libraries 
on the plugins I've checked. They obviously coexist peacefully in DAWs although 
they might be from different decades and are mostly written in C++.



afaict, Gem really requires to link against msvcrt.



using Dependency Walker on the recent Gem 0.94 I see that it only uses C 
symbols from the MSVC, like any other plugin compiled with MinGW, so I don't 
see a problem here. the C++ symbols 

[PD-dev] Windows 64bit installer was: (PD 0.49-0test1 released)

[Lucas Cordiviola]

Moving this to the dev list:

Yes the w64 installer defaults to 'Program Files (x86)' instead of 
'Program Files' . This makes a mess if a user wants to install both an 
32pd & an 64pd.

2 different nsis scripts can be made and both installations are 
possible(1) but they both share the same “windows registry” which is 
rather dirty.

It is also possible to advise the user not to have more than 1 
installation with some message when the installer is run, like:

“Please uninstall any previous installation and don't attempt to have 
32bit-Pd and 64bit-Pd installed on the same machine/user”


There's some time to think what to do.

:)

(1) different app names (pure data 32 bit, pure data 64 bit) different 
start-menu entries and other stuff.

--

Mensaje telepatico asistido por maquinas.

On 9/14/2018 1:00 PM, Max wrote:
> Also I'm hearing the 64bit win installer puts the program in 'Program 
> Files (x86)' instead of 'Program Files'.
>
> m.
>
>

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win

[Lucas Cordiviola]

> $ deken find --arch "Windows-*-*" | sed -n -e 's|^.*\bURL:
> \(.*(Windows-.*\)|\1|p' | sort -u
>
> gives me the attached list (including those you already scanned).

I found missing pkgs from your list but I got a complete one using deken 
(cancelling a download a binking prompt appears on the deken's windows 
results so I use SHIFT+arrows ).

I've scanned all w32-deken (attached list) and "msvcr90.dll" hits only 
"soundhack-v0.0.8"

I've crated a page on puredata.info containing the full scanned output :

http://puredata.info/Members/lucarda/w32-dep-wak-deken-2019/


:)


Mensaje telepatico asistido por maquinas.


zexy[v2.2.8](Windows-i386-32).dek
Uploaded by zmoelnigbot @ 2018-10-02 21:32:29

zexy-v2.2.6svn-20150529iem-(Windows-i386-32)-externals.zip
Uploaded by zmoelnig @ 2016-08-30 14:52:55

zexy-v0.0.extended-(Windows-i386-32)-externals.zip
Uploaded by chr15m @ 2015-07-30 15:27:35

windowing-v0.2.0-(Windows-i386-32)(Sources)-externals.zip
Uploaded by fjkraan @ 2016-07-03 16:45:01

windowing-v0.1.1-20150529iem-(Windows-i386-32)-externals.zip
Uploaded by zmoelnig @ 2016-08-30 14:51:59

windowing-v0.0.extended-(Windows-i386-32)-externals.zip
Uploaded by chr15m @ 2015-07-30 14:51:45

vstplugin~[v0.1-alpha](Windows-i386-32).dek
Uploaded by spacechild1 @ 2018-11-29 14:38:18

vbap-v0.0.extended-(Windows-i386-32)-externals.zip
Uploaded by chr15m @ 2015-07-30 14:55:38

unauthorized-v0.0.extended-(Windows-i386-32)-externals.zip
Uploaded by chr15m @ 2015-07-30 15:38:48

triggerize-plugin[v0.2.2](Darwin-amd64-32)(Darwin-i386-32)(Linux-amd64-32)(Windows-amd64-32)(Windows-i386-32).dek
Uploaded by zmoelnigbot @ 2018-10-01 21:37:36

tof-v0.2.1-(Windows-i386-32)(Sources)-externals.zip
Uploaded by fjkraan @ 2016-11-02 20:10:05

tof-v0.0.extended-(Windows-i386-32)-externals.zip
Uploaded by chr15m @ 2015-07-30 15:11:18

timbreID[v0.7.8](Windows-i386-32).dek
Uploaded by wmbrent @ 2018-08-23 21:46:25

tclpd-v0.0.extended-(Windows-i386-32)-externals.zip
Uploaded by chr15m @ 2015-07-30 15:22:38

swe~-v0.7-(Sources)(Windows-i386-32)-externals.zip
Uploaded by jwmatthys @ 2017-11-17 08:57:43

soundhack-v0.0.8-(Windows-i386-32)-externals.zip
Uploaded by porres @ 2017-06-21 08:09:46

smlib-v0.12.3-(Windows-i386-32)(Sources)-externals.zip
Uploaded by fjkraan @ 2016-09-16 11:02:43

smlib-v0.0.extended-(Windows-i386-32)-externals.zip
Uploaded by chr15m @ 2015-07-30 14:59:22

slip-v0.1~git20151117-(Windows-i386-32)-externals.zip
Uploaded by rdz @ 2015-11-18 13:39:18

sigpack-v0.044-(Windows-i386-32)(Sources)-externals.zip
Uploaded by fjkraan @ 2016-05-06 15:50:10

sigpack-v0.0.extended-(Windows-i386-32)-externals.zip
Uploaded by chr15m @ 2015-07-30 14:54:58

shotnoise-v0.9.1--externals.zip
Uploaded by saturno @ 2016-07-30 23:50:41

saturator-v0.3.5-(Darwin-i386-32)(Sources)(Darwin-x86_64-32)(Linux-amd64-64)(Windows-i386-32)-externals.zip
Uploaded by saturno @ 2016-07-30 20:36:43

readdir-v0.03~git20151116-(Windows-i386-32)-externals.zip
Uploaded by rdz @ 2015-11-18 13:36:26

purest_json-v1.4.2-(Windows-i386-32)-externals.zip
Uploaded by residuum @ 2017-01-03 14:00:48

purest_json-v1.4.1-(Windows-i386-32)-externals.zip
Uploaded by residuum @ 2018-04-23 23:34:11

purest_json-v1.4.0-(Windows-i386-32)-externals.zip
Uploaded by residuum @ 2016-01-10 03:03:23

pmpd-v0.0.extended-(Windows-i386-32)-externals.zip
Uploaded by chr15m @ 2015-07-30 15:35:33

plugin~-v0.0.extended-(Windows-i386-32)-externals.zip
Uploaded by chr15m @ 2015-07-30 15:05:18

pix_mano-v0.0.extended-(Windows-i386-32)-externals.zip
Uploaded by chr15m @ 2015-07-30 15:40:06

pix_fiducialtrack-v0.0.extended-(Windows-i386-32)-externals.zip
Uploaded by chr15m @ 2015-07-30 14:53:40

pix_drum-v0.0.extended-(Windows-i386-32)-externals.zip
Uploaded by chr15m @ 2015-07-30 15:20:27

pix_artoolkit-v0.0.extended--externals.zip
Uploaded by chr15m @ 2015-08-07 15:06:46

pix_artoolkit-v0.0.extended-(Windows-i386-32)-externals.zip
Uploaded by chr15m @ 2015-07-30 15:36:53

pdogg-v0.0.extended-(Windows-i386-32)-externals.zip
Uploaded by chr15m @ 2015-07-30 15:41:38

pdlua-v0.0.extended-(Windows-i386-32)-externals.zip
Uploaded by chr15m @ 2015-07-30 15:31:42

pddp-v0.0.extended-(Windows-i386-32)-externals.zip
Uploaded by chr15m @ 2015-07-30 15:16:30

pdcontainer-v0.0.extended-(Windows-i386-32)-externals.zip
Uploaded by chr15m @ 2015-07-30 15:00:39

patcherize-plugin[v0.2.2](Darwin-amd64-32)(Darwin-i386-32)(Linux-amd64-32)(Windows-amd64-32)(Windows-i386-32).dek
Uploaded by zmoelnigbot @ 2018-10-01 21:37:12

ossia-vv1.0.1-(Windows-i386-32)-externals.zip
Uploaded by ossia @ 2018-09-13 12:27:01

oscx-v0.0.extended-(Windows-i386-32)-externals.zip
Uploaded by chr15m @ 

Re: [PD-dev] local canvas-only pd_bind

[Lucas Cordiviola]

[cyclone/mousestate] is very raw compared to [mousepad]. You can have one or 
more [cyclone/mousestate] and they all will just output the same xy coords for 
the screen (not the patch).

Probably is very easy for [mousepad] to incorporate an option like "global 
sender" to give the same functionality as [cyclone/mousestate].

[mousepad] is totally cool.

:)

Mensaje telepatico asistido por maquinas.

On 3/21/2019 5:30 AM, Alexandre Torres Porres wrote:
I love the idea of a native 2d slider, but how about providing the same 
functionality from [cyclone/mousestate]?

Em qui, 21 de mar de 2019 às 01:47, Chris McCormick 
mailto:ch...@mccormick.cx>> escreveu:
On 19/3/19 11:17 pm, katja wrote:
> Mousepad code is up for inspection at:
>
> https://github.com/katjav/pd-mouse-trial
This is great!

Cheers,

Chris.

--
https://mccormick.cx/

My tech development newsletter:
https://mccormick.cx/subscribe



___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev



___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] local canvas-only pd_bind

[Lucas Cordiviola]

On 3/21/2019 6:18 AM, Lucas Cordiviola wrote:

> You can have one or more [cyclone/mousestate] and they all will just 
> output the same xy coords for the screen (not the patch).

I meant many [mousestate] in different opened patches.


Mensaje telepatico asistido por maquinas.



___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] libpd search paths

[Lucas Cordiviola]

there are a couple of things you can try with your [external] or with 
one that you are sure that works with your arch {1} as Giulio mentioned:

1)

create a folder "jl" on the same dir as "main.pd"

put an abstraction on "jl" folder.

On "main.pd" call the abstraction with [jl/your-abs]

If the abstraction is loaded place your [external] in the "jl" folder 
and try to load it with [jl/gbend~ ].


2)
You can also try placing "gbend~" binary in the same dir as "main.pd" 
and call it using [gbend~ ].

3)
You can also test if [declare] is working.

On "main.pd" create a declare object [declare -path jl]

try loading your abstraction placed on "jl" folder just with [your-abs]




{1} You can use the standard Pd on your pi and use Deken to get some 
external i.e [freeverb~] :

freeverb~-v1.2.3-(Linux-armv7l-32)(Sources)-externals.tgz
     Uploaded by fjkraan @ 2016-07-29 16:40:59

I'm not sure if "Linux-armv7l-32" is for the pi (i guess it is).



Mensaje telepatico asistido por maquinas.

On 2/13/2019 9:54 AM, Joseph Larralde wrote:
> It seems to be a problem with externals because abstractions load just 
> fine from the same folder (see also my answer to Lucas).
> I'm currently struggling to compile the node addon on my pi, and will 
> let you know if I get some positive results.
>
> Le 13/02/19 à 13:47, Giulio Moro a écrit :
>> Hmm, it should work with objects in the same folder as the pd file 
>> you open. I have tried that on Bela and I can remove the 
>> libpd_add_to_search_path() calls, and - as long as I pass the 
>> appropriate relative path to the _main.pd file - then abstractions 
>> that live in the same folder as _main.pd are loaded correctly, even 
>> if the program is started from a different folder. Actually, can you 
>> try with some abstractions instead of externals? Maybe the externals 
>> cannot load for other reasons, but if you get the abstractions to 
>> work, then you'll have narrowed down your problem.
>>
>>
>> On Wednesday, 13 February 2019, 12:15:59 GMT, Joseph Larralde 
>>  wrote:
>>
>> Hi Giulio,
>>
>> Le 13/02/19 à 11:11, Giulio Moro a écrit :
>>> That sounds like an interesting project, although I struggle to 
>>> understand how it would be used.
>> Yes it is :)
>> Actually we are working on a project where we make an extensive use of
>> nodejs for distributed local applications, so it's worth using this
>> addon in our case (and that's the kind of scenario for which it was
>> initially created).
>> I must admit that for my own use, I'm only launching pd from a node
>> server and then doing everything else in the patches ...
>> (I was inspired to do so after trying out the Bela once, so thanks for
>> the inspiration)
>>> AFAIK, libpd does not search in any of the default Pd paths. It 
>>> comes with a `libpd_add_to_search_path()` function that you should 
>>> use to manually add the search paths. From the README of node-libpd, 
>>> among the todos there is :
>>>     • re-enable addToSearchPath and clearSearchPath
>> Thanks for explaining the path issue before I went crazy.
>> You're right, this is written in the todos of the README, which is a bit
>> minimalistic ...
>>> So that is probably where the issue lies. In the meantime you can 
>>> consider just copying or symlinking your externals to the current 
>>> folder.
>> Unfortunately, copying the external to the current folder didn't help,
>> so I guess I'll have to modify the addon a bit to re-enable the
>> addToSearchPath method and make a PR.
>> >From my experience of pd, I suspect this should be done at 
>> initialization time, so I might have to modify the addon's api to
>> provide another json field in the init method instead.
>> Does this sound right-minded ?
>>
>> Thanks,
>> Joseph
>>
>>
>>> Giulio
>>>
>>> On Wednesday, 13 February 2019, 09:49:08 GMT, Joseph Larralde 
>>>  wrote:
>>>
>>> Hi,
>>>
>>> A friend of mine wrote this libpd wrapper for nodejs (which is actually
>>> a work in progress) :
>>> https://github.com/ircam-jstools/node-libpd
>>> It's running fine on a pi3 I'm using ATM.
>>>
>>> Now I need to use some externals I wrote, and I can't get them to load
>>> properly.
>>> But, they're loading when I start my test patch using pd itself.
>>>
>>> Before diving into his wrapper code, I'd like to make sure I'm placing
>>> the externals in the right path.
>>> What makes me think it should be working is this page :
>>> https://github.com/libpd/libpd/wiki/misc
>>> And also the fact that in his code, he's calling the init() function
>>> from PdBase, which is itself calling the libpd_init() function.
>>>
>>> I tried putting the externals into /usr/local/lib/pd-externals,
>>> /usr/local/lib/pd/extra, /usr/lib/pd/extra and ~/.local/lib/pd/extra.
>>> But still no luck ...
>>>
>>> Can anyone confirm I'm not mistaken ?
>>>
>>> Cheers,
>>> Joseph
>>>
>>>
>>>
>>> ___
>>> Pd-dev mailing list
>>> Pd-dev@lists.iem.at
>>> https://lists.puredata.info/listinfo/pd-dev
>>>
>>
>
>
>
>
> 

Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win

[Lucas Cordiviola]

I've finished scanning all the packages from "deken_w32_filled_2.txt" 
attached earlier on this thread which covers all Deken as of july 2016.
No traces of "msvcr90.dll".

@IOhannes:
Can you generate a new .txt with all w32 pkgs?

I'll gladly scan the rest.

:)

Mensaje telepatico asistido por maquinas.


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win

[Lucas Cordiviola]

No traces of msvcrt.dll or msvcr90.dll on PDRP. (Attached dep-walker txt 
files.)

I think bin/msvcrt.dll is safe to delete.

As of "bin/msvcr90.dll": could it be that it's just a leftover from the 
times when you double-compile with VS and MinGW ?
Few externals are compiled with VS and I doubt any developer had ever 
asked to ship "pd/bin/msvcr90.dll". We know it is not needed/inherited 
from the pd-extended-era.



:)

Mensaje telepatico asistido por maquinas.

On 1/23/2019 3:30 PM, Miller Puckette wrote:
> Cool.
>
> I have a real tough test in mind - the old PDRP patches which have MSVC-
> compiled externs in them, with msvcrt.dll dynamically linked (I believe).
> I'll set up a clean W2K system to test them on and see what happens (and
> if they don't work without the DLLs in pd/bin/ I can see if my proposed
> workaround  fixes things).
>
> cheers
> M
>
>
> On Wed, Jan 23, 2019 at 10:14:39AM +, Lucas Cordiviola wrote:
>> Here's a full dependency-walker analysis of all w32 v00-extended Deken:
>>
>> http://lucarda.com.ar/x/dep-walk-00extended-deken-w32-report.zip
>>
>> It's one text file per .dll. We can Grep/Findstring to get results that 
>> mainly boils down to:
>>
>> msvcr90.dll -> no match.
>>
>> msvcr71.dll -> Gem and friends.
>>
>> pthread ->  splits to:
>>
>> PTHREADGC2.DLL --> some objects.
>>
>> PTHREADVC.DLL --> Gem and friends. We must consider Oliver's discoveries on 
>> this: https://lists.puredata.info/pipermail/pd-list/2018-12/124086.html as 
>> there's something strange with this file.
>>
>> As of "msvcrt.dll" I think Christof had explained everything. My tests 
>> deleting this file showed no trouble.
>>
>> As of "msvcr90.dll" I will randomly search tomorrow on non Pd-extended-era 
>> but it could be the case that is not needed, ...
>>
>> Here are the Pd patches I used to generate batch files for dependency-walker 
>> and also to serialize opening and closing *-help.pd files:
>>
>> http://lucarda.com.ar/x/w32DekenPKGdepWalkCHECK1.zip
>>
>> @Christof
>>
>> since 2015 there are new runtime libraries, e.g. UCRTBASE.DLL and 
>> VCRUNTIME140.DLL 
>> (https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL,_MSVCP*.DLL_and_CRTDLL.DLL)
>>
>>
>> I helped Zack Lee's [ofelia] in the early stage a year ago. Basically 
>> there's the normal vc_redist.x86.exe but it does not work on machines that 
>> don't receive updates (a minority anyway) but theres is work around shipping 
>> a lot of dlls. :)
>>
>>
>> Mensaje telepatico asistido por maquinas.
>>
>> On 1/22/2019 10:56 PM, Christof Ressi wrote:
>>
>> sorry for spamming, but I think this SO question and the given answers shed 
>> some more light on the issue:
>>
>> https://stackoverflow.com/questions/1073509/should-i-redistribute-msvcrt-dll-with-my-application
>>
>> TL;DR: programs built with VS can either link statically against the MSVCRT 
>> or they have to install the appropiate redistributable package.
>> msvcrt.dll is very old and was declared a private system library which 
>> applications should not link against (didn't know that!), but MinGW does 
>> anyway.
>> You should certainly *not* redistribute msvcrt.dll.
>>
>> Christof
>>
>> PS: since 2015 there are new runtime libraries, e.g. UCRTBASE.DLL and 
>> VCRUNTIME140.DLL 
>> (https://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL,_MSVCP*.DLL_and_CRTDLL.DLL)
>>
>>
>>
>>
>>
>> Gesendet: Mittwoch, 23. Januar 2019 um 02:17 Uhr
>> Von: "Christof Ressi" <mailto:christof.re...@gmx.at>
>> An: pd-dev <mailto:pd-dev@lists.iem.at>
>> Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
>>
>> to sum it up: msvcrt.dll is always present on the system anyway, so there's 
>> no need to ship it with Pd. if an externals relies on msvcr90.dll in pd/bin 
>> I would consider this a bug.
>>
>>
>>
>>
>> Gesendet: Mittwoch, 23. Januar 2019 um 01:54 Uhr
>> Von: "Christof Ressi" <mailto:christof.re...@gmx.at>
>> An: "Miller Puckette" <mailto:m...@ucsd.edu>
>> Cc: pd-dev@lists.iem.at<mailto:pd-dev@lists.iem.at>
>> Betreff: Re: [PD-dev] removing pd/bin/msvr*.dll from Pd/win
>>
>> @Miller:
>>
>> neither Pd nor any externals built with MinGW (basically every external 
>> using pd-lib-builder) depend on the msvcrt.dll (or the msvcr90.dll or 
>> pthreadVC.dll) included in pd/bin.

Re: [PD-dev] First complete keyboard navigation prototype

[Lucas Cordiviola]

When trying to build on Debian I get this errors:



''


g_text.c: In function ‘canvas_howputnew’:
g_text.c:166:40: error: ‘struct _kbdnav’ has no member named ‘kn_navigating’
 if ( x->gl_editor->e_kbdnav.kn_navigating && 
x->gl_editor->e_kbdnav.kn_ioindex > 0 ){
^
g_text.c: In function ‘canvas_obj’:
g_text.c:237:41: error: ‘struct _kbdnav’ has no member named ‘kn_navigating’
 if ( gl->gl_editor->e_kbdnav.kn_navigating && 
gl->gl_editor->e_kbdnav.kn_ioindex != 0 ){
 ^
g_text.c: At top level:
cc1: warning: unrecognized command line option ‘-Wno-format-truncation’
cc1: warning: unrecognized command line option ‘-Wno-stringop-truncation’
cc1: warning: unrecognized command line option ‘-Wno-cast-function-type’


''

Mensaje telepatico asistido por maquinas.

On 6/7/19 11:52 PM, Henri Augusto Bisognini wrote:
Hi!

I've finally managed to get time to finish a prototype for a keyboard 
navigation interface. I mixed some ideas i had with some I've seen in Desire 
Data's old screenshot gallery (http://artengine.ca/desiredata/).

I've recorded some gifs to demonstrate it. (https://imgur.com/gallery/WSB40P7). 
It shows me using the help patch (which i've put in 
7.stuff/keyboard.navigation). You can read about which keys to use in the 
comments.

The source can be found on my GitHub, on the kbd_nav branch 
(https://github.com/HenriAugusto/pure-data/tree/kbd_nav)

Basically I've wanted to try:

- navigating through objects/inelts connection with ctrl+arrows (cmd+arrows on 
Mac)
- automatically positioning new objects according to selected inlet/outlet
- a console bar to send messages to the focused patch
- ability to display each object index (to be used with the functionalities 
below)
- a new "goto" canvas message to select any object in the patch
- a "magnetic connector" that connects the selected in/outlet to the nearest 
ins/outs
- a "digit connectors" that displays indexes 0 to 9 for the 10 nearest possible 
connections. Just press the number and it will connect it for you
- pd can automatically fill for you a "connect" message in the console 
containing the info for the selected inlet/outlet. It will even select for you 
the part you need to fill
- You can click objects with shift+enter. Mostly useful for sending bangs and 
opening subpatches/abstractions

Everything is intended to be as minimal as possible and very easy to use. I 
wish to propose we study including it in vanilla.

Well, what do you guys think?

This is my first time working on a project this big so help me out if i did 
anything incorrectly. I've been testing the major functions on Win for a while 
now but couldn't test on mac/linux.

Cheers,
Henri.



N�n�r)em�h�yhiם�w^���
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] First complete keyboard navigation prototype

[Lucas Cordiviola]

Right, i could finish the build.


Here on my linux box (Debian9 Xfce) everything is working except the < ctrl+'> 
(control + single quote) to enter the "canvas message console". I can enter it 
as explained in "connecting_with_the_canvas_msg_console".


Feature request:

I found it difficult to see which cable is selected.

I suggest making the selected cable "Thicker" or something that makes it more 
visually obvious.





:)



Mensaje telepatico asistido por maquinas.

On 6/8/19 1:23 AM, Henri Augusto Bisognini wrote:
Sorry, it seems that i've uploaded the wrong "g_text.c" version to the kbd_nav 
branch. I should be fixed now.

____
De: Lucas Cordiviola <mailto:lucard...@hotmail.com>
Enviado: sábado, 8 de junho de 2019 01:10
Para: Henri Augusto Bisognini; pd-dev@lists.iem.at<mailto:pd-dev@lists.iem.at>
Assunto: Re: [PD-dev] First complete keyboard navigation prototype


When trying to build on Debian I get this errors:



''


g_text.c: In function ‘canvas_howputnew’:
g_text.c:166:40: error: ‘struct _kbdnav’ has no member named ‘kn_navigating’
 if ( x->gl_editor->e_kbdnav.kn_navigating && 
x->gl_editor->e_kbdnav.kn_ioindex > 0 ){
^
g_text.c: In function ‘canvas_obj’:
g_text.c:237:41: error: ‘struct _kbdnav’ has no member named ‘kn_navigating’
 if ( gl->gl_editor->e_kbdnav.kn_navigating && 
gl->gl_editor->e_kbdnav.kn_ioindex != 0 ){
 ^
g_text.c: At top level:
cc1: warning: unrecognized command line option ‘-Wno-format-truncation’
cc1: warning: unrecognized command line option ‘-Wno-stringop-truncation’
cc1: warning: unrecognized command line option ‘-Wno-cast-function-type’


''

Mensaje telepatico asistido por maquinas.

On 6/7/19 11:52 PM, Henri Augusto Bisognini wrote:
Hi!

I've finally managed to get time to finish a prototype for a keyboard 
navigation interface. I mixed some ideas i had with some I've seen in Desire 
Data's old screenshot gallery (http://artengine.ca/desiredata/).

I've recorded some gifs to demonstrate it. (https://imgur.com/gallery/WSB40P7). 
It shows me using the help patch (which i've put in 
7.stuff/keyboard.navigation). You can read about which keys to use in the 
comments.

The source can be found on my GitHub, on the kbd_nav branch 
(https://github.com/HenriAugusto/pure-data/tree/kbd_nav)

Basically I've wanted to try:

- navigating through objects/inelts connection with ctrl+arrows (cmd+arrows on 
Mac)
- automatically positioning new objects according to selected inlet/outlet
- a console bar to send messages to the focused patch
- ability to display each object index (to be used with the functionalities 
below)
- a new "goto" canvas message to select any object in the patch
- a "magnetic connector" that connects the selected in/outlet to the nearest 
ins/outs
- a "digit connectors" that displays indexes 0 to 9 for the 10 nearest possible 
connections. Just press the number and it will connect it for you
- pd can automatically fill for you a "connect" message in the console 
containing the info for the selected inlet/outlet. It will even select for you 
the part you need to fill
- You can click objects with shift+enter. Mostly useful for sending bangs and 
opening subpatches/abstractions

Everything is intended to be as minimal as possible and very easy to use. I 
wish to propose we study including it in vanilla.

Well, what do you guys think?

This is my first time working on a project this big so help me out if i did 
anything incorrectly. I've been testing the major functions on Win for a while 
now but couldn't test on mac/linux.

Cheers,
Henri.



N�n�r)em�h�yhiם�w^���



___
Pd-dev mailing list
Pd-dev@lists.iem.at<mailto:Pd-dev@lists.iem.at>
https://lists.puredata.info/listinfo/pd-dev

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pd-0.49-0: Deken not working in Raspberry Pi 3 B+

[Lucas Cordiviola]

hmm,

Today Deken is not working.

I'm on my normal windows machine.

Mensaje telepatico asistido por maquinas.

On 5/29/2019 11:39 AM, Frodo Jedi wrote:
Hi Roman,
I confirm that I also receive  the message "[deken]: No matching externals 
found."  I performed the steps you indicated.
I am on a Debian stretch.
Any idea? Maybe this is an easy to fix bug?






On Wed, May 29, 2019 at 4:05 PM Roman Haefeli 
mailto:reduz...@gmail.com>> wrote:
On Wed, 2019-05-29 at 15:59 +0200, Roman Haefeli wrote:
> On Tue, May 28, 2019 at 3:49 PM Frodo Jedi <
> > frodojedi.mailingl...@gmail.com> 
> > wrote:
> > > Hi all,
> > > I have just compiled and installed pd-0.49-0 on my Raspberry Pi 3
> > > B+.
> > > When launching Deken to find and install externals nothing
> > > happens
> > > (Of course I have internet enabled in the Pi).
> > > Can anyone suggest how to troubleshoot this?
> > > Compilations and installation worked smoothly, no issue at all.
>
> On Wed, 2019-05-29 at 14:55 +0200, Frodo Jedi wrote:
> > Is there anyone who can provide support to this issue please?
>
>
> Please be more specific about your issue. What are the exact steps
> you
> perform? What do you expect to happen after each step? In what way
> does
> the actual behavior deviate from the expected behavior? What is your
> environment/operating system?
>
> "nothing happens" is a pretty broad description of things.
>

This is what I find on my Raspberry Pi 3 B+ with Raspbian 9.9 and a
recently compiled Pd 0.49:

When searching for widely known externals like 'zexy' or 'else' in
'Help' -> 'Find externals', Deken prints to the Pd console:

"[deken]: No matching externals found."

Like the original poster, I checked that the Raspberry Pi in question
has access to the www. So the problem might be somewhere else.

Roman
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev



___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] First complete keyboard navigation prototype

[Lucas Cordiviola]

oops, this feature is already covered on "intelligent patching 
amendments #575"


Mensaje telepatico asistido por maquinas.

On 6/10/2019 5:15 AM, Lucas Cordiviola wrote:
>
>
> Feature request:
>
> Make TAB a shortcut to "goto x++" and SHIFT+TAB "goto x--". This is 
> how web browsers handle navigation on pages. So pressing TAB will 
> navigate through objects. This (i think) will make it easier to patch 
> with the keyboard.
>



___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] formatting HTML doc in Pd distro?

[Lucas Cordiviola]

If the only show stopper for HTML is "typeset equations in native HTML" there's 
a workaround:

https://www.mathjax.org/<https://www.mathjax.org/#gettingstarted>

https://github.com/mathjax/MathJax

the only gotcha is that the "typeset equations" wont render on an offline 
browser.

Works by just including :



in the  of the document.

Its fully documented and looks it is going to be there.  (if for some reason we 
need the local files it takes 40Mb)

It might be just what we want.


?

IOhannes ?


Test code:

'''










big heading 
 h2 smaller heading 

 paragraph ... when \( x < y \) we have ...

 paragraph 2 .. \[ \sum a b \]

 paragraph 3 .. \(\sum a b \)






Mensaje telepatico asistido por maquinas.

On 7/2/2019 11:13 AM, Miller Puckette wrote:

Looks like the best thing will be to use either latex or markdown, and
include both the latex/markdown source and an HTML compiled version of
the doc in the git repo.  The doc will doubtless contain images of
patch fragments, taken from the help files, in a way similar to my
book (http://msp.ucsd.edu/techniques.htm).

cheers
M

for the images.  (Unless it's feasible to unify that with the help
On Tue, Jul 02, 2019 at 07:11:35AM +, Lucas Cordiviola wrote:



On 7/1/2019 5:46 AM, IOhannes m zmoelnig wrote:


i*strongly*  suggest to
- have **all** the sources (for*anything*  generated, including images)
in the git-repository
- allow to build all artifacts automatically?? (via the build-system)



I fail to see anything we can do to auto-generate single image files
from 1 or more LaTex file/s. This should be carefully and manually
handled by the author or the maintainer. There could be one master LaTex
file containing the code for each image if the source is to be stored:

''
figure 0.1.0
$saras \$whatever ...
figure 0.1.1
$ssgdsdg \$whatever ...
''

Since this is not automatic Miller should probably be in favor (and I
understand) of just writing everything on LaTex files instead of html.
Since I don't know how many "math formulas" are needed I don't know what
to say.



:)


Mensaje telepatico asistido por maquinas.

___
Pd-dev mailing list
Pd-dev@lists.iem.at<mailto:Pd-dev@lists.iem.at>
https://lists.puredata.info/listinfo/pd-dev

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] pd 0.50-0 test1 on win64/tk64 and Pdfontloader

[Lucas Cordiviola]

( writing this again as it was in a wrong thread and i have more info)


I've detected that your "0.50-0 test1" for win64 is built with an 64-bit
wish86.exe. This one does not ship, nor load the current pdfonloader.dll
that it's for 32-bit only.

I see 2 solutions:

1 - Build and use wish86.exe for 32bit.

2 - Build an 64bit "pdfontloader64.dll" and include some lines in
pd-gui.tcl to auto-detect the current wish* architecture and then load
the correct pdfontloader.




As for solution 2 to I did:



To compile an 64bit pdfontloader I did add these packages to MinGW with:

pacman -S mingw64/mingw-w64-x86_64-tcl

pacman -S mingw64/mingw-w64-x86_64-tk

then I did "make" in pdfontloder dir. and rename the dll to pdfontloader64.dll.



And included this lines in "pd-gui.tcl" (Line 407) :

set arch $::tcl_platform(pointerSize)
switch -- $arch {
4 { load [file join "$::sys_libdir" 
"bin/pdfontloader.dll"]  }
8 { load [file join "$::sys_libdir" 
"bin/pdfontloader64.dll"] }
}

-- 
Mensaje telepatico asistido por maquinas.

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] networking updates

[Lucas Cordiviola]

On 8/10/19 10:49 PM, Dan Wilcox wrote:
>
> If you can build Pd and want to try this out, the branch is called 
> feature/netobject-updates


When trying to build this one I get:

u_pdsend.c:14:10: fatal error: s_net.h: No such file or directory
  #include 
   ^
compilation terminated.
make: *** [makefile.gnu:170: ../bin/pdsend] Error 1

I'm on linux, using the package downloaded as zip from: 
https://github.com/pure-data/pure-data/tree/feature/netobject-updates


--

Mensaje telepatico asistido por maquinas.





___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] networking updates

[Lucas Cordiviola]

also with Pd 0.50 <-> Pd 0.49 and Pd 0.50 <-> [some other IPv4-only endpoint]!

Been testing 0.50 (win & linux) <-> 0.49(win) & UDP Terminal (android).

It's working nice.

:)

Mensaje telepatico asistido por maquinas.

On 8/11/19 9:03 AM, Christof Ressi wrote:
> The overall approach taken is to keep IPv4 as default and detect IPv6 
> addresses so this should not affect existing patches

We've tried hard to maintain backwards compatibility with existing IPv4-only 
endpoints, so please don't only test with Pd 0.50 <-> Pd 0.50 but also with Pd 
0.50 <-> Pd 0.49 and Pd 0.50 <-> [some other IPv4-only endpoint]!

Christof


Gesendet: Sonntag, 11. August 2019 um 03:49 Uhr
Von: "Dan Wilcox" 
An: pd-dev 
Betreff: [PD-dev] networking updates
Howdy all,

Christoph and I have more or less finished some work that updates Pd's 
networking and also fixes some  bugs and a couple pain points:

* IPv6 support
* multicast
* netsend: optional from hostname & port outlet
* netsend: connectionless UDP, no more connection refused (fire & forget 
without having to manually reconnect)
* netreceive: settable timeout which defaults to 10 seconds (no more super-long 
frozen Pd)
* improved error printing with netsend and netrceive Find Last Error support
* various small bug fixes (no more polling errors after socket is closed)

The pdsend & pdreceive utils are similarly updated.

The discussion & pull request on Github: 
https://github.com/pure-data/pure-data/pull/577

If you can build Pd and want to try this out, the branch is called 
feature/netobject-updates

The overall approach taken is to keep IPv4 as default and detect IPv6 addresses 
so this should not affect existing patches. The IP version handling should also 
degrade gracefully based if IPv6 is not available. An added bonus is hostnames 
now resolve (ie. google.com) and you can also listen on a 
hostname if your system can grab it (ie. computername.local).

One current limitation is that Tcl 8.5 does not have IPv6 support, so the core 
communication with the GUI remains IPv4.


Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com

___ Pd-dev mailing list 
Pd-dev@lists.iem.at 
https://lists.puredata.info/listinfo/pd-dev



N�n�r)em�h�yhiם�w^���
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] 0.50-0 released (windows 64bit release with "font" troubles)

[Lucas Cordiviola]

Hi Miller,

The 64bit release has font troubles. Two files are missing:

bin/pdfontloader.dll (the 64bit one)

font/DejaVuSansMono-Bold.ttf  (this one is the git repo and in is 
included in the 32bit release and is actually needed or we get an ugly 
render.)


I attach "pdfontloader64.zip"


---

To compile the 64bit pdfontloader.dll I did add these packages to MinGW with:

pacman -S mingw64/mingw-w64-x86_64-tcl

pacman -S mingw64/mingw-w64-x86_64-tk

then I did "make" in pdfontloder dir. and rename the dll to pdfontloader64.dll.

--


-- 
Mensaje telepatico asistido por maquinas.

<>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] formatting HTML doc in Pd distro?

[Lucas Cordiviola]

On 6/30/2019 10:41 PM, Miller Puckette wrote:

> The gotcha is that I can't find a way to typeset equations in native HTML...

How about making the rendered image (of the math equation) with 
https://www.codecogs.com/latex/eqneditor.php and include the image in 
the HTML doc. (isn't this is what Latex do when it generates an HTML 
output ?)

?

Mensaje telepatico asistido por maquinas.


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] formatting HTML doc in Pd distro?

[Lucas Cordiviola]

On 6/30/2019 1:05 AM, Miller Puckette wrote:

> Any advice would be very helpful!


Stay in the HTML format.

Following https://www.w3schools.com/html/html_basic.asp anyone can come 
up with an object documentation.

HTML is the way to go. No need for latex, md, or whatever. HTML is 
really simple and works on any computer and is very straightforward to 
maintain and enhance. Most importantly it does not add compiling dependency.

*







 big heading 
 h2 smaller heading 

 paragraph

 paragraph 2




*


Having the ability to open local or remote URLs  is a total Pd enhancer.


:)


Mensaje telepatico asistido por maquinas.

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Double precision externals extensions.

[Lucas Cordiviola]

I could get this from linux, at least is something:

~

Program received signal SIGSEGV, Segmentation fault.

0x76170e93 in pddplink_setup () at pddp/pddplink.c:353

353 sys_vgui("source {%s/pddplink.tcl}\n", dirsym->s_name);

~~~

But no worries is just an edge case. If I compile the lib without 
[pddplink] everything works on /single/ and fails correctly (no crashes) 
on /double/.

I can replace pddplink with [pdcontrol]

:)

On 12/10/19 8:53 PM, Christof Ressi wrote:
> We must find out where exactly the segfault happens. You can either look up 
> how to set breakpoints and step through the code, or use good 'ol printf 
> debugging

Mensaje telepatico asistido por maquinas.

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Double precision externals extensions.

[Lucas Cordiviola]

This is the backtrace with Msys2:

~~

Program received signal SIGSEGV, Segmentation fault.
0x6eb469f5 in pddplink_setup ()
    from /d/00-lucarda-external-dep/out64single-new-cyc/lucdep/liblucdep.dll
(gdb) bt
#0  0x6eb469f5 in pddplink_setup ()
    from /d/00-lucarda-external-dep/out64single-new-cyc/lucdep/liblucdep.dll
#1  0x6eb41467 in liblucdep_setup ()
    from /d/00-lucarda-external-dep/out64single-new-cyc/lucdep/liblucdep.dll
#2  0x673e8c85 in sys_trylock ()
    from 
/c/Users/Lucarda/Downloads/pure-data-double-precision/build4/pd-0.50.2-double/bin/pd.dll
#3  0x673e9304 in sys_loadlib_iter ()
    from 
/c/Users/Lucarda/Downloads/pure-data-double-precision/build4/pd-0.50.2-double/bin/pd.dll
#4  0x67374ed5 in pd!canvas_declare ()
    from 
/c/Users/Lucarda/Downloads/pure-data-double-precision/build4/pd-0.50.2-double/bin/pd.dll
#5  0x673e95e8 in sys_load_lib ()
    from 
/c/Users/Lucarda/Downloads/pure-data-double-precision/build4/pd-0.50.2-double/bin/pd.dll
#6  0x673747d8 in pd!glist_menu_open ()
    from 
/c/Users/Lucarda/Downloads/pure-data-double-precision/build4/pd-0.50.2-double/bin/pd.dll
#7  0x67374c7d in pd!canvas_declare ()
    from 
/c/Users/Lucarda/Downloads/pure-data-double-precision/build4/pd-0.50.2-double/bin/pd.dll
#8  0x673d68db in pd!binbuf_eval ()
--Type  for more, q to quit, c to continue without paging--
    from 
/c/Users/Lucarda/Downloads/pure-data-double-precision/build4/pd-0.50.2-double/bin/pd.dll
#9  0x673d73f6 in pd!binbuf_evalfile ()
    from 
/c/Users/Lucarda/Downloads/pure-data-double-precision/build4/pd-0.50.2-double/bin/pd.dll
#10 0x67379977 in pd!glob_evalfile ()
    from 
/c/Users/Lucarda/Downloads/pure-data-double-precision/build4/pd-0.50.2-double/bin/pd.dll
#11 0x673e9789 in sys_run_scheduler ()
    from 
/c/Users/Lucarda/Downloads/pure-data-double-precision/build4/pd-0.50.2-double/bin/pd.dll
#12 0x673ea6ec in pd!glob_initfromgui ()
    from 
/c/Users/Lucarda/Downloads/pure-data-double-precision/build4/pd-0.50.2-double/bin/pd.dll
#13 0x673d68db in pd!binbuf_eval ()
    from 
/c/Users/Lucarda/Downloads/pure-data-double-precision/build4/pd-0.50.2-double/bin/pd.dll
#14 0x673e75bd in socketreceiver_read ()
    from 
/c/Users/Lucarda/Downloads/pure-data-double-precision/build4/pd-0.50.2-double/bin/pd.dll
#15 0x673e6906 in sys_oktoloadfiles ()
    from 
/c/Users/Lucarda/Downloads/pure-data-double-precision/build4/pd-0.50.2-double/bin/pd.dll
--Type  for more, q to quit, c to continue without paging--
#16 0x673e825b in sys_pollgui ()
    from 
/c/Users/Lucarda/Downloads/pure-data-double-precision/build4/pd-0.50.2-double/bin/pd.dll
#17 0x673dfdda in pd!m_mainloop ()
    from 
/c/Users/Lucarda/Downloads/pure-data-double-precision/build4/pd-0.50.2-double/bin/pd.dll
#18 0x004013b4 in ?? ()
#19 0x004014db in ?? ()
#20 0x7fffdec01611 in KERNEL32!BaseThreadInitThunk ()
    from /c/Windows/system32/KERNEL32.DLL
#21 0x7fffdfb764ad in ntdll!RtlUserThreadStart ()
    from /c/Windows/SYSTEM32/ntdll.dll
#22 0x in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)

~

Mensaje telepatico asistido por maquinas.

On 12/10/2019 8:07 PM, Lucas Cordiviola wrote:
> Thx
>
> :)
>
> Mensaje telepatico asistido por maquinas.
>
> On 12/10/19 7:59 PM, Christof Ressi wrote:
>>> How do I install gdb in msys2?
>> pacman -S gdb
>>
>> Execute in MinGW32 shell and MINGW64 shell accordingly
>>
>>> How do I use it?
>> gdb --args pd [arguments]
>>> run // actually run the program
>> ... wait for crash ...
>>> bt // get the backtrace
>> press Enter repeatedly to see more lines
>>
>> Christof
>>
>>> Gesendet: Dienstag, 10. Dezember 2019 um 22:59 Uhr
>>> Von: "Lucas Cordiviola" 
>>> An: "pd-dev@lists.iem.at" , "Christof Ressi" 
>>> 
>>> Betreff: Re: [PD-dev] Double precision externals extensions.
>>>
>>> @christof
>>>
>>> How do I build Pd with debug symbols?
>>>
>>> How do I install gdb in msys2?
>>>
>>> How do I use it?
>>>
>>> or can I send you the .dll lib and test patch do you get the backtrace?
>>>
>>>
>>> --
>>>
>>> Mensaje telepatico asistido por maquinas.
>>>
>>> On 12/10/19 6:48 PM, Christof Ressi wrote:
>>>>>> # pkgs including both single- and double-precision externals
>>>>>> a single external binary (say: "foo.dll") can hold both single-precision
>>>>>> and double-precision variants of the [foo] object.
>>>> I'm also interested in how t

Re: [PD-dev] Double precision externals extensions.

[Lucas Cordiviola]

I mean this works fine on linux and windows single-precision but this 
single-precision lib crashes Pd-double in win and linux.


?

Mensaje telepatico asistido por maquinas.

On 12/10/19 7:50 PM, Lucas Cordiviola wrote:

Ok. So why do I get a segfault on linux and a crash on windows

~~~

void pddplink_setup(void)

{

t_symbol *dirsym;

pddplink_class = class_new(gensym("pddplink"),

(t_newmethod)pddplink_new,

(t_method)pddplink_free,

sizeof(t_pddplink),

CLASS_NOINLET | CLASS_PATCHABLE,

A_GIMME, 0);

class_addanything(pddplink_class, pddplink_anything);

class_setwidget(pddplink_class, _widgetbehavior);

pddplinkbox_class = class_new(gensym("pddplink"), 0,

(t_method)pddplink_free,

sizeof(t_pddplink), 0, A_GIMME, 0);

class_addbang(pddplinkbox_class, pddplink_bang);

class_addanything(pddplinkbox_class, pddplink_anything);

class_addmethod(pddplinkbox_class, (t_method)pddplink_click,

gensym("click"),

A_FLOAT, A_FLOAT, A_FLOAT, A_FLOAT, A_FLOAT, 0);

dirsym = pddplink_class->c_externdir; /* FIXME */

sys_vgui("source {%s/pddplink.tcl}\n", dirsym->s_name);

}

~~



?

Mensaje telepatico asistido por maquinas.

On 12/10/19 7:45 PM, Christof Ressi wrote:


Is this: "A_FLOAT" forbidden?


I'm not sure what you mean exactly, but A_FLOAT is an atom type, so
it's 100% unrelated to single/double precision.
*Gesendet:* Dienstag, 10. Dezember 2019 um 23:37 Uhr
*Von:* "Lucas Cordiviola" <mailto:lucard...@hotmail.com>
*An:* "pd-dev@lists.iem.at"<mailto:pd-dev@lists.iem.at> 
<mailto:pd-dev@lists.iem.at>
*Betreff:* Re: [PD-dev] Double precision externals extensions.

Is this: "A_FLOAT" forbidden?

~

void pddplink_setup(void)

{

t_symbol *dirsym;

pddplink_class = class_new(gensym("pddplink"),

(t_newmethod)pddplink_new,

(t_method)pddplink_free,

sizeof(t_pddplink),

CLASS_NOINLET | CLASS_PATCHABLE,

A_GIMME, 0);

class_addanything(pddplink_class, pddplink_anything);

class_setwidget(pddplink_class, _widgetbehavior);

pddplinkbox_class = class_new(gensym("pddplink"), 0,

(t_method)pddplink_free,

sizeof(t_pddplink), 0, A_GIMME, 0);

class_addbang(pddplinkbox_class, pddplink_bang);

class_addanything(pddplinkbox_class, pddplink_anything);

class_addmethod(pddplinkbox_class, (t_method)pddplink_click,

gensym("click"),

A_FLOAT, A_FLOAT, A_FLOAT, A_FLOAT, A_FLOAT, 0);

dirsym = pddplink_class->c_externdir; /* FIXME */

sys_vgui("source {%s/pddplink.tcl}\n", dirsym->s_name);

}

~

Mensaje telepatico asistido por maquinas.
On 12/10/19 7:30 PM, Lucas Cordiviola wrote:

I get the segfault on linux (it also crashes Pd-double)

~~~

Program received signal SIGSEGV, Segmentation fault.
0x76170e93 in pddplink_setup ()
   from

/home/lucarda/Desktop/luclibdep/00-lucarda-external-dep/out64single/lucdep/liblucdep.so

~~~


:)


Mensaje telepatico asistido por maquinas.

On 12/10/19 7:06 PM, IOhannes m zmölnig wrote:

On 12/10/19 10:48 PM, Christof Ressi wrote:

I'm also interested in how this works. The following
solution popped up in my head: compile the object twice,
one time with -DPD_FLOATSIZE=32 and another time with
-DPD_FLOATSIZE=64, with different setup functions based on
-DPD_FLOATSIZE, then link it with a third file which
exports the "real" setup function (which calls the other
two private setup functions).

that's about the idea.

gdsa r
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at<mailto:Pd-dev@lists.iem.at>
https://lists.puredata.info/listinfo/pd-dev

___ Pd-dev mailing list
Pd-dev@lists.iem.at<mailto:Pd-dev@lists.iem.at> 
https://lists.puredata.info/listinfo/pd-dev

___
Pd-dev mailing list
Pd-dev@lists.iem.at<mailto:Pd-dev@lists.iem.at>
https://lists.puredata.info/listinfo/pd-dev


___
Pd-dev mailing list
Pd-dev@lists.iem.at<mailto:Pd-dev@lists.iem.at>
https://lists.puredata.info/listinfo/pd-dev

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Double precision externals extensions.

[Lucas Cordiviola]

On 12/10/2019 6:32 PM, IOhannes m zmölnig wrote:
> On 12/10/19 9:45 PM, Lucas Cordiviola wrote:
>> But I'm creating a single binary external with a collection of authors
>> [zexy] [cyclone] [ggee] [pddplink] ...
> what's the purpose of this?
> and what's the license?

Currently I share Pd-Albums (like CD albums, but these are played back 
with Pd) and there is a few externals i use and I ship (with licenses).

Now there are a lot of single files (for win/mac/linux) and i decided to 
compile them all into a single file per OS/ARCH and also for single and 
double.

These are going to be shipped also with sources and a makefile with 
pd-lib-builder.

So far all good except that my single binary crashes the unmatched 
precision.


>
>> I create a setup for the lib and is working *OK* in Pd-w64-32 but it
>> crashed the double precision.
> could you provide a backtrace?

Windows tell me it's liblucdep.dll that produces the fault.

I'll try to get a backtrace with Msys2 but I never did it . I will 
investigate in Linux first.


:)



>
> gmdsar
> IOhannes



Mensaje telepatico asistido por maquinas.

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Double precision externals extensions.

[Lucas Cordiviola]

@christof

How do I build Pd with debug symbols?

How do I install gdb in msys2?

How do I use it?

or can I send you the .dll lib and test patch do you get the backtrace?


--

Mensaje telepatico asistido por maquinas.

On 12/10/19 6:48 PM, Christof Ressi wrote:
>>> # pkgs including both single- and double-precision externals
>>> a single external binary (say: "foo.dll") can hold both single-precision
>>> and double-precision variants of the [foo] object.
> I'm also interested in how this works. The following solution popped up in my 
> head: compile the object twice, one time with -DPD_FLOATSIZE=32 and another 
> time with -DPD_FLOATSIZE=64, with different setup functions based on 
> -DPD_FLOATSIZE, then link it with a third file which exports the "real" setup 
> function (which calls the other two private setup functions).
>
> Is there an easier way?
>
> If not, then a new extension could be handy, so people can throw both 
> versions into the same folder.
>
> Christof
>
>> Gesendet: Dienstag, 10. Dezember 2019 um 21:45 Uhr
>> Von: "Lucas Cordiviola" 
>> An: "pd-dev@lists.iem.at" 
>> Betreff: Re: [PD-dev] Double precision externals extensions.
>>
>> On 12/10/2019 4:54 PM, IOhannes m zmölnig wrote:
>>> # avoiding crashes
>>> an external that has been compiled with single-precision will not
>>> register objectclasses in a double-precision Pd - so the doubl-precision
>>> Pd will not know about those new objects and not crash while using them.
>>> same goes for the other way round.
>> I see with normal externals itt refuses to load and thats fine.
>>
>> But I'm creating a single binary external with a collection of authors
>> [zexy] [cyclone] [ggee] [pddplink] ...
>>
>> I create a setup for the lib and is working *OK* in Pd-w64-32 but it
>> crashed the double precision.
>>
>> this is my wrapper setup:
>>
>> ~~
>>
>> #include "m_pd.h"
>>
>> #include 
>> #include 
>>
>>
>> #ifdef __WIN32__
>> # define vsnprintf _vsnprintf
>> #endif
>>
>>
>>
>> typedef struct liblucdep {
>>     t_object t_ob;
>> } t_liblucdep;
>>
>> t_class *liblucdep_class=NULL;
>>
>>
>>
>>
>> static void *liblucdep_new(void)
>> {
>>     t_liblucdep *x = (t_liblucdep *)pd_new(liblucdep_class);
>>     return (x);
>> }
>>
>> void liblucdep_setup(void)
>> {
>>
>>     post("***");
>>     post("liblucdep loaded.");
>>     post("***");
>>
>>     liblucdep_class = class_new(gensym("liblucdep"), liblucdep_new, 0,
>> sizeof(t_liblucdep), 0, 0);
>>
>>
>>     /* ** */
>>     coll_setup();
>>     comment_setup();
>>     freeverb_tilde_setup();
>>     glue_setup();
>>     helplink_setup();
>>     image_setup();
>>     pddplink_setup();
>>     pink_tilde_setup();
>>     reson_tilde_setup();
>>     tabminmax_setup();
>>     time_setup();
>>     z_tilde_setup();
>> }
>>
>>
>> ~
>>
>>
>>> # pkgs including both single- and double-precision externals
>>> a single external binary (say: "foo.dll") can hold both single-precision
>>> and double-precision variants of the [foo] object.
>>
>> How is that?
>>
>> As I am willing to contribute to the w32/64-double Deken.
>>
>>
>> :)
>>
>> Mensaje telepatico asistido por maquinas.
>>
>>
>> ___
>> Pd-dev mailing list
>> Pd-dev@lists.iem.at
>> https://lists.puredata.info/listinfo/pd-dev
>>
>
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Double precision externals extensions.

[Lucas Cordiviola]

Is this: "A_FLOAT" forbidden?

~

void pddplink_setup(void)

{

t_symbol *dirsym;

pddplink_class = class_new(gensym("pddplink"),

(t_newmethod)pddplink_new,

(t_method)pddplink_free,

sizeof(t_pddplink),

CLASS_NOINLET | CLASS_PATCHABLE,

A_GIMME, 0);

class_addanything(pddplink_class, pddplink_anything);

class_setwidget(pddplink_class, _widgetbehavior);

pddplinkbox_class = class_new(gensym("pddplink"), 0,

(t_method)pddplink_free,

sizeof(t_pddplink), 0, A_GIMME, 0);

class_addbang(pddplinkbox_class, pddplink_bang);

class_addanything(pddplinkbox_class, pddplink_anything);

class_addmethod(pddplinkbox_class, (t_method)pddplink_click,

gensym("click"),

A_FLOAT, A_FLOAT, A_FLOAT, A_FLOAT, A_FLOAT, 0);

dirsym = pddplink_class->c_externdir; /* FIXME */

sys_vgui("source {%s/pddplink.tcl}\n", dirsym->s_name);

}

~

Mensaje telepatico asistido por maquinas.

On 12/10/19 7:30 PM, Lucas Cordiviola wrote:
I get the segfault on linux (it also crashes Pd-double)

~~~

Program received signal SIGSEGV, Segmentation fault.
0x76170e93 in pddplink_setup ()
   from 
/home/lucarda/Desktop/luclibdep/00-lucarda-external-dep/out64single/lucdep/liblucdep.so

~~~


:)


Mensaje telepatico asistido por maquinas.

On 12/10/19 7:06 PM, IOhannes m zmölnig wrote:
On 12/10/19 10:48 PM, Christof Ressi wrote:
I'm also interested in how this works. The following solution popped up in my 
head: compile the object twice, one time with -DPD_FLOATSIZE=32 and another 
time with -DPD_FLOATSIZE=64, with different setup functions based on 
-DPD_FLOATSIZE, then link it with a third file which exports the "real" setup 
function (which calls the other two private setup functions).

that's about the idea.

gdsa r
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at<mailto:Pd-dev@lists.iem.at>
https://lists.puredata.info/listinfo/pd-dev
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Double precision externals extensions.

[Lucas Cordiviola]

I get the segfault on linux (it also crashes Pd-double)

~~~

Program received signal SIGSEGV, Segmentation fault.
0x76170e93 in pddplink_setup ()
    from 
/home/lucarda/Desktop/luclibdep/00-lucarda-external-dep/out64single/lucdep/liblucdep.so

~~~


:)


Mensaje telepatico asistido por maquinas.

On 12/10/19 7:06 PM, IOhannes m zmölnig wrote:
> On 12/10/19 10:48 PM, Christof Ressi wrote:
>> I'm also interested in how this works. The following solution popped up in 
>> my head: compile the object twice, one time with -DPD_FLOATSIZE=32 and 
>> another time with -DPD_FLOATSIZE=64, with different setup functions based on 
>> -DPD_FLOATSIZE, then link it with a third file which exports the "real" 
>> setup function (which calls the other two private setup functions).
>>
> that's about the idea.
>
> gdsa r
> IOhannes
>
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Double precision externals extensions.

[Lucas Cordiviola]

Thx

:)

Mensaje telepatico asistido por maquinas.

On 12/10/19 7:59 PM, Christof Ressi wrote:
>> How do I install gdb in msys2?
> pacman -S gdb
>
> Execute in MinGW32 shell and MINGW64 shell accordingly
>
>> How do I use it?
> gdb --args pd [arguments]
>> run // actually run the program
> ... wait for crash ...
>> bt // get the backtrace
> press Enter repeatedly to see more lines
>
> Christof
>
>> Gesendet: Dienstag, 10. Dezember 2019 um 22:59 Uhr
>> Von: "Lucas Cordiviola" 
>> An: "pd-dev@lists.iem.at" , "Christof Ressi" 
>> 
>> Betreff: Re: [PD-dev] Double precision externals extensions.
>>
>> @christof
>>
>> How do I build Pd with debug symbols?
>>
>> How do I install gdb in msys2?
>>
>> How do I use it?
>>
>> or can I send you the .dll lib and test patch do you get the backtrace?
>>
>>
>> --
>>
>> Mensaje telepatico asistido por maquinas.
>>
>> On 12/10/19 6:48 PM, Christof Ressi wrote:
>>>>> # pkgs including both single- and double-precision externals
>>>>> a single external binary (say: "foo.dll") can hold both single-precision
>>>>> and double-precision variants of the [foo] object.
>>> I'm also interested in how this works. The following solution popped up in 
>>> my head: compile the object twice, one time with -DPD_FLOATSIZE=32 and 
>>> another time with -DPD_FLOATSIZE=64, with different setup functions based 
>>> on -DPD_FLOATSIZE, then link it with a third file which exports the "real" 
>>> setup function (which calls the other two private setup functions).
>>>
>>> Is there an easier way?
>>>
>>> If not, then a new extension could be handy, so people can throw both 
>>> versions into the same folder.
>>>
>>> Christof
>>>
>>>> Gesendet: Dienstag, 10. Dezember 2019 um 21:45 Uhr
>>>> Von: "Lucas Cordiviola" 
>>>> An: "pd-dev@lists.iem.at" 
>>>> Betreff: Re: [PD-dev] Double precision externals extensions.
>>>>
>>>> On 12/10/2019 4:54 PM, IOhannes m zmölnig wrote:
>>>>> # avoiding crashes
>>>>> an external that has been compiled with single-precision will not
>>>>> register objectclasses in a double-precision Pd - so the doubl-precision
>>>>> Pd will not know about those new objects and not crash while using them.
>>>>> same goes for the other way round.
>>>> I see with normal externals itt refuses to load and thats fine.
>>>>
>>>> But I'm creating a single binary external with a collection of authors
>>>> [zexy] [cyclone] [ggee] [pddplink] ...
>>>>
>>>> I create a setup for the lib and is working *OK* in Pd-w64-32 but it
>>>> crashed the double precision.
>>>>
>>>> this is my wrapper setup:
>>>>
>>>> ~~
>>>>
>>>> #include "m_pd.h"
>>>>
>>>> #include 
>>>> #include 
>>>>
>>>>
>>>> #ifdef __WIN32__
>>>> # define vsnprintf _vsnprintf
>>>> #endif
>>>>
>>>>
>>>>
>>>> typedef struct liblucdep {
>>>>  t_object t_ob;
>>>> } t_liblucdep;
>>>>
>>>> t_class *liblucdep_class=NULL;
>>>>
>>>>
>>>>
>>>>
>>>> static void *liblucdep_new(void)
>>>> {
>>>>  t_liblucdep *x = (t_liblucdep *)pd_new(liblucdep_class);
>>>>  return (x);
>>>> }
>>>>
>>>> void liblucdep_setup(void)
>>>> {
>>>>
>>>>  post("***");
>>>>  post("liblucdep loaded.");
>>>>  post("***");
>>>>
>>>>  liblucdep_class = class_new(gensym("liblucdep"), liblucdep_new, 0,
>>>> sizeof(t_liblucdep), 0, 0);
>>>>
>>>>
>>>>  /* ** */
>>>>  coll_setup();
>>>>  comment_setup();
>>>>  freeverb_tilde_setup();
>>>>  glue_setup();
>>>>  helplink_setup();
>>>>  image_setup();
>>>>  pddplink_setup();
>>>>  pink_tilde_setup();
>>>>  reson_tilde_setup();
>>>>  tabminmax_setup();
>>>>  time_setup();
>>>>  z_tilde_setup();
>>>> }
>>>>
>>>>
>>>> ~
>>>>
>>>>
>>>>> # pkgs including both single- and double-precision externals
>>>>> a single external binary (say: "foo.dll") can hold both single-precision
>>>>> and double-precision variants of the [foo] object.
>>>> How is that?
>>>>
>>>> As I am willing to contribute to the w32/64-double Deken.
>>>>
>>>>
>>>> :)
>>>>
>>>> Mensaje telepatico asistido por maquinas.
>>>>
>>>>
>>>> ___
>>>> Pd-dev mailing list
>>>> Pd-dev@lists.iem.at
>>>> https://lists.puredata.info/listinfo/pd-dev
>>>>
>>>
>>> ___
>>> Pd-dev mailing list
>>> Pd-dev@lists.iem.at
>>> https://lists.puredata.info/listinfo/pd-dev
>
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Double precision externals extensions.

[Lucas Cordiviola]

On 12/10/2019 4:54 PM, IOhannes m zmölnig wrote:
> # avoiding crashes
> an external that has been compiled with single-precision will not
> register objectclasses in a double-precision Pd - so the doubl-precision
> Pd will not know about those new objects and not crash while using them.
> same goes for the other way round.

I see with normal externals itt refuses to load and thats fine.

But I'm creating a single binary external with a collection of authors 
[zexy] [cyclone] [ggee] [pddplink] ...

I create a setup for the lib and is working *OK* in Pd-w64-32 but it 
crashed the double precision.

this is my wrapper setup:

~~

#include "m_pd.h"

#include 
#include 


#ifdef __WIN32__
# define vsnprintf _vsnprintf
#endif



typedef struct liblucdep {
   t_object t_ob;
} t_liblucdep;

t_class *liblucdep_class=NULL;




static void *liblucdep_new(void)
{
   t_liblucdep *x = (t_liblucdep *)pd_new(liblucdep_class);
   return (x);
}

void liblucdep_setup(void)
{

   post("***");
   post("liblucdep loaded.");
   post("***");

   liblucdep_class = class_new(gensym("liblucdep"), liblucdep_new, 0, 
sizeof(t_liblucdep), 0, 0);


   /* ** */
   coll_setup();
   comment_setup();
   freeverb_tilde_setup();
   glue_setup();
   helplink_setup();
   image_setup();
   pddplink_setup();
   pink_tilde_setup();
   reson_tilde_setup();
   tabminmax_setup();
   time_setup();
   z_tilde_setup();
}


~


>
> # pkgs including both single- and double-precision externals
> a single external binary (say: "foo.dll") can hold both single-precision
> and double-precision variants of the [foo] object.


How is that?

As I am willing to contribute to the w32/64-double Deken.


:)

Mensaje telepatico asistido por maquinas.


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Double precision externals extensions.

[Lucas Cordiviola]

Ok. So why do I get a segfault on linux and a crash on windows

~~~

void pddplink_setup(void)

{

t_symbol *dirsym;

pddplink_class = class_new(gensym("pddplink"),

(t_newmethod)pddplink_new,

(t_method)pddplink_free,

sizeof(t_pddplink),

CLASS_NOINLET | CLASS_PATCHABLE,

A_GIMME, 0);

class_addanything(pddplink_class, pddplink_anything);

class_setwidget(pddplink_class, _widgetbehavior);

pddplinkbox_class = class_new(gensym("pddplink"), 0,

(t_method)pddplink_free,

sizeof(t_pddplink), 0, A_GIMME, 0);

class_addbang(pddplinkbox_class, pddplink_bang);

class_addanything(pddplinkbox_class, pddplink_anything);

class_addmethod(pddplinkbox_class, (t_method)pddplink_click,

gensym("click"),

A_FLOAT, A_FLOAT, A_FLOAT, A_FLOAT, A_FLOAT, 0);

dirsym = pddplink_class->c_externdir; /* FIXME */

sys_vgui("source {%s/pddplink.tcl}\n", dirsym->s_name);

}

~~



?

Mensaje telepatico asistido por maquinas.

On 12/10/19 7:45 PM, Christof Ressi wrote:
> > Is this: "A_FLOAT" forbidden?
> I'm not sure what you mean exactly, but A_FLOAT is an atom type, so 
> it's 100% unrelated to single/double precision.
> *Gesendet:* Dienstag, 10. Dezember 2019 um 23:37 Uhr
> *Von:* "Lucas Cordiviola" 
> *An:* "pd-dev@lists.iem.at" 
> *Betreff:* Re: [PD-dev] Double precision externals extensions.
>
> Is this: "A_FLOAT" forbidden?
>
> ~
>
> void pddplink_setup(void)
>
> {
>
> t_symbol *dirsym;
>
> pddplink_class = class_new(gensym("pddplink"),
>
> (t_newmethod)pddplink_new,
>
> (t_method)pddplink_free,
>
> sizeof(t_pddplink),
>
> CLASS_NOINLET | CLASS_PATCHABLE,
>
> A_GIMME, 0);
>
> class_addanything(pddplink_class, pddplink_anything);
>
> class_setwidget(pddplink_class, _widgetbehavior);
>
> pddplinkbox_class = class_new(gensym("pddplink"), 0,
>
> (t_method)pddplink_free,
>
> sizeof(t_pddplink), 0, A_GIMME, 0);
>
> class_addbang(pddplinkbox_class, pddplink_bang);
>
> class_addanything(pddplinkbox_class, pddplink_anything);
>
> class_addmethod(pddplinkbox_class, (t_method)pddplink_click,
>
> gensym("click"),
>
> A_FLOAT, A_FLOAT, A_FLOAT, A_FLOAT, A_FLOAT, 0);
>
> dirsym = pddplink_class->c_externdir; /* FIXME */
>
> sys_vgui("source {%s/pddplink.tcl}\n", dirsym->s_name);
>
> }
>
> ~
>
> Mensaje telepatico asistido por maquinas.
> On 12/10/19 7:30 PM, Lucas Cordiviola wrote:
>
> I get the segfault on linux (it also crashes Pd-double)
>
> ~~~
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x76170e93 in pddplink_setup ()
>    from
> 
> /home/lucarda/Desktop/luclibdep/00-lucarda-external-dep/out64single/lucdep/liblucdep.so
>
> ~~~
>
>
> :)
>
>
> Mensaje telepatico asistido por maquinas.
>
> On 12/10/19 7:06 PM, IOhannes m zmölnig wrote:
>
> On 12/10/19 10:48 PM, Christof Ressi wrote:
>
> I'm also interested in how this works. The following
> solution popped up in my head: compile the object twice,
> one time with -DPD_FLOATSIZE=32 and another time with
> -DPD_FLOATSIZE=64, with different setup functions based on
> -DPD_FLOATSIZE, then link it with a third file which
> exports the "real" setup function (which calls the other
> two private setup functions).
>
> that's about the idea.
>
> gdsa r
> IOhannes
>
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
> ___ Pd-dev mailing list 
> Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Double precision externals extensions.

[Lucas Cordiviola]

Thanks Christof now everything's fine and I learned how to use msys2 gdb 
compiling with "alldebug" with pd-lib-builder.

As for the "null pointer check" I just did this on pddplink_setup():

~

     if (dirsym) {
     dirsym = pddplink_class->c_externdir;  /* FIXME */
     sys_vgui("source {%s/pddplink.tcl}\n", dirsym->s_name);
     } else {
     dirsym = NULL;
     }

~

This is working for not crashing the incorrect precision Pd.


Side-note:

I can not statically link pthread (used by cyclon/coll) when compiling 
the lib with "make CPPFLAGS="-DPD_FLOATSIZE=64""

:(

Mensaje telepatico asistido por maquinas.

On 12/10/2019 10:29 PM, Christof Ressi wrote:
> ah, now I see! class_new() returns a null pointer if the precision doesn't 
> match. In pddplink_setup() they try to access members of the class instance, 
> that's why you get a segfault. Just add a null pointer check and you're done.
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Double precision externals extensions.

[Lucas Cordiviola]

On 12/11/2019 2:36 PM, IOhannes m zmölnig wrote:

> the proper condition is:
> if(pddplink_class) {
>dirsym=...
> } else {
>dirsym=NULL;
> }

Ok right, I posted what i did because I was not sure. Had fixed it :)

Coming back to the subject of this thread:

The combined single/double dll is a bit complicated (for example for me 
to just upload double precision versions of the so many unmaintained 
libs that I have been uploading to Deken this last year (almost all w64 
Deken).


Could we leave the combined dll just for experts and have a new defaults 
for double-precision?

Also this will shorten the possibilities of a crash. We don't want to go 
thru all sources and check if there's something like in pddplink.c that 
will cause a crash.

Also: You mention some time ago (when pd-w64 was released) the 
possibility to generate a "file" at compile time that stores current 
arch build. This file gets the "platform detected" info sooner than 
deken. We can also have the "precision" in that generated "file".



?

Mensaje telepatico asistido por maquinas.


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] Double precision externals extensions.

[Lucas Cordiviola]

Could we have special extension for double-precision external?

Something like foo.m_amd64dp ?

This way we can have external pkgs including both single and double 
externals.

Also instruct Pd to *not* try to load the not current precision and 
avoid crashes.



-- 
Mensaje telepatico asistido por maquinas.

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] switch bugs.puredata.info to github?

[Lucas Cordiviola]

I went ahead editing the old https://puredata.info/dev/BugTracker

Mensaje telepatico asistido por maquinas.

On 10/6/2019 5:36 PM, Federico Camara Halac wrote:
> +1 Perhaps it would also be useful to include a tiny issue template, 
> or some simple guidelines to include the minimum needed to understand 
> the issue; and, a link to the sourceforge if people don't want to join 
> github
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] switch bugs.puredata.info to github?

[Lucas Cordiviola]

I agree with the redirection to Github.


If for whatever reason we need to have both (github and sourceforge) we can 
redirect to some new page in puredata.info with a brief explanation:

~~~

Please include which OS and which Pd version you are using in the bug report.

You can use [Github/link] (You must have or create a Github account)

or you can use [Sourceforge/link] (tickets can be created anonymously or with 
an Sourceforge account)



Mensaje telepatico asistido por maquinas.

On 10/6/2019 5:36 PM, Federico Camara Halac wrote:
+1 Perhaps it would also be useful to include a tiny issue template, or some 
simple guidelines to include the minimum needed to understand the issue; and, a 
link to the sourceforge if people don't want to join github
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PD] double precision merged

[Lucas Cordiviola]

I have requested this as it will be more simple for me to upload 
double-precision externals builds from my current w64 deken (I have 
uploded (many, almost all) the with sources and pd-lib-builder so it 
shouldn't be hard to have windows32/windows64 double builds)



:)

Mensaje telepatico asistido por maquinas.

On 2/26/2020 11:40 AM, Lucas Cordiviola wrote:

I have also requested this:

https://lists.puredata.info/pipermail/pd-dev/2019-12/022203.html


:)

Mensaje telepatico asistido por maquinas.

On 2/26/2020 9:58 AM, Christof Ressi wrote:
I see you point and I think it's a philosophical issue. In 
Supercollider, for example, I can't compile a UGen plugin and expect 
it to run on both Scsynth and Supernova, I rather have to pass the 
correct define ("SUPERNOVA"). Plugins are therefore usually built 
twice - with and without "-DSUPERNOVA" - and since they have 
different extensions and export different symbols, they can coexist. 
I think this could be a solution for Pd as well. If we had some 
naming convention for double precision externals, we can then just 
built both versions unconditionally and Pd will load the correct 
version. This can be automated by pd-lib-builder.


Christof

On 26.02.2020 13:39, IOhannes m zmoelnig wrote:

On 26.02.20 13:00, Christof Ressi wrote:

I think I found it :-)

https://github.com/pure-data/pure-data/pull/807#issuecomment-561251729
thanks!


if we want to pass the selected precision on to the entire ecosystem
that depends on a given Pd runtime (that is: all externals that are
built against a specific version of Pd), than the only solution is to
replace the default value for PD_FLOATSIZE in m_pd.h.

I'm not sure I understand. Why do we have to change the default value?
If someone wants to compile double precision externals, they just have
to pass the -DPD_FLOATSIZE=64 to the build system (pd-lib-builder 
could



that's the point.

i don't want to "compile double precision externals".
i want to compile an external that works with the installed version of
Pd, no matter what endianness, data model or sample-type.

if the installed Pd has not been produced with a tweaked build
(overriding *FLAGS, using a non-standard compiler,...) then any 
external

that was built via the standard procedure (using default *FLAGS and
compiler,...) should "just work".

endianness, data model,... are kept consistent by using the "default"
compiler for your environment/OS.

sample-type is defined via a public header that comes with Pd.
why would it define a value that does not match the Pd runtime that
provides it?


enabling a feature via a configure-flag is (at least for me) a way of
saying that "from now on, whatever i do with the so-generated project
(Pd) will have this feature enabled".

I don't see the conflict, to be honest. Also, I don't think there's a
*practical* difference between setting a configure flag and setting 
the

CPPFLAGS variable.

that was my point: it's equally simple to use any of the two methods.
but using CPPFLAGS supposedly tells you that you are now cruising
dangerous waters. (some people might not smell any difference; but if
for them both options are the same, /they/ are not a compelling reason
to prefer one over the other)


In your example, both happen at configure time. The
big advantage of having a configure flag is that it is 
self-documenting

("./configure --help").

yes. that's the advantage.
i don't think it outweighs the drawback though.


just to make clear:
i'm not at all opposed to adding a configure flag to select the
precision (whether it's "--enable-double", "--enable-double-precision"
or "--enable-precision=double" doesn't matter though i like the latter
better).
but that flag should be reflected in the public API.

fgasdrm
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PD] double precision merged

[Lucas Cordiviola]

I have also requested this:

https://lists.puredata.info/pipermail/pd-dev/2019-12/022203.html


:)

Mensaje telepatico asistido por maquinas.

On 2/26/2020 9:58 AM, Christof Ressi wrote:
I see you point and I think it's a philosophical issue. In 
Supercollider, for example, I can't compile a UGen plugin and expect 
it to run on both Scsynth and Supernova, I rather have to pass the 
correct define ("SUPERNOVA"). Plugins are therefore usually built 
twice - with and without "-DSUPERNOVA" - and since they have different 
extensions and export different symbols, they can coexist. I think 
this could be a solution for Pd as well. If we had some naming 
convention for double precision externals, we can then just built both 
versions unconditionally and Pd will load the correct version. This 
can be automated by pd-lib-builder.


Christof

On 26.02.2020 13:39, IOhannes m zmoelnig wrote:

On 26.02.20 13:00, Christof Ressi wrote:

I think I found it :-)

https://github.com/pure-data/pure-data/pull/807#issuecomment-561251729
thanks!


if we want to pass the selected precision on to the entire ecosystem
that depends on a given Pd runtime (that is: all externals that are
built against a specific version of Pd), than the only solution is to
replace the default value for PD_FLOATSIZE in m_pd.h.

I'm not sure I understand. Why do we have to change the default value?
If someone wants to compile double precision externals, they just have
to pass the -DPD_FLOATSIZE=64 to the build system (pd-lib-builder could


that's the point.

i don't want to "compile double precision externals".
i want to compile an external that works with the installed version of
Pd, no matter what endianness, data model or sample-type.

if the installed Pd has not been produced with a tweaked build
(overriding *FLAGS, using a non-standard compiler,...) then any external
that was built via the standard procedure (using default *FLAGS and
compiler,...) should "just work".

endianness, data model,... are kept consistent by using the "default"
compiler for your environment/OS.

sample-type is defined via a public header that comes with Pd.
why would it define a value that does not match the Pd runtime that
provides it?


enabling a feature via a configure-flag is (at least for me) a way of
saying that "from now on, whatever i do with the so-generated project
(Pd) will have this feature enabled".

I don't see the conflict, to be honest. Also, I don't think there's a
*practical* difference between setting a configure flag and setting the
CPPFLAGS variable.

that was my point: it's equally simple to use any of the two methods.
but using CPPFLAGS supposedly tells you that you are now cruising
dangerous waters. (some people might not smell any difference; but if
for them both options are the same, /they/ are not a compelling reason
to prefer one over the other)


In your example, both happen at configure time. The
big advantage of having a configure flag is that it is self-documenting
("./configure --help").

yes. that's the advantage.
i don't think it outweighs the drawback though.


just to make clear:
i'm not at all opposed to adding a configure flag to select the
precision (whether it's "--enable-double", "--enable-double-precision"
or "--enable-precision=double" doesn't matter though i like the latter
better).
but that flag should be reflected in the public API.

fgasdrm
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] libraries that crash in a double-precision runtime

[Lucas Cordiviola]

sorry the txt was empty.

One more try.

see attached.

Mensaje telepatico asistido por maquinas.

On 3/6/2020 6:21 PM, Lucas Cordiviola wrote:

Hi Thomas,

The only thing I got from deken (for win64) was 
"purest_json[v1.4.3](Windows-amd64-64).dek"


Pd-double refuses to load it complaining:

"refusing to load 32bit-float object 'json-encode' into 64bit-float Pd"

Did you compiled it against a Pd-double?

In case you need a Pd-double compiled for win64 here is one:


The list think this link is spam so I'll try in an attached zip (just 
a txt with the link). see attached.






[1] I'm running a self-hosted instance of "Nextcloud" on an asus eeepc 
1GB-ram Intel Atom 32-bit 1.6-Ghz with debian/buster with an ADSL 
connection.


Mensaje telepatico asistido por maquinas.

On 3/6/2020 12:33 PM, Thomas Grill wrote:

Dear all,
i have published binaries on deken for many of my externals covering 
a lot of platforms and variants (i386/x86_64/arm6/arm7/arm64 on 
darwin/windows/linux, single and double precision floats).
Specifically, binaries for Windows and Pd double precision have been 
newly added. I am not able to test the externals on all platforms.
If you like, please give them a try and let me know should there be 
crashes or other problems.

best, Thomas
<>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Issues building PD 0.51.x

[Lucas Cordiviola]

Also note/try:

    $ ./autogen.sh
    $ ./configure
    $ make app

I'd never used:

    $ make all

--

Mensaje telepatico asistido por maquinas.

On 12/9/2020 11:53 AM, Christof Ressi wrote:



indicating that _WIN32 is not defined.
So if I instead build with CFLAGS=-D_WIN32, I get a different set of 
errors while building s_inter.c


If "_WIN32" is not defined by the compiler, something is going very 
wrong...


usr/lib/gcc/x86_64-pc-msys/10.2.0/../../../../x86_64-pc-msys/bin/ld: 
pd-s_audio_oss.o: in function `oss_open_audio':
This files should never be built on Windows in the first place. Can 
you post the full output of the "./configure" and "make" command and 
attach them as text files?


Just for the record, can you successfully build other software with 
Msys2? Just to rule out a general problem with your Msys2 installation.


Christof

On 09.12.2020 15:19, David Rush wrote:

Hi -

I imagine that this is somehow my mistake, but I am having persistent 
problems with building PD 0.51.x from git under the latest 
MSys2/Mingw64 gcc


    $ gcc --version
    gcc (GCC) 10.2.0
    Copyright (C) 2020 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  
There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A 
PARTICULAR PURPOSE.


    $ gcc -dumpmachine
    x86_64-pc-msys

The issues seem to center around various WIN32 compatibility hacks. 
If I use the usual


    $ ./autogen.sh
    $ ./configure
    $ make clean
    $ make all

the build fails while linking pd.exe

/usr/lib/gcc/x86_64-pc-msys/10.2.0/../../../../x86_64-pc-msys/bin/ld: 
pd-s_audio_oss.o: in function `oss_open_audio':
    /c/Users/User/git/pure-data/src/s_audio_oss.c:305: undefined 
reference to `sys_setalarm'
/c/Users/User/git/pure-data/src/s_audio_oss.c:305:(.text+0xee3): 
relocation truncated to fit: R_X86_64_PC32 against undefined symbol 
`sys_setalarm'
/usr/lib/gcc/x86_64-pc-msys/10.2.0/../../../../x86_64-pc-msys/bin/ld: 
/c/Users/User/git/pure-data/src/s_audio_oss.c:394: undefined 
reference to `sys_setalarm'


    

interestingly, that build also generates a warning message while 
compiling s_inter.c (which defines sys_setalarm() under the right set 
of compiler flags) indicating that _WIN32 is not defined.


    s_inter.c: In function ‘sys_init_deken’:
    s_inter.c:998:4: warning: #warning unknown OS [-Wcpp]
      998 | #  warning unknown OS

So if I instead build with CFLAGS=-D_WIN32, I get a different set of 
errors while building s_inter.c


    /usr/include/w32api/psdk_inc/_fd_types.h:100:2: warning: #warning 
"fd_set and associated macros have been defined in sys/types.     
 This can cause runtime problems with W32 sockets" [-Wcpp]
    /usr/include/w32api/winsock2.h:1025:34: error: conflicting types 
for ‘select’
    s_inter.c:217:52: warning: passing argument 5 of ‘select’ from 
incompatible pointer type [-Wincompatible-pointer-types]
    /usr/include/w32api/winsock2.h:1025:116: note: expected 
‘PTIMEVAL’ {aka ‘struct __ms_timeval * const’} but argument is of 
type ‘struct timeval *’
    s_inter.c:490:17: warning: implicit declaration of function 
‘write’; did you mean ‘fwrite’? [-Wimplicit-function-declaration]
    s_inter.c:1305:20: warning: implicit declaration of function 
‘_spawnl’; did you mean ‘spawnl’? [-Wimplicit-function-declaration]
    s_inter.c:1305:28: error: ‘P_NOWAIT’ undeclared (first use in 
this function)
    s_inter.c:1493:10: warning: implicit declaration of function 
‘_exit’ [-Wimplicit-function-declaration]
    s_inter.c:1493:10: warning: incompatible implicit declaration of 
built-in function ‘_exit’


Could someone please enlighten me? Or point me to relevant 
documentation? ig gcc 10.2.0 known to be problematic?


TIA
--
GPG Public key at http://cyber-rush.org/drr/gpg-public-key.txt 



___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PD] [PD-announce] Pd 0.513 test5 released

[Lucas Cordiviola]

Hi Miller,

On Windows 64bit builds starting from Pd 0.51.3-test2 you have switched 
tcl/tk-8.6.8(64bit) to 8.6.10(32bit).


Was it intentional to change the arch?

Pdfontloader.dll (64bit) has stopped loading and Pd falls-back to 
courier font.



--

Mensaje telepatico asistido por maquinas.

On 11/3/2020 12:54 AM, Miller Puckette via Pd-announce wrote:

Ok... test 5 now.  Improved Mac 10.15 permission stuff and some more bug fixes.

http://msp.ucsd.edu/software.htm
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-l...@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Lucas Cordiviola]

sh linuxdep32.sh
rm linuxdep32
~~~

However, the crucial part is that the included libfluidsynth.so should
not be "tainted" with support for all kinds of things. This means, you
can't take the one shipped by the distro.

Why not?



but according to the snippet, I'd suppose something like this:

---
define forLinux

ifeq ($(firstword $(subst -, ,$(shell $(CC) -dumpmachine))), i686)
 $(shell /bin/sh scripts/linuxdep32.sh)
 else
 $(shell /bin/sh scripts/linuxdep32.sh)
endif

endef

---



But then how do you know *where* to copy the .so files. I mean the 
output dir for fluid~.


I still don't know if its possible to do the "for files .." from inside 
the makefile. That will be cool : "for filename in foo cp $filename  
$installdir"


Now that i write this there might it sounds possible pass an argument to 
the script:


$(shell /bin/sh scripts/linuxdep32.sh $installdir)

had to check if this script runs after fluid~ was built.



However, the above detection fails for arm7 and it'll wrongly executes
scripts/linuxdep64.sh. I think instead of an if-else, it could detect
the arch and execute the appropriate script with arch in the name.



Can you check what gives info you an arm7 ik you do:

make allvars



Another thing about scripts/linuxdep*.sh script. I think they should
call cp with the -d flag. Without it, it creates three full copies of
the same .so file. With -d symlinks are preserved.
We can test that but the symlinks are in the original folder. May be 
they are needed as is.



Thing is I don't feel yet
sufficiently confident with these matters, but am happy to learn.

 Me to. :)

There is something i'm worried: I think this linux aproach does not 
loads sf3. as far from what i read (never used sound fonts or 
fluidsynth) the sf3 can have compressed audio files with 
FLAC/Vorvis/etc. These dependencies are there on the win and mac versions.


more:

My first shoot to compile on debian buster was

apt-cache search fluidsynth

I got that and a -dev pkg which i installed.

then the [fluid~] object didn't load saying:

fluid~.pd_linux: undefined symbol: fluid_synth_key_pressure

So then I compiled the latest fluidsynth and it worked.

Now I didn't get fluidsynth*2* whith apt-cache. Why you get the 
fluidsynth*2* pkg?



--

Mensaje telepatico asistido por maquinas.

On 1/8/2021 6:16 AM, Roman Haefeli wrote:

I took the liberty to move this over to pd-dev

On Fri, 2021-01-08 at 03:48 -0300, Alexandre Torres Porres wrote:

Em qui., 7 de jan. de 2021 às 20:07, Roman Haefeli <
reduz...@gmail.com> escreveu:

On Thu, 2021-01-07 at 00:14 -0300, Alexandre Torres Porres wrote:


we still need to sort this for linux,

Since you seem you got it sorted (and I figured out how to compile
fluidsynth with no additional deps)

how did that go?

I just updated pd-fluidsynth repo to get your and Lucas' most recent
changes. I didn't have to modify anything for the build process to
work.

~~~sh
cd pd-fluidsynth
make pkglibdir=$HOME/pd-src/workspace/Linux-arm7-32
make pkglibdir=$HOME/pd-src/workspace/Linux-arm7-32 install
cd $HOME/pd-src/workspace/Linux-arm7-32/fluid~
sh linuxdep32.sh
rm linuxdep32
~~~

However, the crucial part is that the included libfluidsynth.so should
not be "tainted" with support for all kinds of things. This means, you
can't take the one shipped by the distro.


  Can you describe the steps and put it in our readme (with a PR)?

You mean what steps were necessary to compile fluidsynth? I didn't have
to do anything suprising or special. I just had  to figure out how to
disable everything by reading the docs about building. This is what I
came up with (I hope it is correct and complete):

~~~sh
git clone https://github.com/FluidSynth/fluidsynth/
cd fluidsynth
mkdir build
cd build
cmake -Denable-libsndfile=off -Denable-jack=off -Denable-alsa=off 
-Denable-oss=off -Denable-pulseaudio=off -Denable-ladspa=off 
-Denable-aufile=off  -Denable-network=off  -Denable-ipv6=off 
-Denable-getopt=off -Denable-sdl2=off ..
make
sudo make install
~~~

After this, I compiled fluid~ with steps from above.

Regarding the makefile of pd-fluidsynth, I don't understand the purpose
of this section:

---
define forLinux

ifeq ($(firstword $(subst -, ,$(shell $(CC) -dumpmachine))), i686)
 datafiles += scripts/linuxdep32.sh
 else
 datafiles += scripts/linuxdep64.sh
endif

endef
---

Depending on which arch is detected, it'll add one or the other script
in the build result. I think what this is meant to do is to _execute_
the arch specific script, so that libraries get included. I'm not yet
familiar with makefiles to tell you just right away how this is done,
but according to the snippet, I'd suppose something like this:

---
define forLinux

ifeq ($(firstword $(subst -, ,$(shell $(CC) -dumpmachine))), i686)
 $(shell /bin/sh scripts/linuxdep32.sh)
 else
 $(shell /bin/sh scripts/linuxdep32.sh)
endif

endef
---

In order to include the additional dynamic 

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Lucas Cordiviola]

On 1/9/2021 7:38 PM, Alexandre Torres Porres wrote:
As I preannounced at one point earlier, and to the surprise of nobody, 
I have plans on integrating this into ELSE


Are you sure you want ELSE to be so difficult to build just for a single 
[fluidsynth~] object?



Mensaje telepatico asistido por maquinas.




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Lucas Cordiviola]

On 1/9/2021 2:39 PM, Alexandre Torres Porres wrote:
What feels sane for me is creating a new object, with a different name 
(fluidsynth~) and its own design that is cleaner and doesn't try to 
fix this compatibility issues, cause it's just a nightmare with no 
simple solution. I like the idea of making it more compatible to Pd 
Vanilla and take messages in a more straightforward way from its 
internals, and I could do that by having that as a default and just 
removing the "legacy" stuff. That would make it all much cleaner...



+1



Mensaje telepatico asistido por maquinas.




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[Lucas Cordiviola]

On 1/10/2021 6:06 PM, Roman Haefeli wrote:

 From what I understand, the
[fluidsynth~] external doesn't make use of this stuff, so there is no
point in bloating the library and the number of dependencies
unnecessarily.


We have and older Windows build system (which is more straight forward 
and can also be cross-compiled, not based on the msys2 pkg). This build 
does not use FLAC/Vorbis/OGG binaries. It just use libsndfile. We should 
re-consider if building with the bloated msys2 pkg is needed.


We should do some testing with compressed sf3 files. (I only tested the 
"hedOrgan-Soundfont-sf3.zip" and it works on both types of builds)



--

Mensaje telepatico asistido por maquinas.




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Cross compiling for windows from mac

[Lucas Cordiviola]

Hi,

May be others give further advise but roughly:

On 1/28/2021 4:21 PM, Eric Lennartson wrote:


So I have two questions.

A. How do I cross compile for windows from mac using pd-lib-builder 
and make?


Normally you can easily cross-compile to Windows from Linux. Not sure if 
its possible on macOS.



B. If someone cloned my repo to their windows machine, what would they 
need in order to compile using pd-lib-builder and make?


Yes. That's the standard procedure.



:)


Mensaje telepatico asistido por maquinas.




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Cross compiling for windows from mac

[Lucas Cordiviola]

On 1/28/2021 4:46 PM, Eric Lennartson wrote:
I'm sorry if I'm missing something, but what is the standard 
procedure? I'm asking on a very basic level. Is it that all you would 
have to do is clone the repo? There's no need to change the makefile 
in any manner?


Yes. For example you can compile https://github.com/porres/pd-cyclone 
 on win mac and linux. You can 
check the makefile: 
https://github.com/porres/pd-cyclone/blob/master/Makefile 



--


Mensaje telepatico asistido por maquinas.




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Scheme-for-Pd, how to release beta versions, call for testers

[Lucas Cordiviola]

Hi Iain,

I can give it a try on Windows and Linux. I can build for both.

repo?


Mensaje telepatico asistido por maquinas.

On 6/10/2021 5:19 PM, Iain Duncan wrote:
Hi folks, I'm only a few days away (I think!) from a first beta 
release for Scheme-for-Pd, and am wondering what I'm supposed to do 
for releasing to the early testers given I don't want to put it on 
Deken until it's had the tires well kicked...


Things I need to sort  - answers or pointers to where to read both 
appreciated:


Is it pretty common that people know how to build or should I prepare 
a binary for OSX and Windows?


If so, how is that normally bundled up? I need people to have 
external, the help patcher and also a set of scm files on their pd 
search path for it all to work.


Is there anyone who would be interested in testing out building and 
running, both from zipped up packages and cloning and building? 
There's a pretty extensive help file, and everything in it should 
"just work". (haha, we'll see about that!)


thanks
iain

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building with pdlib builder on windows

[Lucas Cordiviola]

Hi Ian,

any news on this?. I know you didn't ask but this notes i made a weeks 
ago might help.


https://nc.nubegris.com.ar/index.php/s/rMbXSrtRLzYWSDk

I got the object running and printing. not sure if it loads properly the 
.scm files. I got the same results as building for Linux.


Hope it helps.

:)

Mensaje telepatico asistido por maquinas.

On 6/14/2021 6:24 PM, Iain Duncan wrote:
great, thanks. I'll get back to you here if I can't figure it out, I 
appreciate the help!


iain


On Mon, Jun 14, 2021 at 1:52 PM Christof Ressi > wrote:


The recommended way is MinGW via msys2. See the "Windows" section
in https://github.com/pure-data/pure-data/blob/master/INSTALL.txt
.

Christof

On 14.06.2021 22:47, Iain Duncan wrote:

Hi folks, I know windows just enough to be dangerous to myself,
but would like to at least be able to prepare binaries of s4pd.
Wondering what the path of least resistance is to compiling on
windows these days if I'm using pd lib builder. ie mingq, cygwin,
virtual studio??

thanks
iain

___
Pd-dev mailing list
Pd-dev@lists.iem.at  
https://lists.puredata.info/listinfo/pd-dev  




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building with pdlib builder on windows

[Lucas Cordiviola]

Oh. I forget about this:

you have to copy "libwinpthread-1.dll" & "libdl.dll" (make sure the 
folder where you copy matches the arch of your build) from your msys2 
installation to the same folder where "s4pd.dll" is.


Mensaje telepatico asistido por maquinas.

On 6/25/2021 6:56 PM, Lucas Cordiviola wrote:

Hi Ian,

any news on this?. I know you didn't ask but this notes i made a weeks 
ago might help.


https://nc.nubegris.com.ar/index.php/s/rMbXSrtRLzYWSDk

I got the object running and printing. not sure if it loads properly 
the .scm files. I got the same results as building for Linux.


Hope it helps.

:)

Mensaje telepatico asistido por maquinas.

On 6/14/2021 6:24 PM, Iain Duncan wrote:
great, thanks. I'll get back to you here if I can't figure it out, I 
appreciate the help!


iain


On Mon, Jun 14, 2021 at 1:52 PM Christof Ressi 
mailto:i...@christofressi.com>> wrote:


    The recommended way is MinGW via msys2. See the "Windows" section
    in https://github.com/pure-data/pure-data/blob/master/INSTALL.txt
<https://github.com/pure-data/pure-data/blob/master/INSTALL.txt>.

    Christof

    On 14.06.2021 22:47, Iain Duncan wrote:

    Hi folks, I know windows just enough to be dangerous to myself,
    but would like to at least be able to prepare binaries of s4pd.
    Wondering what the path of least resistance is to compiling on
    windows these days if I'm using pd lib builder. ie mingq, cygwin,
    virtual studio??

    thanks
    iain

    ___
    Pd-dev mailing list
    Pd-dev@lists.iem.at  <mailto:Pd-dev@lists.iem.at>
    https://lists.puredata.info/listinfo/pd-dev 
<https://lists.puredata.info/listinfo/pd-dev>



___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Modified [partconv~] and issues with fftw3

[Lucas Cordiviola]

This is the Makefile from my Deken pkg (with sources) for Windows-amd64:

bsaylor[v0.1.4](Windows-amd64-32)(Sources).dek
    Uploaded by lucarda @ 2018-09-29 11:33:54



~~~
class.sources = aenv~.c partconv~.c pvoc~.c susloop~.c svf~.c zhzxh~.c


ldlibs = -lfftw3 -lfftw3f -lpthread




include pd-lib-builder/Makefile.pdlibbuilder

#
#
#
# sources from https://packages.debian.org/source/stable/pd-bsaylor
#
# Source Package: pd-bsaylor (0.1-4)
#
#
# patched from pd-bsaylor_0.1-4.debian.tar.xz
#
# MinGW needs this package:
# mingw64/mingw-w64-x86_64-fftw
~~~



You have to install (from the msys2 shell) the fftw library (check which 
arch to install) with:


    pacman -Ss fftw

then to install do (to install the amd64 version):

    pacman -S mingw64/mingw-w64-x86_64-fftw

Then you can build directly from the MinGW64 shell (or MinGW32 shell if 
you build for i386) with:


    make

Or if you are using your makefile add the linker flags "-lfftw3 -lfftw3f 
-lpthread". (i can't remember how to do this with code::blocks but I'm 
sure you can).


PS: then you need to copy files "libfftw3-3.dll libfftw3f-3.dll" from 
somewhere in your compiler folder to the same folder as your externals.



Hope it helps.

:)

Mensaje telepatico asistido por maquinas.

On 4/7/2021 3:54 AM, Gloria Dal Santo wrote:


Hi everyone!

I’m trying to create a sort of 3d audio reproduction system by 
convolving the dry sound with the BRIRs of a room.


The patch I’m working on will be connected to a head-tracker so that I 
can change BRIR depending on the position of the listener.


To achieve this I tried to use bsaylor’s  [partconv~] but 
unfortunately, when I set a new impulse response, I have a short dead 
time. To fix this I tried to cross fade the output of two [partconv~] 
but this messes up the binaural cues, it is not the right approach.


My idea is that of modifying the .c code of the external to get what I 
need. Usually, I work on Code::Blocks, MinGW compiler, Win10. I’ve 
already built some super simple externals, but this time I’m facing a 
problem that I’ve never encountered before: to perform the Fourier 
transform, partconv~.c uses the fftw3 library, and  I couldn’t find a 
way to add it to the Linker Options.


From what I’ve understood online, fftw3 is a dynamic library, 
therefore there’s no .lib file. On Code::Blocks Settings -> Compiler 
-> Linker Settings -> Link libraries I cannot load a .dll dynamic 
library. I tried different solutions that I found online but none of 
those worked. I get “undefined reference to” errors when calling all 
the fftw3 functions.


Can any of you help me somehow? If you were able to write an external 
that referred to the fftw3 library, how was your setup?


Moreover, I saw that in the bsaylor’s  library folder there are also 
files of the type .dsp, .dsw, .o. Once I modify the .c code, should I 
update those as well?


I hope that I stated my issue clearly, if now please ask me for 
further details.


Thank you in advance for your time.

Gloria


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] "extra" folder is not showing its content in Pd's browser.

[Lucas Cordiviola]

Building the current (571ad34) on Linux/Win the extra folder is not 
shown in Pd's Browser.


--
Mensaje telepatico asistido por maquinas.




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Pd breaks zexy (?)

[Lucas Cordiviola]

I bet a lot of other stuff will turn out to be broken, hmm.



get_sys_sleepgrain() and the just removed:

    EXTERN void sys_clearhist(void);
    EXTERN int sys_addhist(int phase);

will surely break Pdvst~

From looking at:

https://github.com/jyg/PdVst/search?q=sys_clearhist

https://github.com/jyg/PdVst/search?q=sys_addhist


Pdvst~ is not much active but I think mainly because it works :)
At least I use it.


--

Mensaje telepatico asistido por maquinas.

On 8/20/2021 4:42 PM, Miller Puckette via Pd-dev wrote:

Well, I've never been able to articulate a clear and complete policy...
Roughly speaking, I'm maintaining source and binary compatibility for anything
that uses the public API (m_pd.h) and trying not to break things that use
private APIs (g_vanas.h, s_stuff.h and, privater still, m_imp.h").  Meanwhile
there's a profusion of ".h" files I didn't write (d_soundfile.h, g_all_guis.h,
etc) that I've never formed a policy for.

In the case of get_sys_sleepgrain() I can write a new implementation that
should work - in fact that might even be a good idea fro otehr reasons :) -
but there's a lot more that I've changed in s_stuff.h, since I've revamped
the whole audio interface.  I bet a lot of other stuff will turn out to
be broken, hmm.

Miller

On Fri, Aug 20, 2021 at 05:23:18PM +0200, Roman Haefeli wrote:

Hi all

I just compiled Pd from master and found that I cannot load [fifop]
from zexy anymore. When loading it, I get:

~~~
error: /home/roman/Documents/Pd/externals/zexy/zexy.pd_linux: 
/home/roman/Documents/Pd/externals/zexy/zexy.pd_linux: undefined symbol: 
get_sys_sleepgrain
  fifop
error: ... couldn't create
~~~

I believe the related commit in Pd is 95b61465.

I haven't tried re-compiling zexy yet, because I am under the
impression that Pd shouldn't break existing externals. I'm using 2.3.1
from Deken.

Roman







___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev






___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] "extra" folder is not showing its content in Pd's browser.

[Lucas Cordiviola]

thanks!


:)

Mensaje telepatico asistido por maquinas.

On 9/1/2021 9:29 AM, Antoine Rousseau wrote:


I'm preparing a PR.

done: https://github.com/pure-data/pure-data/pull/1372 
<https://github.com/pure-data/pure-data/pull/1372>



Le mer. 1 sept. 2021 à 13:30, Antoine Rousseau <mailto:anto...@metalu.net>> a écrit :



the problem is that s_main::sys_main() first calls
s_inter::sys_startgui(), which calls s_inter::sys_do_startgui()
which then calls s_path::sys_set_extrapath() (send extrapath to GUI),
before it calls s_main::sys_afterargparse() which calls
s_path::sys_setextrapath (init extrapath for the OS).

I suggest just calling sys_afterargparse() before sys_startgui().

I'm preparing a PR.



Le mer. 1 sept. 2021 à 12:13, Antoine Rousseau mailto:anto...@metalu.net>> a écrit :

confirmed here (linux).
seems to happen since 95b614656cd62214d6779014e5173d8af697814b
(2021-08-18 23:57:14   "simplified audio device handling and
scheduler")



    Le mar. 31 août 2021 à 11:36, Lucas Cordiviola
mailto:lucard...@hotmail.com>> a écrit :

Building the current (571ad34) on Linux/Win the extra
folder is not
shown in Pd's Browser.

-- 
Mensaje telepatico asistido por maquinas.





___
Pd-dev mailing list
Pd-dev@lists.iem.at <mailto:Pd-dev@lists.iem.at>
https://lists.puredata.info/listinfo/pd-dev
<https://lists.puredata.info/listinfo/pd-dev>


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Helping with building Scheme for Pure Data for windows?

[Lucas Cordiviola]

Hi Iain,

I don't have time right now to learn scheme but surely can help building 
for Windows.


Are you already on Windows machine?

If you like we continue off-list.



--

Mensaje telepatico asistido por maquinas.

On 10/10/2021 2:10 PM, Alexandre Torres Porres wrote:

Lucas usually helps with that ;)

Em dom., 10 de out. de 2021 às 13:39, Iain Duncan 
 escreveu:


Long shot, but in case there is someone on here who is a) excited
about using Scheme in Pd, and b) conversant with building
externals for windows,  I could definitely do with some help. I
really only know developing on linux and osx. I'm sure I'll manage
on my own, but it will be slower and harder to prioritize.

thanks!
iain

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev





___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] call for discussion double-precision file extension

[Lucas Cordiviola]

Joining the discussion:

I think the "deken-specifier" is Ok.

We should probably be prepared for both apps installations coexisting. 
In the case of Windows we should have a different default location and a 
name for the double app. Think of Pd-double whose default installation 
via the installer lives next to the single precision app:


C:\Program Files\Pd

C:\Program Files\Pd-double.

"Pd-double" can be anything better or whatever.

I think we can live sharing the same "Windows registry settings" for 
both apps.


We need the different app name not only for Windows. Thinking of the 
debian package and of course the macos app.



--

Mensaje telepatico asistido por maquinas.





___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] https, msp.ucsd.edu and file downloads.

[Lucas Cordiviola]

Miller, this might leave many (using the latest chrome web browser) 
scratching their heads:


if I follow instructions to get the latest Pd from 
https://msp.ucsd.edu/software.htm when i click to download any of the 
files nothing happens and no files get downloaded. If I start a console 
I see:


```
software.htm:1 Mixed Content: The site at 'https://msp.ucsd.edu/' was 
loaded over a secure connection, but the file at 
'https://msp.ucsd.edu/Software/pd-0.54-1test1.windows-installer.exe' was 
redirected through an insecure connection. This file should be served 
over HTTPS. See 
https://blog.chromium.org/2020/02/protecting-users-from-insecure.html 
for more details.

```

i think the problematic redirection happens in the links in file 
`software.htm` :


    http://msp.ucsd.edu/$$$;>

where 'http' is used.

---

may be the safer way to allow links to work on both types of connections 
(http and https) is to give relative URLs (stripping 'http://msp.ucsd.edu')


    

there might be other ways.

---

if i use the non-secure site all files can be downloaded normally.



--
Mensaje telepatico asistido por maquinas.




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] time for a quick bugfix update?

[Lucas Cordiviola]

Hi Miller,

There's also a Windows installer update the didn't make it to `develop`. 
I think it will be good to have it in a test version.


may be you can do a local merge?

branch: `Lucarda:nsis-safer`

https://github.com/pure-data/pure-data/pull/2067


--

Mensaje telepatico asistido por maquinas.

On 23/10/2023 06:56, Miller Puckette wrote:

Hi list -

I've merged the update and documentation branches, and will merge the 
translation support pretty soon.


I don't know where in Iohannes's CI scripts the TCL/TK version gets 
specified for MacOS (and I can't get to a Macintosh until next week 
maybe to check this)... so will have to wait for word from Iohannes as 
to when I can grab a TCL-TK-correct version from CI.  Once I believe 
that's in place I'll imeddiately put out a 'test' version of 0.54-1...


cheers

Miller





___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] time for a quick bugfix update?

[Lucas Cordiviola]

yes, correct. the commits from the PR are in `master` branch now.


:)

Mensaje telepatico asistido por maquinas.

On 23/10/2023 07:43, Miller Puckette wrote:
I think I have it merged now... can you check I got the merge done 
correctly ?




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] time for a quick bugfix update?

[Lucas Cordiviola]

Miller there's also https://github.com/pure-data/pure-data/pull/2040 
with html updates



--

Mensaje telepatico asistido por maquinas.





___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] release time?

[Lucas Cordiviola]

html: there's branch 
https://github.com/pure-data/pure-data/tree/htmldocs with no PR. It 
mostly contains updates to chapter6. you can do a local merge.




--

Mensaje telepatico asistido por maquinas.

On 27/11/2022 14:57, Miller Puckette via Pd-dev wrote:

TO pd dev -

I'm fixing to make a bugfix release.  I just merged 'develop' and 
'Documentation'.
Anything else (fixes only, please, no new features) that I should look at?

thanks
Miller




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PD] 0.54-0test2 released

[Lucas Cordiviola]

there is a last minute edit to the manual which covers the new file 
extensions and build instructions for Pd64.


https://github.com/pure-data/pure-data/pull/2040



--

Mensaje telepatico asistido por maquinas.





___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] windows installer > 0.54-0

[Lucas Cordiviola]

there are a couple of things i must do but i should ask first:

1. "winget install puredata"

i tried to be smart and always trigger "interactive installs" and test 
it locally but when i tried to add the package friendly people from 
Microsoft didn't approve it and they are right :)


see: 
https://github.com/microsoft/winget-pkgs/pull/111566#issuecomment-1625580667




2. "Wipe prefs"

i'm not really sure if this is needed but may be useful if prefs are 
stopping people from loading the app (as it was reported by oliver: 
https://lists.puredata.info/pipermail/pd-list/2023-06/132360.html )


actually we have a radio button menu for

    [ ] run the uninstaller
    [ ] continue

we can add

    [ ] clear Pd prefs and exit (try this if Pd is not loading anymore)




3. "make the uninstaller recursively delete install path"

actually this is not happening but if someone is running the installer 
without an uninstall, files that changed names get accumulated and 
successive uninstalls loose track of them. this can lead to people 
browsing "reference" or "examples" not meant for their pd-version




thoughts welcomed :)


lucarda


--
Mensaje telepatico asistido por maquinas.




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] double precision pd?

[Lucas Cordiviola]

How hard it would be to have both apps together in a single "Pure data" 
package:


$ pd

$ pd64

?


--

Mensaje telepatico asistido por maquinas.

On 07/06/2023 16:25, cyrille henry wrote:

Hello,
BTW, did anyone made a benchmark :
"pd double" will of course be lot's slower on 32 bit architecture, but 
what about 64 bit architecture?
Will "pd double" perform as fast as "pd float" on modern computer? or 
do we need to have both version installed on the same computer? (some 
patch need to be fast, other need precision...)


Cheers
c




Le 03/06/2023 à 20:02, Alexandre Torres Porres a écrit :
Hi, with pd 0.54-0 round the corner, what is still preventing us from 
shipping double precision pd downloads?


been waiting on it for a while now

cheers

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] double precision pd?

[Lucas Cordiviola]

How hard it would be to have both apps together in a single "Pure 
data" package:



Oh no, compilation will be complex.


--

Mensaje telepatico asistido por maquinas.




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] double precision pd?

[Lucas Cordiviola]

Funnily, my personal feeling is the opposite :-)
I feel that Pd64 clearly describes Pd working with 64 bit data.



I myself don't have any trouble with whatever name we use as I know 
perfectly well the situation. My trouble with Pd64 is that it will get 
listed next to Pd in almost any package manager and may be many people 
opt Pd64 (thinking that is the one for 64bit cpus)


Pd2 is also a good one.


--

Mensaje telepatico asistido por maquinas.

On 07/06/2023 07:55, Antoine Rousseau wrote:
Le mer. 7 juin 2023 à 10:47, Lucas Cordiviola  
a écrit :


For me pd64 gives more chances of confusion than pdd or pdpd.

 (...)

Starting with a new name of the app seems the most sane.


Funnily, my personal feeling is the opposite :-)
I feel that Pd64 clearly describes Pd working with 64 bit data.
I think that confusion with 64 bit architectures will become less 
present, since nowadays most (all?) major platforms are based on 64 
bit CPUs. So "64 bit" is just a particular taste of CPUs, as in x86_64 
or arm64, which has no direct impact from the user's point of view. If 
you want to work with 64bit-wide data on a 32bit PPC, you just need 
Pd64-PPC32, on arm64 it will be Pd64-arm64.


To me, "pdd" or "pdpd" really sound like different apps, which I find 
a bit strange (it's actually the same app, only different options).

I quite like Pd² or even Pd2, though.


.




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] double precision pd?

[Lucas Cordiviola]

For me pd64 gives more chances of confusion than pdd or pdpd.

Apart from the name of the app we should try to give this new app as 
much separation of Pd's paths and preferences as we can.


Starting with a new name of the app seems the most sane.


--

Mensaje telepatico asistido por maquinas.

On 05/06/2023 14:23, Dan Wilcox wrote:

On Mon, 2023-06-05 at 11:46 +0200, Miller Puckette wrote:
Pdouble?

Pd?

pdpd?

enohp ym morf tnes
---
Dan Wilcox
danomatika.com
robotcowboy.com



___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] double precision pd?

[Lucas Cordiviola]

Not really that we have to do this but:

Surely we need 2 compilations but in my head it does not hurt much that 
certain files have their "64" appended in the filename and share the 
same bin and extra dir.


like

pd/bin
    pd.exe
    pd64.exe
    pd.com
    pd64.com
    pd.dll
    pd64.dll
    pdreceive.exe
    pdreceive64.exe
    pdsend.exe
    pdsend64.exe

pd/extra
    bob~/
    bob~.dll
    bob~.Windows-amd64-64.dll
    ...

pd-lib-builder can easily be instructed to pick pd64.dll for a double build.

This should also work on Linux and macOS apps.

building should look like:

    make
    make clean
    make64

"make64" rename and copies the files on target.

if this is feasible we avoid having tons of duplicate .pd files and 
stuff and also having 2 different packages.


just thinking




--

Mensaje telepatico asistido por maquinas.

On 12/06/2023 07:21, Dan Wilcox wrote:
My gut feeling is that this is best kept as two separate builds for 
the platform. IMO we don't want to have to resort to a lot of trickery 
fighting the system's preferred modus operandi as it will, as you 
write, likely blow up in our faces.



On Jun 12, 2023, at 12:00 PM, pd-dev-requ...@lists.iem.at wrote:

Message: 1
Date: Mon, 12 Jun 2023 09:08:36 +0200
From: IOhannes m zm?lnig 
To:pd-dev@lists.iem.at
Subject: Re: [PD-dev] double precision pd?
Message-ID: 
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On 6/8/23 15:23, IOhannes m zm?lnig wrote:

Oh no, compilation will be complex.


Not really.
You basically have to build twice...


oh no, i forgot about the intricacies of the windows build.

with macOS and Linux we have this nice single "pd" binary (or "pd64").
but with Windows we need the supporting pd.dll library where all the
guts live (so externals have something to link against), and as of now,
double-precision externals on Windows will link against pd.dll as well
(but expect that to be contain the double-variant).



Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] windows installer > 0.54-0

[Lucas Cordiviola]

On 10/07/2023 06:58, Christof Ressi wrote:

3. "make the uninstaller recursively delete install path"


Yes, we should definitely do this.


I changed my mind on this because someone might choose d:\my-value-stuff 
in the install dir but had forgot to append the "\pd" at the end of the 
path. then when seeing the mistake attempts to perform an uninstall and 
yes, all d:\my-value-stuff\ is gone. :(



I made a PR with lots of improvements: 
https://github.com/pure-data/pure-data/pull/2067



Lucarda

--

Mensaje telepatico asistido por maquinas.
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] switching app-id to info.puredata.pd?

[Lucas Cordiviola]

On 10/08/2023 12:52, IOhannes m zmölnig wrote:
what do you think? 



From my Windows POV i see no objection to do the change if needed.

If you can't get in touch with A.van de Ven that's bad. i think is 
better that IEM can prove or handle this type of stuff.



--

Mensaje telepatico asistido por maquinas.





___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] compiling externals with gnu gsl library

[Lucas Cordiviola]

Hi,

https://www.gnu.org/software/gsl/doc/html/usage.html#shared-libraries

you can define for all OSs in the main makefile:

ldlibs += -static -lgsl

or for an specific OS (also in the main makefile)

define forWindows
    ldlibs += -static -lgsl
endef


untested.


Lucarda.

Mensaje telepatico asistido por maquinas.

On 08/08/2023 22:22, Vinicius Cesar wrote:
I'm trying to compile an object with pd-lib-builder that uses the gnu 
gsl library on the code. I would like to compile this object in a way 
that the gsl library stays statically linked so it could run on other 
computers without the need to install the gsl. How can I do this using 
pd-lib-builder?

Thanks!




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] Help: How to emulate a larger block size?

[Lucas Cordiviola]

Hi list,

Coming from 
https://lists.puredata.info/pipermail/pd-list/2023-11/132742.html to the 
dev list as this more for C code.


I have a working DSP object @ 
https://github.com/Lucarda/pulqui-tilde/blob/main/pulqui%7E.c but for 
now it only works on a re-blocked sub patch (4096 samples).


Can anyone point me on a direction to make an artificial larger block 
from an 64 block? Any object as an example I should see?


Thanks

:)

--
Mensaje telepatico asistido por maquinas.




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Help: How to emulate a larger block size?

[Lucas Cordiviola]

On 23/11/2023 14:27, Christof Ressi wrote:
Have a look at [env~]. 


Thanks.

--

Mensaje telepatico asistido por maquinas.




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] How to free memory of t_symbol

[Lucas Cordiviola]

hi,


 free(x_biases_array) doesn't seem to work



i'm not to good at C but you are missing the correct path 
("nameofthestruct"->"nameofthevarible"). like


    free(x->x_biases_array).


--

Mensaje telepatico asistido por maquinas.

On 22/02/2024 06:19, Alexandros Drymonitis wrote:
I have a data structure with a symbol and an array of symbols that 
store array names defined as:


```
t_symbol **x_weights_arrays;
t_symbol *x_biases_array;
```

When I'm done with them, I want to free the memory, but calling 
free(x_biases_array) doesn't seem to work, and once called, as soon as 
I try to do something else in Pd (like unlock the patch and choose an 
object), Pd crashes.


I have narrowed down the error to freeing these symbols, and I'm sure 
the crash is not caused by something else. I scanned m_pd.h to see if 
there is a function to free t_symbol memory, but didn't seem to find 
anything. This might be something obvious for C-savvy people, but I'm 
not one, so any advice is welcome.





___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] Pd running on external scheduler changed

[Lucas Cordiviola]

Hi,

I'm working with some new feature of pdvst~ 
(https://git.nubegris.com.ar/lucarda/pdvst-0.52/compare/master...sq-fudi) 
this runs Pd via external scheduler "vstscheduler.dll"


I hit some strange issue with current Pd (Merge branch 'scheduler_fix' 
2bea249)


this message no longer works

--
;
pd dsp 1;
--


while this one works

[dsp 1(
|
[s pd]

is not something I changed in pdvst~. Is something that only exhibits 
with the newest Pd.


I can live with it but may be this is some "peak of iceberg" ?


--

--
Mensaje telepatico asistido por maquinas.




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Pd running on external scheduler changed

[Lucas Cordiviola]

Ok, no rushing if you are traveling.

First, what exactly does "not work"? 


---
;
pd dsp 1;
---

does not start dsp (the toggle in the main Pd window never gets to "on")

Second, these two message should obviously be equivalent. Are you 
really sure that they behave differently?


yes.

[dsp 1(
|
[s pd]

works.

If yes, that would be a bug in Pd's message system, not in my 
scheduler updates.


I could check that the messaging system for other receivers work like [; 
foo 3( works as expected with [r foo].


When I made the updates, I tried not to break the external scheduler 
mechanism and checked that pd~ still works.


yes. pd~ still works.

Maybe it's an issue in your scheduler implementation? 


nothing changed in pdvst~ scheduler implementation (well yes, but using 
the unchanged version the issue is still there on current master Pd and 
not with Pd 0.54-1).



I'll need to have a look at your code, ...


sure: 
https://git.nubegris.com.ar/lucarda/pdvst-0.52/src/branch/sq-fudi/vst-scheduler/vstschedlib.c


you could also see the "master" branch but as mentioned it also exhibits 
the issue.




--

Mensaje telepatico asistido por maquinas.

On 24/04/2024 06:40, Christof Ressi wrote:


On 24.04.2024 09:45, Lucas Cordiviola wrote:

Hi,

I'm working with some new feature of pdvst~ 
(https://git.nubegris.com.ar/lucarda/pdvst-0.52/compare/master...sq-fudi) 
this runs Pd via external scheduler "vstscheduler.dll"


I hit some strange issue with current Pd (Merge branch 
'scheduler_fix' 2bea249)


this message no longer works

--
;
pd dsp 1;
--


while this one works

[dsp 1(
|
[s pd]


First, what exactly does "not work"? Second, these two message should 
obviously be equivalent. Are you really sure that they behave 
differently? If yes, that would be a bug in Pd's message system, not 
in my scheduler updates.


When I made the updates, I tried not to break the external scheduler 
mechanism and checked that pd~ still works. Maybe it's an issue in 
your scheduler implementation? I'll need to have a look at your code, 
but I'm travelling right now.




is not something I changed in pdvst~. Is something that only exhibits 
with the newest Pd.


I can live with it but may be this is some "peak of iceberg" ?


--







___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Pd running on external scheduler changed

[Lucas Cordiviola]

Christof,

looking closer this looks like a false alarm.

further testing showed that

[loadbang]
|
[; pd dsp 1;(

indeed not show dsp toggle ticked but actually dsp is running.

if i do

[; pd dsp 0;(

and then

[; pd dsp 1;(

the toggle shows ticked.

there might be just something in the initial loading. also note this is 
using the 32bit tcl/tk coming from a normal self built latest Pd.


Sorry for the noise.


--

Mensaje telepatico asistido por maquinas.

On 24/04/2024 07:24, Lucas Cordiviola wrote:

Ok, no rushing if you are traveling.

First, what exactly does "not work"? 


---
;
pd dsp 1;
---

does not start dsp (the toggle in the main Pd window never gets to "on")

Second, these two message should obviously be equivalent. Are you 
really sure that they behave differently?


yes.

[dsp 1(
|
[s pd]

works.

If yes, that would be a bug in Pd's message system, not in my 
scheduler updates.


I could check that the messaging system for other receivers work like 
[; foo 3( works as expected with [r foo].


When I made the updates, I tried not to break the external scheduler 
mechanism and checked that pd~ still works.


yes. pd~ still works.

Maybe it's an issue in your scheduler implementation? 


nothing changed in pdvst~ scheduler implementation (well yes, but 
using the unchanged version the issue is still there on current master 
Pd and not with Pd 0.54-1).



I'll need to have a look at your code, ...


sure: 
https://git.nubegris.com.ar/lucarda/pdvst-0.52/src/branch/sq-fudi/vst-scheduler/vstschedlib.c


you could also see the "master" branch but as mentioned it also 
exhibits the issue.




--

Mensaje telepatico asistido por maquinas.

On 24/04/2024 06:40, Christof Ressi wrote:


On 24.04.2024 09:45, Lucas Cordiviola wrote:

Hi,

I'm working with some new feature of pdvst~ 
(https://git.nubegris.com.ar/lucarda/pdvst-0.52/compare/master...sq-fudi) 
this runs Pd via external scheduler "vstscheduler.dll"


I hit some strange issue with current Pd (Merge branch 
'scheduler_fix' 2bea249)


this message no longer works

--
;
pd dsp 1;
--


while this one works

[dsp 1(
|
[s pd]


First, what exactly does "not work"? Second, these two message should 
obviously be equivalent. Are you really sure that they behave 
differently? If yes, that would be a bug in Pd's message system, not 
in my scheduler updates.


When I made the updates, I tried not to break the external scheduler 
mechanism and checked that pd~ still works. Maybe it's an issue in 
your scheduler implementation? I'll need to have a look at your code, 
but I'm travelling right now.




is not something I changed in pdvst~. Is something that only 
exhibits with the newest Pd.


I can live with it but may be this is some "peak of iceberg" ?


--









___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev