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

[Thomas Grill]

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 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
>