Attached is a patch that should make flext buffer handling 64-bit compatible.
It adds new wrapper functions buffer::Peek(int index) and buffer::Poke(int index, t_sample value) to access a buffer's data. New externals should uses these instead of accessing the data array directly, because with newer PDs that doesn't work. I've also updated the buffer1 example to use the new API wrappers.
The issue is that arrays in PD are of type t_word, which is a union that can contain a variety of data, including pointers. In 32-bit architectures you can pretty much ignore that it's a union because floats and pointers are the same size, but on 64-bit architectures it's important to use the w_float member of the union to access stored floats.
This patch shouldn't break any old externals unless they're used with PD > 0.41 (but then they'd be broken, anyways). I don't have access to an OS X machine or Max/MSP, so I've so far only tested this on 64-bit linux/PD. YMMV.
Can someone explain to me why pd's arrays are arrays of t_word instead of t_sample?
-s-
On Thu, Oct 1, 2009 at 10:41 AM, dmotd dmotd@gmx.net wrote:
hi spencer,
afaik there hasn't been any progress with the 64bit translation, i was going to attempt it last time i needed it but got distracted along the way - and i sent a similar message to thomas at the time, so its going to be on his todo list, but proabably not a priority.
i'd be happy to test any changes you make, and collaborate time permitted.
ciao,
dmotd
Spencer Russell wrote:
Thought this should probably go to the list:
---------- Forwarded message ---------- From: Spencer Russell spencer.f.russell@gmail.com Date: Tue, Sep 29, 2009 at 11:13 AM Subject: Re: fixing Flext for 64-bit? To: Thomas Grill gr@grrrr.org
Am 29.09.2009 um 15:00 schrieb Spencer Russell:
Hi Thomas,
I'm writing a Flext external to implement Iannis Xenakis's Dynamic Stochastic Synthesis, and running into some problems with buffer handling on my 64-bit system.
It seems that currently flext uses the deprecated garray_getfloatarray() function and t_sample arrays, instead of the new garray_getfloatwords() function with t_word unions.
Changing the code would make flext incompatible with older versions of PD, but some other external developers are currently using an #ifdef workaround to change to the newer API call for PD versions that support it.
I was going to get in there and see if i can't get it working in the flext code, but I wanted to check with you first to see if you had already done any work on that front. I'll of course send you the diffs if i get it working. Shouldn't be that hard and i think it should really only effect the buffer-handling code, but I don't know the flext codebase that well so there might be some hidden gotchas.
-spencer
On Tue, Sep 29, 2009 at 9:08 AM, Thomas Grill gr@grrrr.org wrote:
Hi Spencer, i know that this is something i should work on, but my schedule is insanely tight and i don't get to it. So, if you can make any contributions and testing on 64-bit systems i'd be very grateful. I'd also go for the Pd API selecton by #ifdef statements. gr~~~
As far as i can tell, PD since 0.41 changed arrays to be arrays of t_words instead of t_samples or t_floats.
On 32-bit architectures they're all the same size, but on 64-bit architectures t_word is 64-bit, while t_sample and t_float are still 32-bit.
For a normal PD external, it's pretty easy to just modify the external to use t_words, but I'm not sure the best way to modify flext to do this without breaking compatibility for externals. One problem is that when an external calls mybuffer.Data(), what should they receive? if the system is PD newer than 0.41, they should receive a pointer to t_word, but MAX or older PD should receive a pointer to t_sample.
The other problem is that accessing an element for newer PD requires accessing the w_float member of the t_word union, but the others just use the element itself.
There could be some sort of GetValue() wrapper for buffer elements that could be made cross-platform, but would break compatibility with existing flext externals, so that seems seriously sub-optimal.
thoughts?
-s- _______________________________________________ http://grrrr.org/ext/flext
flext mailing list flext@grrrr.org http://www.parasitaere-kapazitaeten.net/mailman/listinfo/flext
Hi Spencer, many thanks for the patch... i'm not yet familiar with the way how pd uses arrays in 64 bit mode, but i'll check out your modifications and commit them to the svn. gr~~~
Am 24.10.2009 um 23:24 schrieb Spencer Russell:
Attached is a patch that should make flext buffer handling 64-bit compatible.
It adds new wrapper functions buffer::Peek(int index) and buffer::Poke(int index, t_sample value) to access a buffer's data. New externals should uses these instead of accessing the data array directly, because with newer PDs that doesn't work. I've also updated the buffer1 example to use the new API wrappers.
The issue is that arrays in PD are of type t_word, which is a union that can contain a variety of data, including pointers. In 32-bit architectures you can pretty much ignore that it's a union because floats and pointers are the same size, but on 64-bit architectures it's important to use the w_float member of the union to access stored floats.
This patch shouldn't break any old externals unless they're used with PD > 0.41 (but then they'd be broken, anyways). I don't have access to an OS X machine or Max/MSP, so I've so far only tested this on 64-bit linux/PD. YMMV.
Can someone explain to me why pd's arrays are arrays of t_word instead of t_sample?
-s-
On Thu, Oct 1, 2009 at 10:41 AM, dmotd dmotd@gmx.net wrote:
hi spencer,
afaik there hasn't been any progress with the 64bit translation, i was going to attempt it last time i needed it but got distracted along the way - and i sent a similar message to thomas at the time, so its going to be on his todo list, but proabably not a priority.
i'd be happy to test any changes you make, and collaborate time permitted.
ciao,
dmotd
Spencer Russell wrote:
Thought this should probably go to the list:
---------- Forwarded message ---------- From: Spencer Russell spencer.f.russell@gmail.com Date: Tue, Sep 29, 2009 at 11:13 AM Subject: Re: fixing Flext for 64-bit? To: Thomas Grill gr@grrrr.org
Am 29.09.2009 um 15:00 schrieb Spencer Russell:
Hi Thomas,
I'm writing a Flext external to implement Iannis Xenakis's Dynamic Stochastic Synthesis, and running into some problems with buffer handling on my 64-bit system.
It seems that currently flext uses the deprecated garray_getfloatarray() function and t_sample arrays, instead of the new garray_getfloatwords() function with t_word unions.
Changing the code would make flext incompatible with older versions of PD, but some other external developers are currently using an #ifdef workaround to change to the newer API call for PD versions that support it.
I was going to get in there and see if i can't get it working in the flext code, but I wanted to check with you first to see if you had already done any work on that front. I'll of course send you the diffs if i get it working. Shouldn't be that hard and i think it should really only effect the buffer-handling code, but I don't know the flext codebase that well so there might be some hidden gotchas.
-spencer
On Tue, Sep 29, 2009 at 9:08 AM, Thomas Grill gr@grrrr.org wrote:
Hi Spencer, i know that this is something i should work on, but my schedule is insanely tight and i don't get to it. So, if you can make any contributions and testing on 64-bit systems i'd be very grateful. I'd also go for the Pd API selecton by #ifdef statements. gr~~~
As far as i can tell, PD since 0.41 changed arrays to be arrays of t_words instead of t_samples or t_floats.
On 32-bit architectures they're all the same size, but on 64-bit architectures t_word is 64-bit, while t_sample and t_float are still 32-bit.
For a normal PD external, it's pretty easy to just modify the external to use t_words, but I'm not sure the best way to modify flext to do this without breaking compatibility for externals. One problem is that when an external calls mybuffer.Data(), what should they receive? if the system is PD newer than 0.41, they should receive a pointer to t_word, but MAX or older PD should receive a pointer to t_sample.
The other problem is that accessing an element for newer PD requires accessing the w_float member of the t_word union, but the others just use the element itself.
There could be some sort of GetValue() wrapper for buffer elements that could be made cross-platform, but would break compatibility with existing flext externals, so that seems seriously sub-optimal.
thoughts?
-s- _______________________________________________ http://grrrr.org/ext/flext
flext mailing list flext@grrrr.org http://www.parasitaere-kapazitaeten.net/mailman/listinfo/flext
<flext_64-bit.patch>_______________________________________________ http://grrrr.org/ext/flext
flext mailing list flext@grrrr.org http://grrrr.org/cgi-bin/mailman/listinfo/flext
Hi Spencer, hi all, i finally committed 64-bit fixes to flext. The way buffers are to be accessed now slightly differ from the patches you sent me... i use the indexing operator [] instead of Peek and Poke functions.
Existing code should continue to work. If compiled for 64-bit systems indexed [] access has to be used directly on flext::Buffer instances (instead of t_sample * vectors).
I adapted the tutorial/buffer example accordingly to reflect the new method.
gr~~~
Am 29.10.2009 um 13:21 schrieb Thomas Grill:
Hi Spencer, many thanks for the patch... i'm not yet familiar with the way how pd uses arrays in 64 bit mode, but i'll check out your modifications and commit them to the svn. gr~~~
Am 24.10.2009 um 23:24 schrieb Spencer Russell:
Attached is a patch that should make flext buffer handling 64-bit compatible.
It adds new wrapper functions buffer::Peek(int index) and buffer::Poke(int index, t_sample value) to access a buffer's data. New externals should uses these instead of accessing the data array directly, because with newer PDs that doesn't work. I've also updated the buffer1 example to use the new API wrappers.
The issue is that arrays in PD are of type t_word, which is a union that can contain a variety of data, including pointers. In 32-bit architectures you can pretty much ignore that it's a union because floats and pointers are the same size, but on 64-bit architectures it's important to use the w_float member of the union to access stored floats.
This patch shouldn't break any old externals unless they're used with PD > 0.41 (but then they'd be broken, anyways). I don't have access to an OS X machine or Max/MSP, so I've so far only tested this on 64-bit linux/PD. YMMV.
Can someone explain to me why pd's arrays are arrays of t_word instead of t_sample?
-s-
On Thu, Oct 1, 2009 at 10:41 AM, dmotd dmotd@gmx.net wrote:
hi spencer,
afaik there hasn't been any progress with the 64bit translation, i was going to attempt it last time i needed it but got distracted along the way - and i sent a similar message to thomas at the time, so its going to be on his todo list, but proabably not a priority.
i'd be happy to test any changes you make, and collaborate time permitted.
ciao,
dmotd
Spencer Russell wrote:
Thought this should probably go to the list:
---------- Forwarded message ---------- From: Spencer Russell spencer.f.russell@gmail.com Date: Tue, Sep 29, 2009 at 11:13 AM Subject: Re: fixing Flext for 64-bit? To: Thomas Grill gr@grrrr.org
Am 29.09.2009 um 15:00 schrieb Spencer Russell:
Hi Thomas,
I'm writing a Flext external to implement Iannis Xenakis's Dynamic Stochastic Synthesis, and running into some problems with buffer handling on my 64-bit system.
It seems that currently flext uses the deprecated garray_getfloatarray() function and t_sample arrays, instead of the new garray_getfloatwords() function with t_word unions.
Changing the code would make flext incompatible with older versions of PD, but some other external developers are currently using an #ifdef workaround to change to the newer API call for PD versions that support it.
I was going to get in there and see if i can't get it working in the flext code, but I wanted to check with you first to see if you had already done any work on that front. I'll of course send you the diffs if i get it working. Shouldn't be that hard and i think it should really only effect the buffer-handling code, but I don't know the flext codebase that well so there might be some hidden gotchas.
-spencer
On Tue, Sep 29, 2009 at 9:08 AM, Thomas Grill gr@grrrr.org wrote:
Hi Spencer, i know that this is something i should work on, but my schedule is insanely tight and i don't get to it. So, if you can make any contributions and testing on 64-bit systems i'd be very grateful. I'd also go for the Pd API selecton by #ifdef statements. gr~~~
As far as i can tell, PD since 0.41 changed arrays to be arrays of t_words instead of t_samples or t_floats.
On 32-bit architectures they're all the same size, but on 64-bit architectures t_word is 64-bit, while t_sample and t_float are still 32-bit.
For a normal PD external, it's pretty easy to just modify the external to use t_words, but I'm not sure the best way to modify flext to do this without breaking compatibility for externals. One problem is that when an external calls mybuffer.Data(), what should they receive? if the system is PD newer than 0.41, they should receive a pointer to t_word, but MAX or older PD should receive a pointer to t_sample.
The other problem is that accessing an element for newer PD requires accessing the w_float member of the t_word union, but the others just use the element itself.
There could be some sort of GetValue() wrapper for buffer elements that could be made cross-platform, but would break compatibility with existing flext externals, so that seems seriously sub-optimal.
thoughts?
-s- _______________________________________________ http://grrrr.org/ext/flext
flext mailing list flext@grrrr.org http://www.parasitaere-kapazitaeten.net/mailman/listinfo/flext
<flext_64-bit.patch>_______________________________________________ http://grrrr.org/ext/flext
flext mailing list flext@grrrr.org http://grrrr.org/cgi-bin/mailman/listinfo/flext
Hey Thomas,
On Mon, Jan 11, 2010 at 11:55 AM, Thomas Grill gr@grrrr.org wrote:
Hi Spencer, hi all, i finally committed 64-bit fixes to flext.
great, thanks!
The way buffers are to be accessed now slightly differ from the patches you sent me... i use the indexing operator [] instead of Peek and Poke functions.
Yeah, C++ and that whole overloading operators thing. Good idea!
-spencer
-
Spencer Russell -
Thomas Grill