[flext] Fwd: fixing Flext for 64-bit?

Thu Oct 29 13:21:15 CET 2009

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 at 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 at gmail.com>
>>> Date: Tue, Sep 29, 2009 at 11:13 AM
>>> Subject: Re: fixing Flext for 64-bit?
>>> To: Thomas Grill <gr at 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 at 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 at grrrr.org
>>> http://www.parasitaere-kapazitaeten.net/mailman/listinfo/flext
>>
> <flext_64-bit.patch>_______________________________________________
> http://grrrr.org/ext/flext
>
> flext mailing list
> flext at grrrr.org
> http://grrrr.org/cgi-bin/mailman/listinfo/flext