Ok, this confirms umlaeute's PR and comments on my github repo.
His PR uses the garray_getfloatwords function and copies the contents to
a float array to make it accessible to the c++ code.
It works very well (at least on my osx 32 bit pd), but I really dislike
the waste of CPU it takes to duplicate all this data.
umlaeute also pointed me to a stride-based solution, which I think is
the good direction to follow, so this is what I'm considering right now.
Thanks to both of you for this very useful and cross-validated tip :)
Le 08/11/18 à 17:54, Christof Ressi a écrit :
in your case, casting definitly won't work in 64 bit Pd because a t_word is
64bit (the largest union member is a pointer) while a float is only 32 bit, so
every other float would be garbage.
you *could* introduce an optional stride value in bytes to your API by which
you advance the pointers. but I would start with simply copying the array data
and profile.
Gesendet: Donnerstag, 08. November 2018 um 16:50 Uhr
Von: "Joseph Larralde" <[email protected]>
An: "Christof Ressi" <[email protected]>, Pd-List <[email protected]>
Betreff: Re: [PD] [PD-announce] jl lib
Hmmm, that's what I was fearing.
In my c++ lib I read the buffers/tables contents passing them as
pointers to floats/doubles.
I'm not sure I can do this anymore with t_words, without either copying
the whole buffer to provide a simple pointer to it,
or modifying the c++ API in some other way, using getters ore some other
trick.
Le 08/11/18 à 15:12, Christof Ressi a écrit :
If one can just cast a t_word into a float or a double, things should go
smoothly.
the proper way is to access the union member of t_word, e.g.:
myarray[0].w_float;
Gesendet: Donnerstag, 08. November 2018 um 14:40 Uhr
Von: "Lucas Cordiviola" <[email protected]>
An: "Joseph Larralde" <[email protected]>, "[email protected]"
<[email protected]>
Betreff: Re: [PD] [PD-announce] jl lib
On 11/8/2018 10:00 AM, Joseph Larralde wrote:Hi Lucas,
Thanks a lot for the hints !
I'm curious to know how you compiled the win64 version.
>From what I remember, I installed msys2 and could only compile using the 32
bit version.
pd-lib-builder is ready to use 32 and 64 bit Pds if they are in the default
location:
32bit: C:\Program Files (x86)\pd
64bit: C:\Program Files\pd
If you like you can specify any other dir when calling make:
make PDDIR=your/path/to/pd
On Msys2 you have to install the 64bit compiler (you probably did) :
pacman -S mingw64/mingw-w64-x86_64-gcc
Later I added the [tonnetz] object to the library and had to add the "cflags =
-std=c++11" line in the makefile
in order for it to compile (because of some c++ vector initializers I
introduced in my underlying c++ lib).
Then I didn't push my investigations forward because ATM I was happy enough
with the windows 32 bit version
and had a working fat external for mac.Just curious:
you don't get the "failed since it uses garray_getfloatarray while running
64-bit!" on OSX 64bit Pd?
That's good to know that I just need to add a "+" to the makefile to get the lib to compile for windows 64 bit,
and, apparently, to get all objects to work except gbend~ (if I understood
correctly what you implied).
I opened "jl-objects.pd" and all objects get created, then i started testing at random
and when I opened "gbend~" help I spotted the error in the console.
I'll try the changes that you suggested.
I hope I won't have to rewrite a part of my underlying lib's API.
If one can just cast a t_word into a float or a double, things should go
smoothly.
I wish I could help you more but C code is not for me yet.
Cheers,
Joseph
Mensaje telepatico asistido por maquinas.
_______________________________________________ [email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
